Part II: 構造化設計手法と
設計の表現
2. データフロー設計:
データフロー図
データフロー図とは、以下の特徴を持つ設計言語である。
抽象設計に適用する。特に、プログラムの構造を設計
するには、適切な言語である。)
構造化設計手法である。
データの流れを重視する。
データ駆動の設計。つまり、データがプログラムの操作
の間にどのように流れていることを定義するによって、
プログラムの設計を行う方法である。
例えば、次の数式を計算するプロセスを
データフロー図で表現する):
(a + b) * (c + d) + f
a
Add1
b
sum1
f
p
Multiply
sum2
c
Add2
d
res
Add3
データフロー図の同意語 :
バブル図(
Bubble chart)
DFD (Data Flow Diagram)
バブル図(
Bubble diagram)
プロセスモデル(Process model)
機能モデル(
Function model)
適用の応用領域:
操作がデータより重要であるシステムの設計に
有効である。
紹介する内容:
DFDの部品
プロセス分解
階層的なDFDの構築の指針
2.1 DFDの部品
DFDは四種類の部品を持つ。
プロセス(process)
データフロー又はデータの流れ(Data flow)
データストア(Data store)
ターミネーター(Terminator)
2.1.1 プロセス
プロセスとは、入力により出力を生成する操作である。
プロセスの同意語:
バブル(Bubble)
機能(Function)
変換(Transformation)
操作(Operation)
プロセスを図で表す:
Name
例えば,
Arrange
Lectures
重要: データフローの変換を
表すプロセスだけが意味がある。
このため、データフローに連接して
いないプロセスは、意味がない。
Register
Projects
プロセス名の付け方。プロセス名は、次のように
作成できる。
動詞ー目的語の語句。
一定の機能を持つ組織の名前又は実体名。
重要: プロセス名は、そのプロセスの機能を示す
べきである。
2.1.2 データフロー
データフルーとは、データ項目の移動を表すもの
である。
データフローを図で表す。
a
ここで、aはそのデータフロー名である。
データフロー名の付け方。データフローに次のよう
に名前を付ける。
名詞語句。
データの情報を示すべきである。
データフロー名は、一般に小文字英字で表す。
データフローはプロセスと一緒に使われ、プロセス
のデータフローを転換する機能を表す。
Sort
Records
sorted-records
qualified-student-records
study-records
Divide
Records
failed-student-records
Give
Recommendations
records-withrecommendations
データフローについての要点
データフローは、一種類の情報を表す。
データフローは、複合なデータ項目の表示が
できる。
データフローは、方向を示す。
データフローは、分岐又は収束することができ
る。
例えば,
student-records
Faculty
Office
University
Student
Office
Professor
分岐データフロー
収束データフロー
Provide
Student
Data
student
Provide
Professor
Data
professor
administrator
Provide
Administrator
Data
Classify
Data
classified-data
データフローは、手続き的な情報を示していない。
例えば、次のDFDは、どういう意味を示して
いるのか。
a
c
P
b
d
e
2.1.3 データストア
データストアは、動かない状態の一つ又は幾つか
のデータ項目を表す。
例えば, file, databaseは、データストアとして
使われる。
データストアを図で表す。二つの可能性がある。
(a) データストアに名前だけを挙げる。
(b) データストアに名前と番号を挙げる。
n a m e
(a )
n
n a m e
(b )
データストアの使い方:
students
Faculty
Office
Professor
sorted-records
study-records
データストアについての要点:
データフローを通じてプロセスに結ぶ。
プロセスからデータストアへのデータフローは、更新の意味を
表す。
データストアからプロセスへのデータフローは、データストアの
情報を読み込むの意味を表す。
データストアとプロセスの間のデータフルーには、
名前を付けるか、付けないかが構わない。
データストアは受動的である。
2.1.4 ターミネーター
ターミネーターとは、プログラムシステムと交信する外部
の実体である。
例えば、人、組織、政府機関などは、ターミネーターと成
れる。
ターミネーターを図で表す。
Name
ターミネーターの事例:
Ministry of Education
student-enrollment-data
enrollment-data
request-for-study-records
University
Information
System
Parents
available-study-records
ターミネーターが含まれるDFDは、文脈図(context
diagram)と呼ばれる。
ターミネーターについての要点:
ターミネーターは、設計されているプログラムの
外のものである。
設計者は、ターミネーターの内容や働き方など
を変えることができない。
ターミネーターらの間の関係は、DFDに表され
ない。
Exercise 2.1
以下の機能を持つATMシステムの設計をDFDで表現
しなさい。
“ATMシステムは、Receive-Request, Check-Password, Withdraw,
およびShow-Balanceという四つのプロセスを使う。
プロセスReceive-Request は、「引き出す」又は「残高を見せる」という
命令を受け、その命令をプロセスWithdraw 又はShow-Balance へ送
る。
同時に、プロセスCheck-Password へも入力されたカードのIDと
password を検査する指示を送る。
Check-Password からShow-Balance とWithdraw
にIDとpasswordが確認されたメセッジを送る。
Withdraw は、customer に引き出す金額を要請、
もしその金額が口座の残高より小さいなら、その
金額の金を出力する。
皆プロセスからデータストアaccountsにアクセス
または更新する必要がある。
Show-Balanceは口座の残高を出力する。“
2.2 プロセス分解
プロセス分解の必要性:
プロセスをDFDに分解することにより、そのプロ
セスがどのように自分の入力から出力への変換
を行ったということがもっと詳しく理解できす。
一つレベルのDFDの複雑度を減少する。
並列的チームワークを支える。
分解の事例:
Personal Expenses Management System は、トップレベル
DFDである。
item-reg
reg-confim
single-item-d
Person
total-exp
all-item-d
item-d
Personal Expenses
Management System
total-amount
Output device
(screen, printer)
items-table
Full names for data flows:
item-reg = item-registration
single-item-d = single-item-data
toatl-exp = toatl-expense
all-item-d = all-item-data
reg-confirm = registration-confirmation
item-d = item-data
total-amount = total-amount
items-table = items-table
プロセスPersonal Expenses Management Systemの
分解されたDFDは、次のスライドで表される。
プロセスCompute Total Expense は、次のDFDに分
解される。
expenses-file
7.2
total-exp
month
7.1
Provide Month
Find All
Related Items
7.3
items-list
Calculate Total
Expense
total-amount
2.3 階層的DFDを描くガイドライン
複雑なプログラムシステムは、階層的なDFDで
表すのが普通である。階層的なDFDを構築するに
は、ガイドラインがある。
次の階層的なDFDらを考えましょう。
b
a
T1
T2
The
System
c
T3
Figure 0 the context diagram
a
d
e
b
2
1
f
h
s
4
3
g
c
Figure 1 the decomposition of process The System
d
h
e
j
2.1
2.2
i
3.1
b
f
3.3
Figure 2
3.2
s
g
2.3
h
k
3.4
l
Figure 3
j
2.2.1
h
x
2.2.2
y
2.2.3
Figure 4
b
ガイドライン
数字を用いて、プロセスとそれの分解された
DFDを結び。例えば, Figure 1 のプロセス 2 は、
Figure 2 のDFD に分解された。そのため、
Figure 2のプロセスらは、数字 2.1, 2.2, および
2.3で表示する。
データストアにアクセスするプロセスの分解され
たDFDにもそのデータストアを適当に使う。例え
ば、プロセス3は、データストアs に書き込むこと
がある。この機能も分解されたDFDに反映され
るはずである。
階層的DFDを一般にトップーダウン設計により作
成する。しかし、ある場合は、階層的DFDを
“middle-out” という方法で構築する。この方法で
は、先ず設計者が一番分かっているかつ一番重
要な部分からDFDを設計する。その後、プロセス
の分解およびDFDの統合によって、全体の階層
的DFDを完成する。
一つレベルのCDFDの規模としては、約六つのプ
ロセスを含むのは普通である。
階層的DFDには、構造の整合性を守ることが重
要である。階層的DFDの構造の整合性によると、
プロセスの入力と出力データフローは、必ずそれ
の分解されたDFDのプロセスに使われる。例え
ば、Figure 0 のトップレベルプロセスThe System
には、一つの入力データフロー a および二つの
出力データフロー bとcがある。それらのデータフ
ローは、そのプロセスの分解したDFDに使われ
ている。
買い物のICカードシステムの事例
機能要求:
(1)ICカードを認識できる。
(2)ICカードを使うためにパースワードが必要。
(3)ICカードで買った物に対して支払い場合、直接
に自分の銀行口座から引き出す。
(4)
支払いの金額は、自分の銀行口座の残高より
大きい場合、支払いが出来ない。
買い物のICカードシステムのトップレベルDFD
プロセスPay_from_Bank_Accountの分解
Exercise 2.2
練習問題2.1に設計されたATMシステムの階層
的DFDを描きなさい。そのため、“middle-out” アプ
ローチの利用を薦め。例えば、プロセスWithdrawを
二つのプロセスCheck-Amount とDispense-Cashを
含むDFDに分解される。また、プロセスWithdrawを
含むDFDを一つの高いレベルのプロセスに抽象で
きる。
Small project
階層的なDFDを用いて、「個人情報管理システム」
を設計しなさい。そのシステムは次の機能を提供
する。
個人費用の管理
個人授業データの管理
本の情報の管理
自分の情報によりその情報管理システムを設計し
なさい。
ダウンロード

Part II: 構造化設計手法と 設計の表現