Acasă Munca și educație DFD - diagrama fluxului de date. Diagrame de flux de date Compoziția diagramelor de flux de date

DFD - diagrama fluxului de date. Diagrame de flux de date Compoziția diagramelor de flux de date

Baza acestei metodologii este modelarea grafică sisteme de informare 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

Procese

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 fizic procesul poate fi implementat căi diferite, cel mai adesea înseamnă 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 preluate 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 separate reflectă natura informațiilor transmise necesare pentru deservirea clientului băncii. 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 la un card de credit

standardele IT

În comentariile la unul dintre articolele mele anterioare despre IDEF0, unul dintre utilizatori a cerut să spună mai multe despre ce este DFD. Conceptul este oarecum confuz, mulți dintre clienții mei pun întrebări și despre fluxul de date și standardele de diagrame. De aceea am decis să dedic acest articol DFD.

DFD este o abreviere comună pentru engleză. diagrame de flux de date - diagrame de flux de date. Acesta este numele metodologiei de analiză structurală grafică, care descrie sursele și destinațiile datelor externe sistemului, funcțiile logice, fluxurile de date și depozitele de date care sunt accesate. Diagrama fluxului de date (DFD) este unul dintre principalele instrumente de analiză structurală și proiectare a sistemelor informaționale care existau înainte de utilizarea pe scară largă a UML. Wikipedia

În opinia mea, definiția din Wikipedia în limba rusă este oarecum supraîncărcată cu informații și, ca urmare, inutil de greu de înțeles. În plus, eu personal cred că DFD și UML sunt instrumente diferite și, prin urmare, este incorect să spunem că DFD este pur și simplu predecesorul UML.

Pentru mine, am venit cu următoarea formulare:

DFD este o notație concepută pentru a modela sistemele informaționale în ceea ce privește stocarea, procesarea și transmiterea datelor.

De ce este necesară notația DFD?

Din punct de vedere istoric, sintaxa acestei notații a fost folosită în două versiuni - Jordan (Yourdon) și Gane-Sarson (Gane-Sarson). Diferențele dintre ele sunt în tabelul de mai jos:

Eu însumi folosesc doar una dintre opțiuni, potrivit lui Gein și Sarson. Dar când cercetam materialul înainte de a scrie acest articol, am văzut acest tabel de comparație. Cred că este important nu atât pentru alegerea unei opțiuni de sintaxă, va depinde mai mult de alegerea software-ului pentru crearea notațiilor și de preferințele tale personale, ci ca o ilustrare clară a faptului că DFD nu are o sintaxă rigidă, cum ar fi , de exemplu, BPMN. Aici puteți utiliza diferite opțiuni, principalul lucru este că acestea sunt clare pentru dvs. și clienții dvs. Notația DFD este un instrument la îndemână pentru a crea diagrame ad-hoc care pot fi realizate rapid și cu libertate maximă.

Acest tip de notație este utilizat atunci când este necesară o descriere a sistemului ca depozit de date. Acestea. Notația ar trebui să răspundă clar la întrebările:

Ce este un sistem informatic?
Ce este nevoie pentru a procesa informații?

Notația direct DFD constă din următoarele elemente:

Proces, adică o funcție sau o secvență de acțiuni care trebuie întreprinse pentru ca datele să fie prelucrate. Poate fi crearea unei comenzi, înregistrarea unui client etc. Se obișnuiește să se folosească verbe în numele proceselor, adică. „Creează client” (nu „creează client”) sau „procesează comanda” (nu „post comandă”). Nu există un sistem strict de cerințe aici, ca, de exemplu, în IDEF0 sau BPMN, unde notațiile au o sintaxă definită rigid, deoarece pot fi executabile. Dar inca anumite reguli ar trebui urmat pentru a nu deruta alte persoane atunci când citesc DFD.
Entități externe (Engleză External Entity). Acestea sunt orice obiecte care nu sunt incluse în sistemul în sine, dar sunt o sursă de informații pentru acesta sau destinatarii oricărei informații din sistem după procesarea datelor. Poate fi o persoană, un sistem extern, orice purtător de informații și stocare de date.
Magazin de date. Stocarea internă a datelor pentru procesele din sistem. Datele primite înainte de procesare și rezultatul după procesare, precum și valorile intermediare, trebuie stocate undeva. Acestea sunt baze de date, tabele sau orice altă opțiune pentru organizarea și stocarea datelor. Acesta va stoca datele clienților, solicitările clienților, facturile și orice alte date care au intrat în sistem sau sunt rezultatul proceselor de prelucrare.
Flux de date. Notația este afișată sub formă de săgeți care arată ce informații intră și care provin dintr-un anumit bloc din diagramă.

Notația DFD poate descrie orice acțiune, inclusiv procesul de vânzare sau expediere a mărfurilor, lucru cu solicitările clienților sau achiziționarea de materiale, în ceea ce privește descrierea sistemului. Această notație ajută la înțelegerea în ce ar trebui să constea sistemul, ce este necesar pentru a automatiza procesul de afaceri. Dar DFD nu este o descriere a procesului de afaceri în sine. Aici, de exemplu, nu există un parametru atât de important ca timpul. De asemenea, această notație nu oferă condiții și „furci”. În DFD, luăm în considerare de unde provin datele, ce date sunt necesare, cum sunt procesate și unde să trimitem rezultatele. Acestea. această notație descrie nu atât procesul în sine, cât mișcarea fluxurilor de date. Pentru lucrul cu procese, recomand să folosești BPMN sau IDEF3 (voi vorbi despre asta altă dată).

Cum se creează notații DFD

Să luăm ca exemplu notația de automatizare a vânzărilor. Sa presupunem ca avem un client care face o comanda prin site sau telefonic. Există un manager care înregistrează această aplicație. Astfel, în sistem apar date - clientul și comanda sa. Muncitorul depozitar trebuie să vadă acest lucru și să expedieze mărfurile cu înregistrarea tuturor documente necesare si predau documentele clientului.

Secvența este astfel:

Clientul își oferă datele și aplicația.
Managerul verifică și introduce datele primite în sistem.
Muncitorul din depozit generează documente, de exemplu, o factură, și expediază mărfurile.
Clientul primește marfa și un pachet de documente pentru aceasta.

Trebuie să vedem această secvență de acțiuni din punctul de vedere al stocării datelor și al lucrului cu acestea într-un sistem IT.

În ceea ce privește DFD, avem:

Cumpărătorul este o entitate externă care este sursa datelor și destinatarul rezultatului.
Procesul de procesare a comenzii (confirmarea și afișarea datelor în sistem de către manager).
Colectarea comenzii in depozit (dupa primirea cererii).
Înregistrarea expedierii (crearea documentelor necesare).

Ce reguli trebuie să știți pentru a crea o diagramă DFD:

Cum va arăta diagrama (fără descompunere, nivel superior):

Și descompunerea elementului principal al diagramei noastre:

Unde se folosesc notații DFD

Diagramele DFD sunt utilizate în mod activ în dezvoltarea de software. în care:

depozitele de date sunt foi de calcul și baze de date,
entități externe - clienți sau alte baze de date, inclusiv cele din alte programe (integrare și schimb de date),
procesele sunt funcțiile și modulele care sunt efectuate în sistem.

De asemenea, notațiile DFD sunt convenabile pentru analiză atunci când sistemul este considerat din punct de vedere al fluxului de lucru. În același timp, puteți vedea clar unde sunt stocate datele, cum este schimbată documentația, unde s-au făcut greșeli în organizarea proceselor de afaceri în acest proces etc. Dar aici utilizarea diagramelor DFD necesită o atenție specială. Totuși, aceasta nu este o descriere a procesului de afaceri ca atare, ci mai degrabă o diagramă a mișcării datelor în implementarea proceselor de afaceri. Dar ca opțiune auxiliară, inclusiv pentru a demonstra vizual clientului problemele existente și metodele de optimizare a muncii, acest tip de notație este destul de potrivit.

