Ақпарат жүйесіндегі дерек ағынының графикалық бейнелеуі
Data-flow diagram
Дерек ағыны диаграммасы – ақпарат жүйесіндегі деректердің қозғалысын көрсетеді. Кіріс-шығыс, процестерді түсіндіреді, бақылау ережесі жоқ. SEO үшін маңызды!
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Ақпараттық жүйе арқылы деректердің "ағынының" графикалық бейнесі
Graphical representation of the "flow" of data through an information system
Деректер ағыны диаграммасы – процесс немесе жүйе (әдетте ақпараттық жүйе) арқылы деректердің ағынын бейнелеу тәсілі. DFD әрбір элементтің кірістері мен шығыстары туралы, сондай-ақ процестің өзі туралы ақпаратты ұсынады. Деректер ағыны диаграммасында бақылау, шешімдер ережелері мен циклдар жоқ. Деректерге негізделген нақты операцияларды блок-схема арқылы көрсетуге болады. Деректер ағыны диаграммаларын бейнелеу үшін бірнеше нотациялар бар. Жоғарыда көрсетілген нотация 1979 жылы Том ДеМарко құрылымдық талдаудың бір бөлігі ретінде сипаттаған. Әрбір дерек ағыны үшін процесте кем дегенде бір соңғы нүкте (көзі және/немесе мақсаты) болуы керек. Процестің нақтырақ бейнесін басқа деректер ағыны диаграммасында көрсетуге болады, ол осы процесті кіші процестерге бөледі. Деректер ағыны диаграммасы – құрылымдық талдау мен деректерді модельдеу құралының бір бөлігі. UML қолданғанда, әдетте белсенділік диаграммасы деректер ағыны диаграммасының орнын басады. Деректер ағыны жоспарының ерекше түрі – нысаналық деректер ағыны жоспары. Деректер ағыны диаграммаларын кері Петри желілері деп қарастыруға болады, себебі мұндай желілердегі орындар деректер сақтаудың семантикасына сәйкес келеді. Сол сияқты, Петри желілерінен өтудің семантикасы және деректер ағыны мен деректер ағыны диаграммаларынан функциялар эквивалентті деп есептелуі керек.
A data flow diagram is a way of representing a flow of data through a process or a system (usually an information system). The DFD also provides information about the outputs and inputs of each entity and the process itself. A data flow diagram has no control are no decision rules and no loops. Specific operations based on the data can be represented by a flowchart. There are several notations for displaying data flow diagrams. The notation presented above was described in 1979 by Tom DeMarco as part of structured analysis. For each data flow, at least one of the endpoints (source and / or destination) must exist in a process. The refined representation of a process can be done in another data flow diagram, which subdivides this process into sub processes. The data flow diagram is a tool that is part of structured analysis and data modeling. When using UML, the activity diagram typically takes over the role of the data flow diagram. A special form of data flow plan is a site oriented data flow plan. Data flow diagrams can be regarded as inverted Petri nets, because places in such networks correspond to the semantics of data memories. Analogously, the semantics of transitions from Petri nets and data flows and functions from data flow diagrams should be considered equivalent.
Тарих
DFD белгісі бастапқыда ұйымдардағы жұмыс процесін модельдеу үшін операциялық зерттеулерде, ал компьютер ғылымында есептеулердегі кіріс-шығыс ағынын модельдеу үшін қолданылған граф теориясына негізделген. Оны алғаш Ларри Константин ұсынды, ал Эдвард Юрдон, Том ДеМарко, Крис Гейн және Триш Сарсон оны кеңінен танымал етті. Олар диаграмма жасау техникасын әртүрлі белгілермен және деректер сөздігін пайдалану арқылы байытты. DFD негізгі деректер ағынын құжаттауға немесе дерек ағыны тұрғысынан жаңа, жоғары деңгейдегі дизайнды зерттеуге көмектесті.
The DFD notation draws on graph theory, originally used in operational research to model workflow in organizations, and in computer science to model the flow of inputs and outputs across computations. It was first proposed by Larry Constantine, and popularized by Edward Yourdon, Tom DeMarco, Chris Gane and Trish Sarson, who enriched the diagramming technique with different notations, data dictionary practices DFDs were useful to document the major data flows or to explore a new high level design in terms of data flow.
DFD құру ережесі
Субъектінің атауы қосымша түсіндірмелерсіз түсінікті болуы керек. DFD – жүйе пайдаланушыларымен сұхбаттасу негізінде талдаушылар құратын жүйе. Ол бір жағынан жүйе әзірлеушілер, екінші жағынан жоба мердігерлері үшін жасалғандықтан, субъектілердің атаулары модельдік салаға немесе кәсіби немесе жаңадан бастаған пайдаланушыларға сәйкес болуы тиіс. Субъектінің атауы жалпылама (нақты тұлғалар сияқты, қызметті орындайтын адамдардан тәуелсіз) болуы керек, бірақ субъектіні нақты анықтауы тиіс. Процестерді жеңілдетіп картаға түсіру және нақты процестерге сілтеме жасау үшін нөмірленуі керек. Нөмірлеу ретсіз болғанымен, DFD-нің барлық деңгейлерінде дәйектілік сақталуы қажет (DFD иерархиясын қараңыз). DFD түсінікті болуы керек, сондықтан бір DFD-дегі процестердің максималды саны 6-дан 9-ға дейін, ал ең аз саны 3 болуы ұсынылады. Бірақ контекстуалдық диаграмма деп аталатын ерекше жағдай бар, онда бір ғана процесс модельдік жүйені және жүйе байланысатын барлық терминаторларды көрсетеді.
Entity names should be comprehensible without further comments. DFD is a system created by analysts based on interviews with system users. It is determined for system developers, on one hand, project contractor on the other, so the entity names should be adapted for model domain or amateur users or professionals. Entity names should be general (independent, e. g. specific individuals carrying out the activity), but should clearly specify the entity. Processes should be numbered for easier mapping and referral to specific processes. The numbering is random, however, it is necessary to maintain consistency across all DFD levels (see DFD Hierarchy). DFD should be clear, as the maximum number of processes in one DFD is recommended to be from 6 to 9, minimum is 3 processes in one DFD. The exception is the so called contextual diagram where the only process symbolizes the model system and all terminators with which the system communicates.
DFD сәйкестігі
DFD жүйелік-тұлғалық қатынас диаграммасы, күйлер ауысу диаграммасы, деректер сөздігі және процесс спецификациясы модельдері сияқты жүйенің басқа модельдерімен үйлесімді болуы керек. Әрбір процесс атауға, кіріске және шығысқа ие болуы тиіс. Әрбір ағынның атауы болуы керек (Ағын ерекшелігін қараңыз). Әрбір деректер қоймасында кіріс және шығыс ағындары болуы керек. Кіріс және шығыс ағындары бір DFD-де көрсетілмеуі мүмкін, бірақ олар бірдей жүйені сипаттайтын басқа DFD-де болуы керек. Жүйемен байланысатын жүйеден тыс (сыртқы сақтау) қойма – ерекше жағдай.
DFD must be consistent with other models of the system—entity relationship diagram, state transition diagram, data dictionary, and process specification models. Each process must have its name, inputs and outputs. Each flow should have its name (exception see Flow). Each Data store must have input and output flow. Input and output flows do not have to be displayed in one DFD—but they must exist in another DFD describing the same system. An exception is warehouse standing outside the system (external storage) with which the system communicates.
DFD иерархиясы
DFD-ны түсінікті ету үшін (яғни, тым көп процестер болмауы үшін) көп деңгейлі DFD-тар құруға болады. Жоғары деңгейдегі DFD-тар аз егжей-тегжейлі болады (төменгі деңгейлердегі егжей-тегжейлі DFD-тарды жиынтықтайды). Контексттік DFD иерархиядағы ең жоғары деңгейде орналасады (DFD құру ережелерін қараңыз). «0-деңгей» деп аталатын DFD 0 процестерді нөмірлеуден басталады (мысалы, 1-процесс, 2-процесс). Одан кейін, «1-деңгей» деп аталатын DFD 1 нөмірлеуді жалғастырады. Мысалы, 1-процесс DFD-ның алғашқы үш деңгейіне бөлінеді, олар 1.1, 1.2 және 1.3 деп нөмірленеді. Сол сияқты, 2-деңгейдегі (DFD 2) процестер 2.1.1, 2.1.2, 2.1.3 және 2.1.4 деп нөмірленеді. Деңгейлердің саны модельдік жүйенің мөлшеріне байланысты. DFD 0 процестерінің ыдырау деңгейлерінің саны бірдей болуы міндетті емес. DFD 0 жүйенің ең маңызды (жинақталған) функцияларын қамтиды. Ең төменгі деңгейге шамамен бір А4 беттік процесс спецификациясын жасауға мүмкіндік беретін процестер кіруі керек. Егер мини спецификация көлемді болса, онда оны бірнеше процеске бөлу үшін қосымша деңгей құру орынды. DFD-ның бүкіл иерархиясын анық көрсету үшін тік (қима) диаграмма жасауға болады. Деректер қоймасы алғаш пайдаланылған ең жоғары деңгейде де, барлық төменгі деңгейлерде де көрсетіледі.
To make the DFD more transparent (i. e. not too many processes), multi level DFDs can be created. DFDs that are at a higher level are less detailed (aggregate more detailed DFD at lower levels). The contextual DFD is the highest in the hierarchy (see DFD Creation Rules). The so called zero level is followed by DFD 0, starting with process numbering (e. g. process 1, process 2). In the next, the so called first level—DFD 1—the numbering continues For example, process 1 is divided into the first three levels of the DFD, which are numbered 1.1, 1.2, and 1.3. Similarly, processes in the second level (DFD 2) are numbered 2.1.1, 2.1.2, 2.1.3, and 2.1.4. The number of levels depends on the size of the model system. DFD 0 processes may not have the same number of decomposition levels. DFD 0 contains the most important (aggregated) system functions. The lowest level should include processes that make it possible to create a process specification for roughly one A4 page. If the mini specification should be longer, it is appropriate to create an additional level for the process where it will be decomposed into multiple processes. For a clear overview of the entire DFD hierarchy, a vertical (cross sectional) diagram can be created. The warehouse is displayed at the highest level where it is first used and at every lower level as well.