Part II: Structured design methods and representations （構造化設計手法と設計の表現）

2. Data-driven design notation: Data Flow Diagrams （データフロー図） Data flow diagrams are a tool for program design, with the following features:(データフロー図は、以下の特徴を持つ 設計ツールである） It is suitable for abstract design, since it offers an intuitive and comprehensible notation for describing architecture of program systems.（抽象設計に適用する） It is a structured methods, supporting top-down, modular, and hierarchical designs.（構造化設計手法である） It concentrates on data flows among processes rather than on control flows among processes. （データの流れに重視する） It is a data-driven approach to program design.（データ駆動の設計）

Let us first have a look at a simple example:（事例） The data flow diagram for evaluating the arithmetic expression: （次の数式を計算するプロセスをデータフロー図で表現する）(a + b) * (c + d) + f

Synonyms of Data Flow Diagrams:（データフロー図の同意語 ） Bubble chart（バブル図） DFD (the abbreviation for Data Flow Diagram) Bubble diagram（バブル図） Process model（プロセスモデル） Function model（機能モデル） Application domain:（適用なドメイン） DFD is suitable for the design of operational systems in which the functions of the systems are more important and more complex than data that the system deals with. For example, banking systems, customer service systems, railway ticket systems, and so on. （操作がデータより重要であるシステムの設計に有効である）

The contents to be introduced:（紹介する内容） The components of DFDs（ＤＦＤの部品） Decomposition of processes（プロセス分解） Guidelines for drawing hierarchical DFDs（階層的なＤＦＤの構築の指針）

2.1 The components of DFDs （ＤＦＤの部品） There are four kinds of components in DFDs: （ＤＦＤは四種類の部品を持つ） Process(プロセス） Data flow(データフロー又はデータの流れ） Data store（データ倉庫） Terminator（ターミネーター）

2.1.1 The process （プロセス） A process realizes a transformation from inputs to outputs. It represents an operation, and once executed it performs some function in terms of consuming its input and generating its output. （プロセスは入力により出力を生成する操作である） Synonyms of process:（プロセスの同意語） Bubble（バブル） Function（機能） Transformation（変換） Operation（操作）

The graphical representation:（図で表す） For example, Important: processes are meaningful only when they model a transformation of data flows. That is, without connecting to data flows, processes are not useful. （データフローの変換を表すプロセスだけが意味がある）

Guidelines for naming processes: （プロセス名の付け方） A process can be named in one of the following two ways: Verb-object phase, such as Arrange Lectures, Register Projects. （動詞ー目的語の語句） The name of an organization or entity that processes data. For example, Student Office, Addition, Subtraction. （組織名又は実体名） Important: the name of a process should indicate the potential function of the process. This would help improve the readability of DFDs. （プロセス名は、そのプロセスの機能を示すべきである）

2.1.2 The data flow (データフロー） A data flow describes a data item moving from one part to another of the system.（データフルーはデータ項目の移動を表すものである） The graphical representation: （図で表す） Where a is the name of this data flow.（aはそのデータフロー名である）

Guidelines for naming data flows:（データフロー名の付け方） The name should normally be a noun phrase, for example, student, book, etc.（名詞語句） The name should indicate the type of the information. For example, student, book. （データの情報を示すべきである） The name is usually written in lower case letters.

Data flows are usually used together with processes; that is, they are used to connect processes, indicating that data items are moving from one process to another. （データフローはプロセスと一緒に使われる）For example,

Important points about data flows （データフルーについての要点 ） A data flow should carry one type of information. We should not name a data flow as: student and professor and administrator. （データフルーは一種類の情報を表す） A data flow can carry a composite data item. For example, university-member, which may consists of the three components: student, teacher, and administrator.（データフローは複合なデータ項目の表示ができる） Data flows show directions.（データフローは方向を示す） Data flows allow diverging and converging. （データフローは分岐 又は収束することができる）

For example, Diverging data flow

Converging data flows

Data flows do not answer many procedural questions Data flows do not answer many procedural questions. For example, whether, when, and how input data flows of a process cause an execution of the process are uncertain. Whether, when, and how the process produces its output data flows are not defined. （データフローは手続き的情報を示していない）

2.1.3 The store （データ倉庫） A store describes a single or a set of data items at rest. （データ倉庫は動かない状態の一つ又は幾つかのデータ 項目を表す） For example, a file, database can be modeled as a store. The graphical representation: one of the following representations can be used:（データ倉庫を図で表す） representation (a) only gives the name of the store, while (b) gives both the name and the number that is used to reference the store in a DFD involving many stores.

The use of stores: （データ倉庫の使い方） Important points about stores:（データ倉庫の要点) Stores are connected to processes by data flows. (データフローを通じてプロセスに結ぶ） A data flow to a store from a process: it means a writing or updating of the store.（プロセスからプロセスへのデータフローは更新の意味を表す） A data flow from a store to a process: it means a read of the store by the process. （データ倉庫からプロセスへのデータフローは倉庫の情報を読まれるの意味を表す）

The data flows connected to a store can either be labeled or unlabeled; they have no substantial difference in semantics.（データ倉庫とプロセスの間のデータフルーに名前を付けるか付けないかが構わない） The store is passive; data does not travel through the store unless a process explicitly asks for them. （データ倉庫は受動的である）

2.1.4 The terminator （ターミネーター） A terminator is an external entity with which the program system communicates. （ターミネーターはプログラムシステムと交信する外部の実体である） Typically, a terminator is a person or a group of people, an outside organization, or government agency. （例えば、人や組織や政府機関などはターミネーターと成れる） The graphical representation:（図で表す）

Example of terminator: A DFD involving terminators is called Context Diagram.（ターミネーターが含まれるDFDは文脈図と呼ばれる）

Important points about terminators:（ターミネーターについての要点） They are outside the program under design.（ターミネーターは設計されているプログラムの外のもの） The designer cannot change the contents of terminators or the way they work.（設計者は、ターミネーターの内容や働き方などを変えることができない） Relations between terminators are not shown in the DFD of the program system.（ターミネーターらの間の関係はDFDに表されない）

Exercise 2.1 Design a DFD for an ＡＴＭ（Automated Teller Machine) system with the following functions:（以下の機能を持つ ATMシステムの設計をDFDで表現しなさい） “The ATM system uses four processes: Receive-Request, Check-Password, Withdraw, and Show-Balance. （ATMシステムは四つのプロセスを使う。） 　Process Receive-Request takes a request for either withdrawing or showing the 　balance, and sends this request to either process Withdraw or Show-Balance. （プロセスReceive-Request は、「引き出す」又は「残高を見せる」という命令を受け、その命令をプロセスWithdraw 又はShow-Balance へ送る）。 　At the same time, it also sends an instruction to Check-Password to check whether the input card and password are correct. （同時に、プロセスCheck-Password へも入力されたカードのIDとpassword を検査する指示を送る）

　Check-Password then sends a confirmation to both Show-Balance and Withdraw.（ Check-Password からShow-Balance and Withdraw にIDとpasswordが確認されたのメセッジを送る） 　 Withdraw requests an amount from the customer, and ouptuts the amount of the money if it is within the range of the account balance. （ Withdraw はcustomer に引き出すの金額を要請、もしその金額が口座の残高より小さいなら、その金額の金を出力する） 　To determine whether the requested amount is small enough to be withdrawn, the system needs to keep the file accounts that allows all the related processes to access. （皆プロセスからアクセスできるデータ倉庫accountsが必要である） 　Show-Balance outputs the present balance. （ Show-Balanceは口座の残高を出力する）“

2.2 Decomposition of processes （プロセスの分解） Motivation：（動機） Refine an abstract process into a more detailed DFD so that we can understand how the input data flows of the process are transformed into its output data flows.（プロセスをDFDに分解することにより、そのプロセスがどのように自分の入力から出力への変換を行ったということがもっと詳しく分かられる） Reduce the complexity of the entire system by dividing it into small, manageable processes.（システムの複雑性を減少する） Support teamwork concurrently; that is, different people working on the same system may design different processes at the same time.（並行なチームワークを支える）

Example of decomposition: the context diagram of a Personal Expenses Management System is the top level DFD:

The decomposition of process Personal Expenses Management System is the next lower level DFD, as shown on the next slide.（プロセスPersonal Expenses Management Systemの分解されたDFDは次のスライドで表される）

The decomposition of process Compute Total Expense is the following DFD: （プロセスCompute Total Expense は次のDFDに分解される）

2.3 Guidelines for drawing hierarchical DFDs （階層的DFDを描くガイドライン） A complex program system is usually designed as a hierarchical DFDs. Such a hierarchical DFDs is constructed by means of decompositions of high level processes. There are some guidelines for drawing hierarchical DFDs that help to ensure the quality of the hierarchical DFDs. Consider the abstract description of a hierarchical DFDs on the next slide. （次の階層的DFDらを考えましょう）

Guidelines Use numbers to relate a process to its decomposition, which is a lower level DFD. （数字を用いて、プロセスとそれの分解されたDFDを結び）For example, process 2 in Figure 1 is decomposed into the DFD in Figure 2, so the processes occurring in this DFD are numbered as 2.1, 2.2, and 2.3. Show stores in the decomposition of a process that is connected to the stores. （データ倉庫にアクセスするプロセスの分解されたDFDにもそのデータ倉庫を適当に使う）For example, since process 3 writes to store s, the detail of writing to this store by the low level processes in the decomposition of process 3 must be shown.

A hierarchical DFDs is usually constructed using top-down approach A hierarchical DFDs is usually constructed using top-down approach. （階層的DFDを一般にトップーダウン設計により作成する）That is, the program system is first abstracted into a top level context diagram, and then developed further by decomposing processes. This decomposition process continues until sufficient functions of the system are designed. However, this does not mean that top-down approach always works well. In some cases “middle-out” approach can be more effective. That is, you first start with designing the middle level DFDs which you know the best, and then develop them by both decomposing involved processes and synthesizing those DFDs into high level DFDs.

The number of processes in a DFD of any level should be kept around 6, which is usually comfortable to manage, according to industrial experience. （一つレベルのCDFDの規模としては、約六つのプロセスを含むのは普通である） The structural consistency of the hierarchical DFDs must be ensured. （階層的DFDには、構造の整合性を守ることが重要である）The structural consistency requires: the data flows coming into and going out of a process at one level must appear as the data flows coming into and going out of an entire figure at the next lower level that describes that process. （階層的DFDの構造の整合性によると、プロセスの入力と出力データフローは、必ずそれの分解されたDFDのプロセスに使われる）For example, the top level process The System in Figure 0 of the abstract DFD hierarchy has one input data flow a, and two output data flows b and c, so a is the input data flow to the decomposed DFD in Figure 1 and both b and c are its output data flows.

Input-only and output-only processes must be used with care Input-only and output-only processes must be used with care. （入力だけ又は出力だけを持つプロセスを設計するとき、十分に注意することが必要である）An input-only process means that the process does not produce any output data flow that is useful within this system, while an output-only process means that the process produces output data flows without the need of any input data flow (e.g., receive values from input devices, or create data flows by initializing variables).

Exercise 2.2 Draw a hierarchical DFDs for the ATM system described in Exercise 2.1. The way suggested to build the DFD hierarchy is to take the “middle-out” approach. That is, on the one hand, synthesize the DFD for Exercise 2.1 into a context diagram, and on the other hand, decompose some of the processes in the DFD. For example, Withdraw can be realized by two processes: Check-Amount and Dispense-Cash. （練習問題２．１に設計されたATMシステムの階層的DFDを描きなさい。そのため、 “middle-out” アプローチの利用を薦め。例えば、プロセスWithdrawを二つのプロセスCheck-Amount と Dispense-Cashを含むDFDに分解される。また、プロセスWithdrawを含むDFDを一つの高いレベルのプロセスに抽象できる。）

Small project Design a “Personal Information Management System” using DFDs. This system must contain the following functions: （階層的なDFDを用いて、「個人情報管理システム」を設計しな さい。そのシステムは次の機能を提供する。） Personal Expenses Management（個人費用の管理） Course Data Management（個人授業データの管理） Books Management（本の情報の管理） The system should be designed based on your own information and functional requirements. There is no unique answer to this problem. （自分の情報に よりその情報管理システムを設計しなさい。）