De exemplu, pentru a identifica problemele de flux de documente, duplicarea documentelor sau, dimpotrivă, lipsa documentației sau a datelor electronice din sistem, este foarte convenabil să creați separat o descriere a unui proces de afaceri și apoi o notație DFD pentru acesta. Sau invers, o notație DFD este creată mai întâi pentru a înțelege elementele de bază ale afacerii și caracteristicile implementării fluxului de lucru. Ajută la identificarea, de exemplu, a lipsei unor documente importante în sistemul de automatizare, care sunt de fapt create (pe hârtie), dar nu sunt afișate în sistem în niciun fel. Și apoi se construiește un proces de afaceri optimizat, ținând cont de nuanțele identificate ale fluxului de lucru.

Notarea DFD este ușoară!

Cred că notația DFD este cu adevărat mult mai simplă decât pare la prima vedere. Principalul lucru este să înțelegeți clar limitările construcției acestui tip de diagrame (lipsa condițiilor, timp, etc.) și să le aplicați acolo unde exact această abordare va fi mai convenabilă. Poate veți găsi propriile aplicații ale DFD, pe care nu le-am descris mai sus. Lista mea conține doar acele opțiuni pe care le folosesc în practică.

Ceea ce este deosebit de convenabil în notațiile DFD este că nu este necesar să se respecte regulile și sintaxa stricte, ca, de exemplu, în BPMN. Aceste notații nu vor fi executabile, sunt necesare pentru a înțelege caracteristicile fluxului de lucru, structura și munca ulterioară cu date. Prin urmare, dacă diagrama dvs. este clară atât pentru dvs., cât și pentru client, unele abateri de la standardele DFD sunt destul de acceptabile.

Puteți desena diagrame DFD, în principiu, unde și cum preferați. Dar dacă doriți să lucrați cu descompunerea, să construiți un sistem la diferite niveluri de detaliu, atunci va trebui să uitați de „sertarele” (Visio, Paint și altele asemenea). Veți avea nevoie de software specializat de modelare.

Personal, folosesc programul ERwin și îl recomand tuturor. Unul dintre motivele alegerii mele sunt caracteristicile de descompunere. În ERwin, precum și în alte sisteme similare, este posibil să se descompună procesele DFD în format IDEF3, de exemplu. diagrama principală va fi în format DFD, iar la cel mai general nivel, veți vedea principalele fluxuri de date și „nodurile” lor de procesare. Și atunci când descompuneți, puteți utiliza deja o abordare prin proces, care este, de asemenea, foarte convenabilă pentru dezvoltarea sistemelor mari sau pentru lucrul cu diferite unități de afaceri.

Intrebari si raspunsuri

Care este diferența dintre DFD și UML?

Există un limbaj de notație UML care se poziționează și ca notație bazată pe date. Dar, în același timp, UML este deja un limbaj de programare, există o sintaxă rigidă, cerințe, dar există și multe mai multe oportunități de descriere a diferitelor funcții. DFD sunt notații care sunt folosite mai liber, mai potrivite pentru planificare, explorarea posibilelor soluții, discutarea cu clientul etc.

Dacă sunteți dezvoltator și cunoașteți UML, este posibil ca chiar și unele soluții preliminare să vă fie mai convenabil să le creați în această notație. Și pentru un consultant de afaceri, DFD va fi întotdeauna mai convenabil ca instrument, deoarece un consultant de afaceri nu are nevoie descriere detaliata funcții în ceea ce privește automatizarea, aceasta este sarcina tehnicienilor. Dar DFD economisește mult timp și efort.

În același timp, nu ar trebui să considerați DFD ca o versiune simplificată a UML. În ciuda asemănării abordării, acestea sunt instrumente diferite concepute pentru scopuri diferite.

Câte elemente pot fi folosite în DFD?

Spre deosebire de sistemele cu sintaxă și reguli stricte, DFD nu are limită pentru numărul de elemente care pot fi pe o diagramă. Pentru comparație: în IDEF0 numărul de astfel de elemente, apoi - doar detalii (descompunere) sau notații diferite.
Pe de o parte, acesta este un mare plus, deoarece absența restricțiilor oferă libertate și confort maxim atunci când compuneți notația. Pe de altă parte, această libertate nu trebuie abuzată. Amintiți-vă, cu cât aveți mai multe elemente într-o diagramă, cu atât este mai dificil de citit.

Este posibil să utilizați notațiile DFD pentru a lucra cu clienții?

În principiu, nimeni nu o poate interzice. Mai mult decât atât, în cantități limitate, ca ilustrare a unora dintre explicațiile dvs., astfel de notații sunt, de asemenea, grozave atunci când discutați despre caracteristicile unui proiect cu un client. Dar totuși, clienții sunt de obicei slab versați în problemele de automatizare, structura de stocare a datelor, capacitățile de procesare etc. Totul este în mâinile dezvoltatorilor. Și notațiile DFD sunt construite ținând cont de particularitățile lucrului cu date, așa că recomand în continuare să le folosești în principal atunci când discutăm despre un proiect de către specialiști, când creez o descriere tehnică și o sarcină pentru dezvoltatori, pentru a crește înțelegerea esenței și a caracteristicilor proiectul de către dezvoltatori. Poate fi dificil să explici caracteristicile notațiilor DFD unui client nepregătit.

Dispoziții generale

DFD este o abreviere comună pentru engleză. Diagrame de flux de date - diagrame de flux de date. Acesta este numele metodologiei de analiză structurală grafică, care descrie sursele și destinațiile datelor externe sistemului, funcțiile logice, fluxurile de date și depozitele de date care sunt accesate.

Diagrama fluxului de date (DFD) (Fig. 2.1.) - unul dintre principalele instrumente de analiză structurală și proiectare a sistemelor informaționale care exista înainte de utilizarea pe scară largă a UML. În ciuda faptului că a avut loc în conditii moderne mutând accentul de la o abordare structurală la o abordare orientată pe obiecte a analizei și proiectării sistemelor, notațiile structurale „vechi” sunt încă utilizate pe scară largă și eficient atât în analiza de afaceri, cât și în analiza sistemelor informaționale.

Fig.2.1. Diagrama fluxului de date.

Din punct de vedere istoric, sunt folosite două notații pentru a descrie diagramele DFD - Yodan (Yourdon) și Gane-Sarson (Gane-Sarson), care diferă în sintaxă. Ilustrația de mai jos folosește notația Gein-Sarson.

Sistemul informațional primește fluxuri de date din exterior. Conceptul de entitate externă este utilizat pentru a desemna elementele mediului de funcționare a sistemului. În cadrul sistemului, există procese de transformare a informațiilor care generează noi fluxuri de date. Fluxurile de date pot fi introduse în alte procese, plasate (și preluate) în depozite de date, transferate către entități externe.

Modelul DFD, ca majoritatea celorlalte modele structurale, este un model ierarhic. Fiecare proces poate fi descompus, adică împărțit în componente structurale, relația dintre care în aceeași notație poate fi prezentată pe o diagramă separată. Când se atinge adâncimea de descompunere necesară, procesul de nivel inferior este însoțit de o mini-specificație (descriere textuală).

În plus, notația DFD susține conceptul de subsistem - o componentă structurală a sistemului în curs de dezvoltare.

Notația DFD este un instrument convenabil pentru crearea unei diagrame de context, adică o diagramă care arată AIS dezvoltat în comunicare cu Mediul extern. Aceasta este diagrama de nivel superior din ierarhia diagramei DFD. Scopul său este de a limita domeniul de aplicare al sistemului, de a determina unde se termină sistemul în curs de dezvoltare și unde începe mediul. Alte notații utilizate adesea în formarea diagramei de context sunt diagrama SADT, diagrama diagramei de caz de utilizare.

Pentru a rezolva problema modelării funcționale pe baza analizei structurale se folosesc în mod tradițional două tipuri de modele: diagramele IDEF0 și diagramele fluxului de date.

Metodologia de elaborare a diagramelor de proces este de obicei utilizată în anchetele întreprinderilor ca parte a proiectelor de consultanță în management, precum și în proiectele de automatizare la scară largă pentru sondaje expres (de obicei pentru a întocmi un plan de lucru detaliat).

Notarea diagramelor de flux de date vă permite să afișați pe diagramă atât etapele unui proces de afaceri, cât și fluxul de documente și control (în principal control, deoarece transferul de control contează la nivelul superior al descrierii zonelor de proces). De asemenea, puteți afișa instrumente de automatizare pentru pașii procesului de afaceri pe diagramă. În mod obișnuit, este folosit pentru a afișa al treilea și cel mai jos nivel de descompunere a proceselor de afaceri (primul nivel este lista identificată a proceselor de afaceri, iar al doilea este funcțiile îndeplinite în cadrul proceselor de afaceri).

Diagrama fluxului de date (DFD):

sunt principalele mijloace de modelare a cerințelor funcționale pentru sistemul proiectat;

sunt create pentru a modela procesul existent de mișcare a informațiilor;

folosit pentru a descrie fluxul de lucru, procesarea informațiilor;

Ele sunt folosite ca o completare la modelul IDEFO pentru o afișare mai vizuală a operațiunilor curente ale fluxului de lucru (schimb de informații);

· furnizarea de analiză și determinare a principalelor direcții de reinginerie SI.

Diagramele DFD pot completa ceea ce este deja reflectat în modelul IDEF0, deoarece descriu fluxurile de date, permițându-vă să vedeți modul în care informațiile sunt schimbate atât în cadrul sistemului între funcțiile de afaceri, cât și între sistemul în ansamblu și mediul extern informațional.

Dacă există o parte software/programabilă în sistemul simulat (aproape întotdeauna), de obicei se acordă preferință DFD din următoarele motive.

1. Diagramele DFD au fost create ca instrument pentru proiectarea sistemelor software, în timp ce IDEF0 a fost creat ca instrument pentru proiectarea sistemelor în general, astfel încât DFD-urile au un set mai bogat de elemente care reflectă în mod adecvat specificul lor (de exemplu, depozitele de date sunt prototipuri de fișiere sau baze de date).

2. Prezența unor mini-specificații ale proceselor DFD de nivel inferior permite depășirea incompletității logice a IDEF0, și anume, ruperea modelului la un anumit nivel suficient de scăzut, atunci când detalierea ulterioară a acestuia devine lipsită de sens și construirea unui specificația funcțională completă a sistemului dezvoltat.

3. Algoritmi pentru transformarea automată a ierarhiei DFD în hărți structurale există și sunt susținuți de o serie de instrumente CASE, care demonstrează relațiile intersistem și intrasistem, precum și ierarhia sistemelor, care, împreună cu mini-specificațiile, reprezintă o sarcină completă. pentru programator.

Cu ajutorul diagramelor DFD, cerințele pentru IS proiectat sunt împărțite în componente funcționale (procese) și prezentate ca o rețea conectată prin fluxuri de date. obiectivul principal descompunerea funcțiilor DFD - pentru a demonstra modul în care fiecare proces își transformă datele de intrare în date de ieșire, precum și pentru a identifica relațiile dintre aceste procese. Diagramele proceselor de afaceri afișează:

funcții de proces;

Informații de intrare și de ieșire, la descrierea documentelor;

procesele externe de afaceri descrise în alte diagrame;

Puncte de întrerupere când procesul trece la alte pagini.

Dacă, la modelarea conform metodologiei IDEF0, sistemul este considerat ca o rețea de funcții interconectate, atunci atunci când se creează o diagramă DFD, sistemul este considerat ca o rețea de funcții interconectate, adică. ca un set de entităţi (obiecte).

Analiza structurală este o abordare sistematică, pas cu pas, a analizei cerințelor și a proiectării specificațiilor sistemului, indiferent dacă este un sistem existent sau unul nou. Metodologiile Gane-Sarson și Yourdon/DeMarko pentru diagramarea fluxului de date, bazate pe ideea organizării ierarhice de sus în jos, demonstrează cel mai clar această abordare.

Scopul acestor două metodologii este de a converti cunoștințele comune, obscure despre cerințele de sistem în definiții precise (pe cât posibil). Ambele metodologii se concentrează pe fluxul de date, iar scopul lor principal este de a crea documente de cerințe funcționale bazate pe grafice. Metodologiile sunt susținute de metode tradiționale de proiectare de sus în jos și oferă una dintre moduri mai bune comunicarea între analiști, dezvoltatori și utilizatori ai sistemului prin integrarea următoarelor instrumente:

· Diagrame ale fluxurilor de date.

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

· Prelucrarea mini-specificațiilor care descriu procesele DFD de nivel scăzut și sunt baza pentru generarea codului.

minispec.

O minispecificație este un algoritm pentru descrierea sarcinilor efectuate de procese; setul tuturor minispecificațiilor este o specificație completă a sistemului. Mini-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. Există un număr mare de metode diferite care vă permit să specificați corpul procesului, limbajul corespunzător poate varia de la limbaj natural structurat sau pseudocod până la limbaje de proiectare vizuală (cum ar fi forme FLOW și diagrame Nassi--Schneiderman) și computer formal limbi.

Specificațiile de proiectare sunt construite automat din DFD și mini-specificațiile acestora. Cel mai adesea, pentru a descrie specificațiile de proiectare, se folosește tehnica hărții structurale Jackson, care ilustrează ierarhia modulelor, legăturile dintre acestea și unele informații despre execuția lor (secvență de apel, iterație). Există o serie de metode pentru conversia automată a DFD-urilor în hărți de structură.

Principala caracteristică distinctivă a metodologiei Gein-Sarson este prezența unei etape de modelare a datelor care determină conținutul depozitelor de date (baze de date și fișiere) în DFD în a treia formă normală. Această etapă include construirea unei liste de elemente de date situate în fiecare depozit de date; analiza relațiilor dintre date și construirea unei diagrame adecvate a relațiilor dintre elementele de date; prezentarea tuturor informațiilor despre model sub formă de tabele normalizate legate. În plus, metodologiile diferă în aspecte pur sintactice, de exemplu, simbolurile grafice care reprezintă componentele DFD sunt diferite.

Metodele discutate sunt metode care vă ajută să treceți de la o foaie goală de hârtie sau un ecran la un model de sistem bine organizat. Ambele metodologii se bazează pe conceptul simplu al unei defalcări incrementale de sus în jos a funcțiilor sistemului în subfuncții:

În prima etapă, se formează o diagramă de context de nivel superior care identifică limitele sistemului și definește interfețele dintre sistem și mediu.

După intervievarea unui expert în domeniu, se formează o listă de evenimente externe la care sistemul trebuie să răspundă. Pentru fiecare dintre aceste evenimente, un proces gol (bulă) este construit pornind de la presupunerea că funcția sa oferă reacția necesară la acest eveniment, care în cele mai multe cazuri include generarea de fluxuri și evenimente de ieșire (dar poate include și introducerea de informații în date). magazin pentru utilizare de către alte evenimente).și procese).

La următorul nivel de detaliu, se desfășoară o activitate similară pentru fiecare dintre procesele goale.

Pentru a îmbunătăți funcționalitatea în această notație diagramă, sunt furnizate elemente specifice pentru descrierea fluxurilor de informații și documente, cum ar fi entitățile externe și depozitele de date.

Principalele simboluri ale diagramelor DFD conform acestor notații sunt:

Orez. 3.1. Simboluri de bază ale diagramelor DFD

Pe lângă notația Yordon / De Marco și Hein - Sarson, pot fi utilizate și alte notații pentru elementele diagramelor DFD. conventii(OMT, SSADM etc.). Toate au aproape aceeași funcționalitate și diferă doar în detalii.

În ciuda faptului că metodologia IDEF0 a devenit larg răspândită, potrivit multor analiști, DFD este mult mai potrivit pentru proiectarea sistemelor informaționale în general și a bazelor de date în special. DFD vă permite să determinați cerințele de bază pentru date deja în stadiul de modelare funcțională (acest lucru este facilitat de împărțirea fluxurilor de date în materiale, informaționale și de control). În plus, integrarea modelelor DFD și a modelelor ER (entity-relationship, „entity-relationship”) nu provoacă dificultăți. De exemplu, puteți defini o listă de atribute ale depozitelor de date, acestea din urmă în etapa de modelare a informațiilor sunt afișate în mod unic în entitatea modelului entitate-relație.

La rândul său, după cum sa menționat deja, IDEF0 este mai potrivit pentru rezolvarea problemelor legate de consultanța în management (reingineria proceselor). Acest lucru este facilitat și de legătura strânsă a IDEF0 cu metoda de analiză funcțională a costurilor ABC (Activity Based Costing), care face posibilă determinarea schemei de calcul a costului efectuării unei anumite proceduri de afaceri. Cu toate acestea, există o serie de sisteme CASE - care oferă metodologia IDEF0 în stadiul examinării funcționale a domeniului subiectului. În astfel de sisteme, următoarea etapă este pur și simplu o listă a tuturor obiectelor modelului IDEF0 (intrari, ieșiri, mecanisme, control), care sunt apoi luate în considerare pentru includerea în modelul de informații.

2.2.4.3. Terminologie de notație DFD.

DFD-BLOCKS - o reprezentare grafică a unei operații (proces, funcție, lucru) pentru procesarea sau conversia informațiilor (date). Semnificația blocului DFD care afișează funcția este aceeași cu semnificația blocurilor IDEFO și IDEF3, care este de a converti intrările în ieșiri. Blocurile DFD au, de asemenea, intrări și ieșiri, dar nu acceptă controale și mecanisme precum IDEFO.

Scopul funcției este de a crea fluxuri de ieșire din fluxurile de intrare conform acțiunii specificate de numele procesului. Prin urmare, numele funcției trebuie să conțină un verb într-o formă nedefinită urmat de o adăugare. Funcțiile sunt de obicei denumite după numele sistemului, de exemplu „Dezvoltarea sistemului proiectare asistată de calculator„”. Se recomandă utilizarea verbelor care afișează relații dinamice, de exemplu: „calculați”, „primiți”, „comandă”, „frezi”, „ascuți”, „calcula”, „pornește”, „simula”, etc. Dacă autorul folosește verbe precum „procesează”, „modernizează” sau „editează”, atunci aceasta înseamnă că probabil că nu înțelege încă suficient de profund această funcție a procesului și este necesară o analiză suplimentară.

Conform notației Hein-Sarson, un bloc DFD este reprezentat de un dreptunghi cu colțuri rotunjite. Fiecare bloc trebuie să aibă un număr unic la care să se facă referire în diagramă. Fiecare număr de bloc poate include un prefix, un număr de bloc părinte (A) și un număr de obiect, care este un număr de bloc unic pe diagramă. De exemplu, o funcție poate avea numărul A.12.4.

Pentru a evita intersecțiile liniilor de flux de date, același element poate fi afișat de mai multe ori pe aceeași diagramă; într-un astfel de caz, două sau mai multe dreptunghiuri care denotă același element pot fi identificate printr-o linie care traversează colțul din dreapta jos.

DATA FLOW (fluxul de date) este un mecanism utilizat pentru modelarea transferului de informații între participanții la procesul de schimb de informații (funcții, depozite de date, legături externe). Conform notației Hein-Sarson, fluxul de date (documente, obiecte, angajați, departamente sau alți participanți la prelucrarea informațiilor) este reprezentat de o săgeată între două obiecte ale diagramei DFD, de preferință orizontală și/sau verticală, și direcția a săgeții indică direcția curgerii. Fiecare săgeată trebuie să aibă o sursă și o țintă. Spre deosebire de săgețile diagramei IDEF0 (ICOM), săgețile DFD pot intra sau ieși din orice parte a casetei.

Săgețile descriu modul în care obiectele (inclusiv datele) se deplasează dintr-o parte a sistemului în alta. Deoarece fiecare parte a unui bloc din DFD nu are un scop clar, spre deosebire de blocurile unei diagrame IDEF0, săgețile pot intra și ieși din orice față. În diagramele DFD, pentru a descrie dialogurile de comandă-răspuns între operații, se folosesc săgeți bidirecționale între o funcție și o entitate externă și/sau între entități externe. Săgețile se pot îmbina și ramifica, ceea ce face posibilă descrierea descompunerii săgeților. Fiecare segment nou o săgeată de îmbinare sau de ramificare poate avea propriul nume.

Uneori, informațiile se pot mișca într-o singură direcție, pot fi procesate și revin. O astfel de situație poate fi modelată fie prin două fluxuri diferite, fie printr-unul bidirecțional. Un flux de date poate fi referit prin specificarea proceselor, entităților sau depozitelor de date pe care le conectează fluxul.

Fiecare flux ar trebui să aibă un nume de-a lungul sau deasupra săgeții, ales pentru a transmite cel mai bine sensul conținutului fluxului utilizatorilor care vor vizualiza diagrama fluxului de date. Când schițați o diagramă de flux de date, numele pot fi omise dacă sunt evidente pentru utilizator, dar autorul diagramei trebuie să furnizeze o descriere a fluxului în orice moment.

DIAGRAMĂ DE FLUX DE DATE (DFD-diagram) (Fig.4.1.) - diagrame utilizate pentru reprezentarea grafică (organigrama) a mișcării și procesării informațiilor într-o organizație sau în orice proces. În mod obișnuit, diagramele de acest tip sunt folosite pentru a analiza organizarea fluxurilor de informații și pentru a dezvolta SI. Diagramele DFD sunt o parte cheie a documentului cu specificațiile cerințelor - specificații ierarhice grafice care descriu sistemul în termeni de fluxuri de date. Fiecare nod de proces din DFD poate fi extins într-o diagramă de nivel inferior, care permite abstracția de la detalii la orice nivel. Fig.4.1. Un exemplu de diagramă de flux de date DFD.

Pentru diagramele de acest tip se folosește de obicei abrevierea DFD. DFD-urile sunt. Un DFD poate include patru simboluri grafice reprezentând fluxuri de date, procese de transformare de la intrare la ieșire, surse și destinații de date externe și fișierele și bazele de date necesare proceselor pentru operațiunile lor.

Diagramele DFD modelează funcțiile pe care ar trebui să le îndeplinească sistemul, dar aproape nimic despre relația dintre date, precum și despre comportamentul sistemului în timp - în aceste scopuri se folosesc diagrame entitate-relație și, respectiv, diagrame de tranziție de stare.

DATA STORE (stocare date) (Fig.4.2.) - reprezentare grafică a fluxurilor de date importate/exportate din bazele de date corespunzătoare. De obicei, acestea sunt tabele pentru stocarea documentelor. Spre deosebire de săgețile care descriu obiecte în mișcare, depozitele de date descriu obiecte în repaus. Unitățile de date sunt un fel de prototip al unei baze de date a sistemului informațional al unei organizații. Depozitele de date sunt incluse în modelul de sistem dacă există etape ale ciclului tehnologic la care apar date care trebuie stocate în memorie. La afișarea procesului de salvare a datelor, săgeata fluxului de date este direcționată către depozitul de date și invers - din stocare dacă datele sunt importate.

Fig.4.2. Magazin de date.

Depozitele de date sunt concepute pentru a reprezenta unele dispozitive abstracte pentru stocarea informațiilor care pot fi plasate sau preluate acolo în orice moment, indiferent de implementarea lor fizică specifică. Se folosesc depozite de date:

în sistemele materiale, unde obiectele așteaptă să fie procesate, cum ar fi într-o coadă;

în sistemele de procesare a informațiilor pentru a modela mecanismele de stocare a datelor pentru operațiuni ulterioare.

Conform notației Hein-Sarson, un depozit de date este indicat de două linii orizontale închise la un capăt. Fiecare depozit de date trebuie identificat pentru referință prin litera D și un număr arbitrar într-un pătrat din partea stângă, cum ar fi D5. Numele trebuie selectat ținând cont de cel mai mare conținut de informații pentru utilizator.

Mai multe apariții ale depozitului de date pot fi create într-un model, fiecare dintre ele putând avea același nume și același număr de referință. Pentru a nu complica diagrama fluxului de date cu intersecții de linii, este posibil să se reprezinte duplicate ale depozitului de date cu linii verticale suplimentare în partea stângă a pătratului.

REFERINȚĂ EXTERNĂ (link extern, entitate externă, entități externe) (Fig.4.3.) - un obiect al unei diagrame de flux de date, care este o sursă sau un receptor de informații din afara modelului. Legăturile/entitățile externe descriu intrări și/sau ieșiri, de ex. oferi o interfață cu obiecte externe din afara sistemului care se modelează. Legăturile externe ale sistemului sunt de obicei clase logice de obiecte sau persoane care reprezintă sursa sau receptorul mesajelor, de exemplu, clienți, designeri, tehnologi, servicii de producție, depozitari etc. Acestea pot fi surse specifice, precum contabilitate, sistem de recuperare a informațiilor, serviciu standard de control, depozit. Dacă sistemul în cauză primește date de la alt sistem sau transmite date către alt sistem, atunci acest celălalt sistem este un element sistem extern. Fără un obiect „entitate externă”, uneori poate fi dificil pentru un analist să determine de unde provin aceste documente în companie. Sau de la ce documente mai provin, o entitate externă precum, de exemplu, „client”.

Fig.4.3. entitate externă.

În notația Gein-Sarson, o pictogramă xref este un dreptunghi umbrit în partea de sus și din stânga, care are o lățime dublă pentru a distinge simbolul de alte simboluri din diagramă și este de obicei situat la marginile diagramei. O legătură externă poate fi identificată printr-un E minuscul în colțul din stânga sus și un număr unic, cum ar fi E5. De asemenea, un link extern are un nume.

Considerând sistemul ca functie externa, este adesea indicat că se află în afara granițelor sistemului care se modelează. După analiză, unele legături externe pot fi mutate în diagrama fluxului de date a sistemului în cauză sau, dimpotrivă, o parte din funcțiile sistemului poate fi scoasă și considerată ca o legătură externă.

La interpretarea unei diagrame DFD, se folosesc următoarele reguli:

Funcțiile transformă fluxurile de date primite în fluxuri de ieșire;

· Depozitele de date nu modifică fluxurile de date, ci servesc doar la stocarea obiectelor primite;

· Transformările fluxurilor de date în legături externe sunt ignorate.

În plus, sunt definite elementele de date asociate fiecărui flux de informații și stocare. Fiecărui element de date i se dă un nume și se pot specifica un tip de date și un format pentru acesta. Această informație este cea inițială la următoarea etapă de proiectare - construcția modelului „entitate-relație”. În acest caz, de regulă, magazinele de informații sunt convertite în entități, proiectantul trebuie doar să rezolve problema folosind elemente de date care nu sunt legate de magazine.

Reprezentarea fluxurilor ca săgeți împreună cu depozitele de date și entitățile externe face ca modelele DFD să fie mai asemănătoare cu caracteristici fizice sisteme - deplasarea obiectelor, depozitarea obiectelor, furnizarea și distribuția obiectelor.

Construirea diagramelor.

Diagramele DFD pot fi construite folosind analiza structurală tradițională, similar modului în care sunt construite diagramele IDEFO:

se construiește un model fizic care reflectă starea actuală a lucrurilor;

Modelul rezultat este convertit într-un model logic care afișează cerințele pentru sistem existent;

se construiește un model care reflectă cerințele pentru viitorul sistem;

se construiește un model fizic, pe baza căruia ar trebui construit un nou sistem.

O abordare alternativă este o abordare utilizată în dezvoltarea de software numită partiționare de evenimente, în care diferite diagrame DFD construiesc un model al sistemului:

un model logic este construit ca un set de procese și documentație a ceea ce ar trebui să facă aceste procese;

· Folosind modelul de mediu, sistemul este descris ca un obiect care interacționează cu evenimente de la entități externe. Un model de mediu conține de obicei o descriere a scopului sistemului, o diagramă de context și o listă de evenimente. Diagrama de context conține un bloc care înfățișează sistemul ca întreg, entități externe cu care sistemul interacționează, legături și câteva săgeți importate din diagramele IDEF0 și DFD. Includerea legăturilor externe în diagrama de context nu anulează cerințele metodologiei de a defini clar scopul, domeniul de aplicare și punctul de vedere comun asupra sistemului care se modelează;

· model de comportament (model de comportament) arată modul în care sistemul procesează evenimentele. Acest model constă dintr-o singură diagramă în care fiecare bloc ilustrează fiecare eveniment din modelul de mediu, pot fi adăugate magazine pentru a modela datele care trebuie reținute între evenimente. Fluxurile sunt adăugate pentru a comunica cu alte elemente și diagrama este verificată cu modelul de mediu.

Diagramele rezultate pot fi transformate pentru a reprezenta mai vizual sistemul, în special, funcțiile pot fi descompuse.

Un exemplu de diagrame DFD conform notației Gein-Sarson pentru o întreprindere care își construiește activitățile pe principiul „fabricat la comandă” este prezentat în Figura 5.1.

Pe baza comenzilor primite se formeaza un plan de productie pentru o anumita perioada. În conformitate cu acest plan, se stabilește necesarul de componente și materiale, precum și programul de încărcare. echipament de productie. După fabricarea produselor și efectuarea plăților, produse terminate trimis clientului.

Comenzile sunt supuse controlului și sortării primite. În cazul în care comanda nu corespunde gamei de produse sau este executată incorect, atunci aceasta este anulată cu notificarea corespunzătoare a clientului. Dacă comanda nu este anulată, se stabilește dacă articolul corespunzător este în stoc. În cazul unui răspuns pozitiv, se emite o factură de plată și se prezintă clientului, la primirea plății, marfa este trimisă clientului. În cazul în care comanda nu este furnizată cu stocuri de depozit, atunci o cerere pentru mărfuri este trimisă producătorului. După ce mărfurile necesare ajung la depozitul companiei, comanda devine securizată și repetă traseul descris mai sus.

Fig.5.1. Un exemplu de diagrame DFD conform notației Gein-Sarson pentru o întreprindere

Această diagramă reprezintă cel mai înalt nivel al modelului funcțional. Desigur, aceasta este o descriere foarte grosieră a domeniului subiectului. Modelul este rafinat prin detalierea funcțiilor necesare pe diagrama DFD a următorului nivel. Deci putem împărți funcția „Identificarea nevoilor și furnizarea materialelor” în sub-funcții „Identificarea nevoilor”, „Căutare furnizori”, „Încheierea și analiza contractelor de furnizare”, „Controlul plăților”, „Controlul aprovizionării”, conectate prin propriile fluxuri de date, care vor fi prezentate într-o diagramă separată. Detalierea modelului trebuie efectuată până când acesta conține toate informațiile necesare pentru construirea unui sistem informațional.

Avantajele tehnicii DFD includ:

capacitatea de a identifica fără ambiguitate entitățile externe prin analizarea fluxurilor de informații din interiorul și din exteriorul sistemului;

Capacitatea de a proiecta de sus în jos, ceea ce facilitează construirea unui model „cum ar trebui să fie”;

· disponibilitatea specificațiilor de proces de nivel inferior, care face posibilă depășirea incompletității logice a modelului funcțional și construirea unei specificații funcționale complete a sistemului în curs de dezvoltare.

Dezavantajele modelului includ:

· necesitatea introducerii artificiale a proceselor de control, întrucât acțiunile (fluxurile) de control și procesele de control din punctul de vedere al DFD nu sunt diferite de cele obișnuite;

· absența conceptului de timp, i.e. lipsa analizei intervalelor de timp la conversia datelor (toate limitele de timp trebuie introduse în specificațiile proceselor).

Bibliografie:

1. Andreychikov A. V. Andreychikova O. N. Sisteme informatice inteligente Izd. „Finanțe și statistică”, Moscova, 2004 422s.

2. Anisimov B.P., Kotov V.V. Revista „Metodologii moderne de analiză structurală și proiectare a sistemelor de procesare a informațiilor” Produse softwareși sisteme” Nr. 2 pentru 1997. [ 24.06.1997]

3. Kozlenko L. „Design of information systems. Partea 1. Etapele dezvoltării proiectului: strategie și analiză „Revista ComputerPress, 9” 2001.

4. Mark D.A. McGowek, K. Metodologia SADT pentru analiză structurală și proiectare, ed. Metatehnologie, M. 1993.

5. Vendrov A.M. tehnologii CASE metode moderneși instrumente și sisteme de proiectare ed. Finanţe şi statistică M. 1998.

Resurse de internet:

http://www.aiportal.ru/

http://www.itstan.ru/

http://www.intuit.ru/

tenologie SADT

Introducere

SADT (Structured Analysis and Design Technique) este una dintre cele mai cunoscute metodologii de analiză și proiectare a sistemului, introdusă în 1973 de Ross. SADT a fost utilizat cu succes în domeniul militar, industrial și organizatii comerciale pentru o gamă largă de sarcini precum software retelele telefonice, suport de sistem și diagnosticare, pe termen lung și planificare strategica, producție și proiectare automatizate, configurare sisteme informatice, instruirea personalului, software încorporat pentru sisteme de apărare. management financiar și logistic, etc. Această metodologie este susținută pe scară largă de Departamentul Apărării al SUA. care a fost inițiatorul dezvoltării standardului IDEF0 ca subset al SADT. Acest lucru, împreună cu suportul automatizat în creștere, l-a făcut mai accesibil și mai ușor de utilizat.

Din punctul de vedere al SADT, modelul se poate baza fie pe funcțiile sistemului, fie pe subiectele acestuia (planuri, date, echipamente, informații etc.). Modelele corespunzătoare se numesc modele de activitate și modele de date. Modelul de activitate reprezintă, cu gradul de detaliu necesar, un sistem de activități, care la rândul lor reflectă relațiile lor prin obiectele sistemului. Modelele de date sunt duale cu modelele de activitate și reprezintă o descriere detaliată a elementelor sistemului conectate de activitățile sistemului. Metodologia completă a SADT este de a construi modele de ambele tipuri pentru a descrie mai precis un sistem complex. Cu toate acestea, în prezent, doar modelele de activitate și-au găsit o aplicare largă, iar această secțiune este dedicată luării în considerare a acestora.

Diagramele SADT

Principalul element de lucru în modelare este o diagramă. Modelul SADT combină și organizează diagramele în structuri arborescente ierarhice, cu cât nivelul diagramei este mai ridicat, cu atât este mai puțin detaliat. Diagrama constă din blocuri care descriu activitățile sistemului care este modelat, leagă blocuri între ele și ilustrează interacțiunile și relațiile dintre blocuri. SADT necesită ca o diagramă să aibă 3-6 blocuri: în aceste limite, diagramele și modelele sunt ușor de citit, înțeles și utilizat. În loc de un model greoi, sunt folosite mai multe modele mici interconectate, ale căror valori se completează reciproc, făcând clară structurarea unui obiect complex. Cu toate acestea, o cerință atât de strictă pentru numărul de blocuri dintr-o diagramă limitează utilizarea SADT pentru un număr de domenii. De exemplu, în structurile bancare există 15-20 de activități egale pe care este indicat să le reflectați pe o singură diagramă. Separarea lor artificială în diferite niveluri ale modelului SADT, evident, nu îmbunătățește înțelegerea acestuia.

Structura blocului

Blocurile din diagrame sunt prezentate ca dreptunghiuri și sunt însoțite de texte în limbaj natural care descriu activitățile. Spre deosebire de alte metode de analiză structurală în SADT, fiecare parte are un scop special bine definit: partea stângă a blocului este pentru Intrări, cea de sus este pentru Controale, partea dreaptă este pentru Ieșiri, cea inferioară este pentru Interpreți. Această desemnare reflectă anumite principii de activitate: Intrările sunt convertite în Ieșiri, Controalele restricționează sau prescriu condiții de execuție, Executorii descriu modul în care sunt efectuate transformările.

Arcurile din SADT reprezintă seturi de articole și sunt etichetate cu texte în limbaj natural. Elementele pot fi asociate cu activități în patru relații posibile: Input, Output, Control, Performer. Fiecare dintre aceste relații este reprezentată de un arc asociat cu o anumită latură a blocului - astfel laturile blocului sortează obiectele reprezentate de arce într-un mod pur grafic. Arcurile de intrare reprezintă elementele utilizate și transformate de activități. Arcurile de control reprezintă de obicei informații gestionarea actiunilor Activități. Arcurile de ieșire reprezintă elementele în care sunt convertite intrările. Arcurile de performanță reflectă (cel puțin parțial) implementarea activităților.

Blocurile de pe diagramă sunt plasate într-un model „în trepte” în conformitate cu dominanța lor, care este înțeleasă ca influență exercitată de un bloc asupra altora. În plus, blocurile ar trebui numerotate, de exemplu, în funcție de dominanța lor. Numerele bloc servesc ca identificatori unici pentru activități și organizează automat aceste activități într-o ierarhie de model.

Interacțiunea reciprocă a blocurilor poate fi exprimată fie prin transmiterea Ieșirii către o altă activitate pentru o transformare ulterioară, fie prin dezvoltarea informațiilor de control care prescriu exact ce ar trebui să facă cealaltă activitate. Astfel, diagramele SADT sunt diagrame prescriptive care descriu atât transformările dintre Input și Output, cât și regulile prescriptive pentru aceste transformări.

Relații

În SADT, sunt necesare doar cinci tipuri de relații între blocuri pentru a descrie relațiile lor: Control, Input, Control Feedback, Input Feedback, Output - Performer. Relația dintre control și intrare este cea mai simplă, deoarece reflectă influențe directe intuitiv evidente. O Relație de Control apare atunci când Ieșirea unui bloc afectează direct un bloc cu mai puțină dominanță. O relație de intrare apare atunci când un bloc Out of one devine o intrare pentru un bloc cu mai puțină dominanță. Feedback-urile sunt mai complexe deoarece reflectă iterația sau recursiunea - Ieșirile dintr-o activitate afectează execuția viitoare a altor funcții, care afectează ulterior activitatea inițială. Feedback-ul de control apare atunci când Ieșirea unui bloc afectează un bloc cu o dominație mai mare, iar raportul de intrare Părere apare atunci când Ieșirea unui bloc devine Intrarea altui bloc cu mai multă dominanță. Ieșire din relații - Interpreții se întâlnesc rar și prezintă un interes deosebit. Ele reflectă o situație în care rezultatul unei activități devine un mijloc pentru un scop al unei alte activități.

Principalele componente ale diagramelor de flux de date sunt:

Entități externe (Referință externă);

Sisteme/subsisteme;

procese;

Dispozitive de stocare a datelor (magazin de date);

Fluxuri de date.

Sursele de informații (entități externe) generează fluxuri de informații (fluxuri de date) care transferă 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.

entitate externă

O entitate externă este un obiect material, individ sau alt sistem care reprezintă sursa și/sau destinatarul informațiilor.

Nume entităţile trebuie să conţină substantiv, De exemplu, „OS”, „Sistem de fișiere”, „Utilizator”, „Stocare externă”, „Vânzător(i)”, „Client(i)”, „Depozit”.

Definirea unor obiecte sau sisteme ca entităţi externe indică faptul că sunt dincolo de graniţe a sistemului proiectat, ei nu ar trebui să participe la nicio prelucrare.

Prin urmare, acestea nu pot fi mecanisme dintr-un model în notație IDEF0. Un caz special alcătuiți mecanisme de model în notația IDEF0, cum ar fi „Utilizator”.

Utilizatorul poate fi reprezentat și ca un mecanism, deoarece participă la procesul de prelucrare prin introducerea datelor, selectarea elementelor de meniu etc. În acest caz, el acționează ca un operator. Și, în același timp, utilizatorul este o entitate externă în model în notație DFD, deoarece oferă date pentru prelucrare, primește și rezultatul sistemului proiectat, în special software.

entitate externă notat cu un dreptunghi(Fig. 10.1), situat ca „deasupra” diagramei și aruncând o umbră asupra acesteia, tocmai pentru a arăta că entitatea externă este în afara contextului sistem simulat.

De obicei, entitățile externe au de-a lungul marginilor diagramei. O entitate externă poate fi utilizată de mai multe ori într-una sau mai multe diagrame. Această tehnică este folosită pentru a nu desena săgeți de legătură prea lungi și confuze.

Fiecare entitate externă este identificată prin litera „E” și un număr arbitrar (același pe diferite copii ale entității). Fiecare entitate externă este dată descriere text.

Exemple de entități cu posibile descrieri textuale sunt date în Tabel. 10.1.

Tabelul 10.1

Exemple de entități externe

Numele entitatii	Descriere
Utilizator	Persoană care utilizează acest sistem(software dat)
	Sistemul de operare (MS Windows) oferă: setări ale interfeței OS, cum ar fi setările imprimantei, dimensiunea, stilul, culoarea fontului, culoarea fundalului etc.; permisiuni pentru acțiuni cu fișierul; data și ora curente
Unități logice și/sau fizice	Oferă (oferă) utilizatorului o listă de fișiere și foldere stocate pe computer și, de asemenea, oferă (oferă) posibilitatea de a înregistra și stoca date noi
Sistemul de fișiere
	Stocare externă care vă permite să stocați informații arbitrare în sine, cu posibilitatea recuperării lor ulterioare
Stocare externă	Hard disk, dischetă, CD-ROM, unitate de rețea etc.

Sistem și subsistem

Atunci când se construiește un model al unui sistem complex, acesta este prezentat în foarte vedere generala pe diagrama de context ca un. Atunci ea descompuse într-un număr de subsisteme.

La fel de Nume sisteme, subsisteme utilizate propoziție cu subiectși definiții și completări aferente, De exemplu, „Sistem de procesare a informațiilor”, „Subsistem pentru lucrul cu fișiere”, „Subsistem pentru lucrul cu o imagine”, „Subsistem pentru lucrul cu un document”, „Subsistem pentru setarea unui font”.

Proces, acțiune (sau muncă)

Un proces (sau o lucrare) este o funcție a unui sistem, a unui subsistem. Convertește fluxurile de date de intrare în date de ieșire conform unui anumit algoritm.

Fizic un proces poate fi implementat în diverse moduri: poate fi o subdiviziune a unei organizații (departament) care procesează documente de intrare și emite rapoarte, un program, un dispozitiv logic implementat hardware etc.

La fel de Nume este utilizat procesul propoziție cu activ fără ambiguitate verb în formă nedefinită(calculați, calculați, verificați, determinați, creați, obțineți) urmat de un substantiv la acuzativ, De exemplu, Scalare imagine, Imprimare document, Deschidere document, Desenare linie, Redenare imagine.

Utilizarea verbelor precum „procesează”, „modernizează” sau „editează” înseamnă de obicei o lipsă de înțelegere acest procesși necesită analize suplimentare.

Sistemele, subsistemele, procesele, acțiunile (sau lucrările) sunt descrise în același mod: dreptunghiuri cu colțuri rotunjite - blocuri funcționale (Fig. 10.2).

În cazul general, semnificația lor coincide cu semnificația acțiunilor din notațiile IDEF0 și IDEF3. Ele sunt identificate pe diagrame similar blocurilor funcționale în notația IDEF0 (prefix, număr diagramă, număr obiect). La fel ca acțiunile din IDEF3, ele au intrări și ieșiri, dar nu acceptă controale și mecanisme precum blocurile funcționale din IDEF0.

Fiecare bloc funcțional este dat descriere text.

În „Termeni de referință”, în secțiunea „Cerințe de sistem”, la enumerarea lucrărilor care pot fi efectuate folosind software-ul dezvoltat, trebuie indicate definițiile (descrierile) detaliate ale acestora.

Flux de date (săgeată)

Fluxul de date descrie mișcarea unui obiect dintr-o parte a sistemului în alta.

Entitățile, procesele și unitățile externe pot acționa ca surse de date și receptori pentru fluxuri.

Fizic un flux de date poate fi informații transmise printr-un cablu între două dispozitive, scrisori trimise prin poștă, benzi magnetice sau dischete, transferate de la un computer la altul și așa mai departe.

Orientarea săgeții indică direcția fluxului. Săgețile cu două capete pot fi folosite pentru a descrie dialogurile comandă-răspuns. În fiecare caz, analistul decide ce este mai convenabil să descrie: un flux bidirecțional sau două fluxuri diferite în direcții opuse.

Deoarece fiecare parte a unui bloc funcțional nu are un scop clar în DFD, ca în IDEF0, săgețile pot intra și ieși din orice față a blocului.

Fiecare flux de date are Nume reprezentând conținutul acestuia. Trebuie folosit numele substantiv. Fiecare flux de date este dat descriere text.

Anexa la „Termeni de referință” conține nume și descrieri textuale ale fluxurilor de date sub forma unui dicționar de date.

În DFD, săgețile se pot îmbina și se ramifică, ceea ce ne permite să descriem descompunerea săgeților (fluxuri de date). Fiecare segment nou (subflux) al unei săgeți de îmbinare sau ramificare poate avea propriul nume.

La descompunerea fluxurilor fluxurile și subfluxurile trebuie să fie strict definite în dicționarul de date, adică definiți clar structura datelor.

Structură de date- un grup numit, înrudit logic, de elemente și substructuri de date stocate în unitate sau transmise în fluxul de informații. Un instrument pentru specificarea compoziției și relației elementelor individuale de date.

Pentru a crește claritatea și lizibilitatea diagramelor efectuați descompunerea fluxurilor peste granițele diagramelor.

De exemplu, fluxul „Date” este inclus în lucrarea detaliată, pe diagrama de detaliere acest flux este șters, iar în loc de acesta, „Date pentru lucrul cu imaginea”, „Date despre parametrii interfeței”, „Date pe sunt introduse fluxuri de atribute ale imaginii, ca și cum ar fi fost transferate dintr-o lucrare detaliată.

Dar, în scopuri de echilibrare, trebuie să existe o definiție strictă a structurii fluxului „Date”: fluxul „Date” constă din subfluxuri „Date pentru lucrul cu imaginea”, „Date despre parametrii interfeței”, „Date despre atributele imaginii”. " și fără alte elemente de date.

Unitate de date (stocare)

Un dispozitiv de stocare a datelor este un dispozitiv de stocare abstract capabil să scrie și să recupereze date. Metodele de acces (plasarea și extragerea) și stocarea datelor în unități pot fi orice și nu sunt specificate în timpul analizei.

Acumulator descrie obiect în repaus spre deosebire de un flux de date care descrie un obiect în mișcare.

Fizic un dispozitiv de stocare a datelor poate fi implementat ca sertar într-un dulap de fișiere, o masă în RAM, un fișier pe suport magnetic etc.

La dezvoltarea software-ului, stocarea datelor sunt prototipuri fișiere sau baze de date. De aceea Descriere depozitate în ele date ar trebui să fie legat de modelul informațional.

Nume conduce trebuie să fie substantivși este ales din punctul de vedere al celui mai mare conținut informațional pentru designer. În cazul în care un flux de date intră sau iese dintr-o unitate și structura acestuia se potrivește cu cea a unității, acesta trebuie să aibă același nume.

Dispozitivul de stocare a datelor este reprezentat așa cum se arată în Fig. 10.3. O unitate poate fi utilizată de mai multe ori pe una sau mai multe diagrame. Unitatea de date este identificată printr-un număr de serie (același pe diferite copii ale unității).

Fiecare unitate este dată descriere text: „utilizat atunci când se efectuează un astfel de proces (acțiune, muncă)”, „destinat să stocheze astfel de date”. Exemple de unități cu posibile descrieri text sunt date în tabel. 10.2.

Tabelul 10.2

Drive exemple

Numele unității	Descriere
Imagine în memorie	Unitatea este concepută pentru a stoca informații despre setul de pixeli care alcătuiesc imaginea
Deschideți documentulîn OP	Conceput pentru a stoca în OP conținutul unui document text și numele complet al acestuia (inclusiv calea)
Setări de interfață în memorie	Folosit pentru a stoca informații despre dimensiunea ferestrei de lucru și starea ferestrelor auxiliare
Atributele imaginii memoriei	Folosit pentru a stoca lățimea imaginii, înălțimea, unitățile, vizualizarea paletă

Datele stocate în unitate sunt obiecte de domeniu și la construirea unui model de date, acestea vor fi modelate ca „entități” (a nu se confunda cu entitățile de notație DFD).

Pentru fiecare depozit de date, este compilat un tabel care listează compoziția datelor în unități.

Tab. 10.3 - 10.5 sunt exemple de astfel de tabele pentru modelul „Editor grafic (Paint)” în notația DFD prezentată în fig. 10,4 - 10,7.

Tabelul 10.3

Conținutul dispozitivului de stocare a datelor „Imagine de memorie”.

Numele domeniului		Descriere
Nume de fișier	Text
Cod de culoare	Numeric, întreg	Cod de codificare
Conţinut	Text	Conținutul fișierului grafic - informații despre setul de pixeli care alcătuiesc imaginea Dimensiunea imaginii din memorie depinde de lățimea și înălțimea imaginii. Dimensiunea maximă a imaginii: 99999*99999 pixeli

Tabelul 10.4

Conținutul depozitului de date „Atribute imagine în memorie”.

Numele câmpurilor		Descriere
Lățimea imaginii	Numeric, întreg	Câmpul stochează lățimea imaginii în pixeli (max. 99999)
Înălțimea imaginii	Numeric, întreg	Câmpul stochează înălțimea imaginii în pixeli (maxim 99999)
Vizualizare paletă	Logic	Culoare sau alb-negru (1/0)
Unități	Logic	centimetru, inch, punct

Tabelul 10.5

Conținutul depozitului de date „Parametrii interfeței de memorie”.

Numele câmpurilor		Descriere
Lățimea ferestrei de lucru	Numeric, întreg	Câmpul stochează lățimea ferestrei de lucru în pixeli (maxim 1600)
Înălțimea ferestrei de lucru	Numeric, întreg	Câmpul stochează înălțimea ferestrei de lucru în pixeli (maxim 1200)
Set de instrumente	Logic	Afișați/Ascundeți (1/0)
	Logic	Afișați/Ascundeți (1/0)
Bara de stare	Logic	Afișați/Ascundeți (1/0)
Panoul de atribute text	Logic	Afișați/Ascundeți (1/0)

Pentru software-ul „Editor de text (Notepad din grupul Windows Standard OS)”, care funcționează cu un fișier text, iar conținutul fișierului text este stocat în OP, conținutul unității „Deschidere document în OP” poate fi așa cum se arată în tabel. 10.6.

Tabelul 10.6

Conținutul depozitului de date „Deschideți documentul în OP”

Numele domeniului		Descriere
Nume de fișier	Text	Numele complet al fișierului (inclusiv calea)
Codificare	Text	Nume codificare (lista de codificări acceptate depinde de sistemul de operare)
Conţinut	Text	Conținutul documentului - informații despre setul de caractere care alcătuiesc documentul text

Dacă un depozit de date este utilizat pentru a stoca valorile formatului de afișare curent, atunci conținutul unui astfel de magazin poate fi așa cum se arată în tabel. 10.7.

Tabelul 10.7

Conținutul depozitului de date „Format de afișare curent”

Numele domeniului		Descriere
Numele fontului	Text	Numele unuia dintre fonturile posibile, de exemplu, Times New Roman
Stilul fontului	Text	Numele unuia dintre stilurile posibile, de exemplu, italic, bold
Marimea fontului	Numeric, întreg	O valoare care corespunde uneia dintre dimensiunile posibile de font
Încheierea textului	Logic	1 - transfer activat, 0 - dezactivat

Dacă se utilizează software-ul opțiuni posibile parametrii (de exemplu, opțiuni pentru setările programului; opțiuni pentru fonturi posibile; opțiuni pentru dimensiuni posibile de font), din care utilizatorul selectează valorile curente, apoi conținutul unității de date cu opțiuni pentru fiecare parametru poate fi așa cum se arată în Tabel. 10.8.

Tabelul 10.8

Conținutul unității de date „Opțiuni de setare program”.

Numele câmpurilor			Descriere
Nume parametru	Text		Câmpul stochează numele parametrului
Lista de valori posibile pentru acest parametru	Matrice numerică, întreg (sau matrice booleană sau Matrice de șiruri)	4 octeți (sau 1 bit, sau dimensiunea unei linii) * număr de opțiuni de valoare	Câmpul stochează o listă de valori ale parametrilor
Și așa pentru fiecare parametru stocat în stocarea de date

Concept general

Metoda de modelare a proceselor - Fluxuri de date (DFD)

DFD-urile vă permit să prezentați cerințele pentru sistemul proiectat sub forma unei ierarhii de componente funcţionale (procese) conectate prin fluxuri de date.

Scopul acestei reprezentări este de a arăta modul în care fiecare proces își transformă intrările în ieșiri și de a dezvălui relațiile dintre aceste procese.

Exemplu. America anilor 20. Consilierul de birou a înconjurat fiecare funcționar și o săgeată fiecare document a trecut între ei. Folosind o astfel de diagramă, el a propus o schemă de reorganizare în care doi funcționari care schimbau multe documente erau așezați unul lângă celălalt, iar funcționarii cu puțină interacțiune erau așezați la mare distanță unul de celălalt. Așa a apărut primul prototip DFD.

Pentru a construi DFD se folosesc două notații diferite, corespunzătoare metodelor Jordan și Gein-Serson. Alte exemple vor folosi notația Gein-Serson mai populară astăzi.

Modelul de sistem descrie un proces asincron de transformare a informațiilor. Descompunere diagrame de context(diagramele de nivel superior) continuă, creând o ierarhie de diagrame pe mai multe niveluri, până când se ajunge la un nivel de descompunere, la care procesele devin elementare și este imposibil să le detaliezi mai departe.

Principalele componente ale diagramelor de flux de date sunt:

1. Entități externe.

2. Sisteme și subsisteme.

3. Procese.

4. Unități de date.

5. Fluxuri de date.

entitate externă- un obiect material sau un individ reprezentând o sursă sau un receptor de informații (clienți, furnizori, clienți, un depozit etc.) În diagramele fluxului de date, o entitate externă este indicată printr-un pătrat care face umbră.

Sisteme și subsisteme sunt elemente ale nivelului superior al descompunerii și sunt afișate pe diagramele de context în ansamblu.

Sistemele și subsistemele sunt descompuse în proceselor– componente ale diagramelor concepute pentru a converti fluxurile de date de intrare în cele de ieșire în conformitate cu un anumit algoritm.

Din punct de vedere fizic, procesul poate fi implementat în diferite moduri: poate fi o subdiviziune a organizației care procesează documente de intrare și emite rapoarte, sau un program, sau un dispozitiv logic implementat hardware etc.

Utilizarea verbelor precum „procesează”, „modernizează” sau „editează” în diagrame indică o lipsă de înțelegere a acestui proces și necesită o analiză suplimentară.

Stocare a datelor- un dispozitiv abstract pentru stocarea informațiilor. Se presupune că informațiile pot fi plasate în unitate în orice moment și preluate după un anumit timp, iar metodele de plasare și preluare de acolo pot fi diferite.

Din punct de vedere fizic, un dispozitiv de stocare a datelor poate fi implementat sub forma unui sertar într-un dulap de fișiere, o masă în RAM, fișiere pe suport magnetic etc.

În diagrama fluxului de date, depozitul de date este identificat prin litera „D” și un număr arbitrar. Numele unității este ales din punctul de vedere al celui mai mare conținut de informații pentru designer. În cazul general, stocarea datelor este un prototip al viitoarei baze de date, iar descrierea datelor stocate în aceasta trebuie specificată în conformitate cu modelul informațional (ERD).

Flux de date defineşte informaţia transmisă printr-o conexiune de la sursă la receptor. Fluxul real de date poate fi informații transmise printr-un cablu între două dispozitive, scrisori trimise prin poștă, benzi magnetice sau dischete transferate de la un computer la altul și așa mai departe.

În diagramă, fluxul de date este reprezentat printr-o linie care se termină cu o săgeată care arată direcția fluxului. Fiecare flux de date are un nume care reflectă conținutul său.

La construirea diagramelor DFD, se obișnuiește să se utilizeze următoarele recomandări:

1.Puneți pe fiecare diagramă de la 3 la 6÷7 procese.

3. Încercați să nu folosiți abrevieri.

4. Nu aglomerați diagramele cu detalii irelevante.

9.3. Diagrame entitate-relație

Notația ERD pentru construirea diagramelor entitate-relație include nouă componente principale.

Cel mai adesea, modelele de informații de acest tip sunt folosite pentru a proiecta structura unei baze de date.