日本ソフトウェア科学会第 34 回大会 (2017 年度) 講演論文集

ソースコードの変更によるデータフロー図の差異検出
手法
長岡 源樹

上田 賀一

堀田 大貴

高橋 竜一

ソフトウェアの保守作業において設計書をもとにソフトウェアの概要を理解できることが望ましい．しかし，軽微な保守作業ではソースコードを変更しても，この変更を設計書に反映しないまま放置することも多い．これにより設計書とソースコードの対応が次第に取れなくなり，設計書によるソフトウェアの理解は困難になってしまう．そこで，ソースコードの変更を設計書に反映させる工程を支援することで，保守作業を支援することを考える．今回は業務システムの設計時に使用されることが多いデータフロー図を対象に，ソースコードの変更を設計書に反映させる手法を提案する．本手法は，初期開発時のデータフロー図とソースコードの対応関係から，変更後のソースコードの差分をデータフロー図に反映させる．これにより変更をデータフロー図に反映させ易くなり，保守作業のコストの削減が期待される．

It is desirable to be able to understand the outline of the software based on the design document in software maintenancework. However, in a minor maintenance work, even if you change the source code, you often leave this change without reflecting it in the design document. As a result, correspondence between design document and source code becomes gradually
impossible, and it becomes diﬃcult to understand software by reading design document. Therefore, we consider supporting
the maintenance work by supporting the process of reflecting the change of the source code in the design document. In thispaper, we propose a method for reflecting change of source code in design document, for data flow diagram which is often
used when designing business system. In this approach, the diﬀerence of source code after change is reflected in the data
flow diagram from the correspondence relationship between the data flow diagram and the source code which can be assumed
that correspondence can be taken at the time of initial development. This makes it easy to reflect changes in the data flow
diagram, and it is expected that the cost of maintenance work will be reduced.にしたり，どのような機能があり，仕様はどうなって1 はじめにいるのかを明確にするため，UML やデータフロー図

1. 1 背景等を用いて設計書を作成する．

近年におけるソフトウェア開発は，ソフトウェアの保守工程でバグの修正や機能拡張を行う場合，既保守を行う割合が多い．保守工程では設計書を元に存のソフトウェアが何をするためのソフトウェアなのバグの修正や機能修正，機能拡張等が行われる．コスか，どのような仕様なのかを理解しなければならな

トの割合では要件分析 3%，基本設計 3%，詳細設計

い．理解するためには，ソースコードを読んだり，設5%，実装 7%，製品段階では運用と保守 67%，テス計書を読む必要がある．ソースコードは人には理解し

ト 15%とされている [5].

にくいものであるため，一般的にはまず設計書を読

初期開発時には，まずソフトウェアの設計をし，設んでソフトウェアの概要を理解する．次にソースコー計書に沿ってソースコードを作成する．要求分析時やドと設計書の変更を行う．しかし，軽微な保守作業で設計時には，ソフトウェアに何をさせたいのかを明確はソースコードのみ変更し，この変更を設計書に反映しないまま放置することも多い．これにより設計Detection of diﬀerence in data flow diagram due to sourcecode change
Motoki Nagaoka, Yoshikazu Ueda, Hiroki Horita, Ryuichi
Takahashi, 茨城大学, Ibaraki University.

書とソースコードの対応が次第に取れなくなり，設計書からソフトウェアを理解することが困難になると，後の保守作業に支障が出てしまう．

図1

データフロー図の例
図2

業務アプリケーションの設計にデータフロー図が良コンテキストを理解し 図 3

コンテキストを理解したコールグラフ

ないコールグラフ

く使われている．データフロー図はデータがどのように変化していくかを表現した図である．

円 (図 1 の プロセス ) で表す．データの処理・変換を示し，入力データを処理し，結果となる

1. 2 目的
業務アプリケーションの設計に良く使われるデータデータを出力するもの．
データフロー

フロー図に注目し，ソースコードの変更をデータフ

矢印 (図 1 の データ 1 等) で表す．各要素間のロー図に反映させることで設計書の保守作業を支援

データの流れを表す．データの流れる方向を矢印する．

で表し，データフローに名前をつけてデータを識

ソースコードの情報から完全なデータフロー図を別する．

作成することは困難であるため，データフロー図上でデータストアの変更を提示し，開発者がデータフロー図を変更し易2 本の平行線 (図 1 の データベース ) で表す．

くすることを目的とする．

データの格納場所を示す．

本研究では，次の手法を提案する．まず始めに，初外部実体期開発で作られたデータフロー図，これと対応が取四角形 (図 1 の 発生源等) で表す．システムれているソースコードを利用し，データフロー図と外部に存在するものであり，外部の情報源や外部ソースコードの対応関係を調べる．このときメソッドへの情報の出力先を示す．

間データ依存グラフを作成し，コールグラフと Graph

Edit Distance の情報を用いて対応付けを行う．次に，2. 2 コールグラフ

保守工程で変更されたソースコードを解析し，元のコールグラフとは，プログラムのメソッド同士の呼ソースコードとの差異を検出する．最後に，元のソーび出し関係を表現した有向グラフである．各ノードがスコードと変更後のソースコードの差異から，変更箇メソッドを表現し，各エッジ (f, g) はメソッド f がメ所をデータフロー図に反映させる．

ソッド g を呼び出すことを示す．
コールグラフは様々な形で表現できる．例えば図 22 関連知識のコンテキストを理解したコールグラフ (各メソッド

2. 1 データフロー図（DFD）

についてメソッドが呼び出されるコールスタックごデータフロー図（DFD）[2] は，情報システムのデーとに別々のノードを持つグラフ) や，図 3 のコンテキ

タの流れをグラフィカルに表現する図である．システ

ストを理解しないコールグラフ (各メソッドについてム設計段階の初期に描かれることが多い [1]. また，構ノードを 1 つしか持たないコールグラフ) 等が挙げら造化分析で利用され，業務上のシステムの設計時に使れる．

われることが多い．
データフロー図の構成要素を以下に示す．
プロセス

2. 3 Graph Edit Distance
Graph Edit Distance(以下 GED とする) とは，2 つのグラフの類似性を表すものである．片方のグラフを編集してもう片方のグラフを作り出すときの，編集コストの最小値である．グラフ g1 と g2 の GED を，GED(g1 , g2 ) と表す．
グラフの編集操作には以下のものがある．

• ノードの追加• ノードの削除

図4• ノードの変更提案手法の概要（DFD）• エッジの追加

3. 1. 1 データ依存関係• エッジの削除

メソッド間のデータ依存関係を定義する．次のと• エッジの変更

き，データ依存関係があるものとする．
メンバ変数への代入・参照

3 提案手法メソッド f がメンバ変数 v へ値を代入している

本研究の目的は，ソースコードの変更をデータフ

メソッド g がメンバ変数 v の値を参照している

ロー図 (以下 DFD とする) に反映させることで設計書

以上の 2 つを満たす時，メソッド f からメソッドの保守作業を支援することである．プログラムのみ変更されたソフトウェアに対し，変更前の DFD とソーg へのデータ依存関係があるとする．
メソッドへの引数での受け渡し

スコード，変更後のソースコードから，変更前と変更

メソッド f が引数を取るメソッド g を呼び出して後の DFD 上での差異を検出し，変更を DFD に反映いる場合，メソッド f からメソッド g にデータ依させる．

存関係があるとする

本手法の概要を DFD で表したものを図 4 に示す．

メソッドの返り値での受け渡し

本手法では，ソースコードから DFD を作成するため，メソッド f が値を返すメソッド g を呼び出していメソッド間のデータ依存関係をグラフで表したメソッる場合，メソッド g からメソッド f へのデータ依ド間データ依存グラフ (3. 1 節) を利用する．

存関係があるとする

初めに変更前のソースコードのメソッド間データ依存グラフを作成 (3. 2 節) し，このグラフのノードと3. 2 メソッド間データ依存グラフの作成

DFD 上のノード (プロセス) との対応関係を求める

ソースコードの静的解析によりデータ依存関係を(3. 3 節)．次に，変更後のメソッド間データ依存グラ解析し，メソッド間データ依存グラフ G を作成する．

フを作成し，このグラフと変更前のグラフとの差異を

3. 1. 1 節でのデータ依存関係を見つける毎に，グラフ検出する (3. 4 節)．最後に，このメソッド間データ依G にノードとエッジを追加していく．

存グラフ上での差異を DFD に反映させる (3. 5 節)．

3. 3 DFD とメソッド間データ依存グラフの対応
3. 1 メソッド間データ依存グラフ
DFD のプロセスはデータを処理するものであるため，メソッドの組み合わせであると考えられる．そこ付け

3. 2 節で作られたグラフ G と，DFD との対応付けを行う．

で，メソッド間のデータ依存関係を表現したグラフをメソッド間データ依存グラフは DFD に比べて非常定義する．メソッドをノード，データ依存関係（3. 1. 1に抽象度が低く，このままでは DFD との対応が分か節）をエッジとした有向グラフとする．

りにくい．そこで，メソッド間データ依存グラフのノードのグループ化を行い DFD の抽象度に近づけてここでのグラフ G には外部実体・データストアといく．また，ソースコードからではどの部分が外部実の対応付け（3. 3. 1 節）は完了しているものとする．

体・データストアへの入出力なのか特定できないた

纏まった処理を 1 つのノードとみなし，そのノードめ，外部実体・データストアへの入出力の箇所は手動が DFD 上のプロセスと完全に対応していることが理で指定する必要がある．

想となる．コールグラフ上で深い位置にあるメソッド

初めに DFD の外部実体・データストアへの入出力は細かい処理をしていると考えられるため，コールグ箇所と対応付けを行い (3. 3. 1 節)，グラフ G のノー

ラフ上での位置が深いメソッドから順にグループ化

ドをグループ化して DFD の形に近づけ (3. 3. 2 節)，していく．グラフ G のノードは各メソッドに対してDFD のプロセスと対応付ける (3. 3. 3 節) ことで行う．

1 つのノードを持っているため，同様の構造となる図

3. 3. 1 外部実体・データストアとの対応付け

3 のコンテキストを理解しないコールグラフを利用すソースコードを解析するだけでは外部実体・データる．手順を次に示す．

ストアの対応を特定できないため，外部実体・データ

1. コールグラフ Gcall を作成する

ストアとの対応は手動で指定する．ここでは外部実(a) メソッド f の定義内でメソッド g を呼び出

体・データストアとの対応付けに必要となる情報と，している場合,Gcall にノード f からノード g

グラフ G への対応付けの反映方法を述べる．

へのエッジを追加する「DFD 上に現れている全ての外部実体・データス(b) 全てのメソッド定義に対して行うトアと繋がっているデータフロー」に対し，「1 対 1

2. Gcall 上で最も深い位置にあるメソッド（Gcall 上で対応する，そのデータフローを作り出しているメで先頭のノードとの直径が最大のノードのメソッソッド」がソースコード上に存在していることを前ド）を探し，このメソッドをメソッド A とする提とし，この対応関係を必要とする．また，DFD で

3. G 上でメソッド A のノードのデータ依存元のはデータフローの名前は通常一意なものであり，同じノードがある場合，そのノードのうちの 1 つとデータフロー名が存在する箇所はデータストアへのグループ化する入出力の部分のみと考えられる．そのため，それぞれまた，メソッド A が外部実体・データストアとのデータフロー名とデータフローの方向（外部実体・の依存関係が存在する場合でも，この依存関係はデータストアに対して入力か出力か) とそれに対応す存在しないものとして扱う（外部実体・データス

るメソッド名 (パッケージ名，クラス名，メソッド名）トアとのグループ化は行わない）の対応関係の情報があれば外部実体・データストアとの対応付けが行える．
この対応関係をグラフ G に反映するためには，デー

4. G 上でメソッド A のノードのデータ依存元のノードがない場合，データ依存先のノードのうちの 1 つとグループ化する

タフロー名をノードとしたものをグラフ G に追加し，また，メソッド A が外部実体・データストアと対応するメソッドノードへの依存関係のエッジを追加の依存関係が存在する場合でも，この依存関係はすることで行う．

存在しないものとして扱う（外部実体・データス

3. 3. 2 メソッド間データ依存グラフのノードのグループ化

DFD のプロセスはメソッドの組み合わせと考えらトアとのグループ化は行わない）

5. Gcall 上のメソッド A のノードを削除する
6. 2 〜 5 を G のノード数が DFD のプロセス数とれるため，ノードをグループ化する (メソッドをまと一致するまで繰り返すめる) ことで，グラフ G を DFD と対応した形に変形

3. 3. 3 プロセスとの対応付けできると考えられる．グループ化されたノード群を 1

グラフ G のノードと，DFD のプロセスの対応付けつのノードとみなすことでグラフ G の抽象度を上げを行う．DFD と形が最も類似するように対応付けるることができる．

ことで，プロセスとの対応付けできると考えられる．

DFD のプロセスをノード，データフローをエッジと

表1

料理レシピ帳プログラムの規模して，G と DFD の Graph Edit Distance が最小となる

定義されたメソッド数

ように G のノードに DFD のプロセスを割り当てる．

コード行数1,523

グラフ G のノード数と DFD のノード数は一致してファイル数21102おり，エッジの区別はしていない．そのため，GED を求める際のグラフの編集操作はエッジの追加，エッジの削除のみを利用し，それぞれのコストは 1 とする．

3. 4 メソッド間データ依存グラフの差異検出
元のソースコードのメソッド間データ依存グラフ

G p ，変更後のソースコードのメソッド間データ依存
グラフ Gn を比較し，差異を検出する．G p は DFD との対応付けまで行われているものとする．次の手順で差異を検出する．

図5

料理レシピ帳プログラムの DFD

1. 変更後のソースコードからメソッド間データ依存グラフ Gn を作成する

2. Gn のノードを，G p 内で同じグループとなっているノード同士でグループ化する

4. 1 料理レシピ帳プログラム
料理のレシピを管理するプログラムである．レシピの登録と，レシピの検索が行える．レシピの登録で3. グループ化されなかったノードがあった場合，は，レシピ名，材料名，材料の分量，料理の手順を記

そのノードは変更によって生じたことが分かる

入する．レシピの検索では，フリーワードで検索し，レシピ名，材料名，料理の手順の中で，一致する箇所

3. 5 変更後の DFD 作成
3. 4 の差異検出により得られたグラフ Gn を，元のDFD と対応付けされたグラフ G p に基づいて DFD のが存在するレシピを表示する．
この料理レシピ帳プログラムの DFD を図 5，プログラムの規模を表 1 に示す．

プロセスを対応付ける．このグラフ Gn に外部実体・データストアを追加し，プロセスと対応づいたノード

4. 2 メソッド間データ依存グラフの作成にプロセスの名前を付けると，変更によって追加されレシピ帳プログラムのソースコードからメソッド間たメソッドがプロセスとして追加された DFD が作れ

データ依存グラフ G p を作成する．この結果，G p はる．ただし，この追加されたプロセス名はメソッド間202 個のノードを持つグラフとなった．定義されたメ

データ依存グラフでのノード名であり，データフローソッドのノードは 102 個であり，残りの 100 個はラ名は付けることができない．

イブラリ等のメソッド呼び出しのノードとなる．

4 適用事例
対象とするプログラムと DFD に提案手法を適用し，

4. 3 DFD とメソッド間データグローグラフの対応
付けプログラムと DFD の対応関係が正しく取れているか，

4. 3. 1 外部実体・データストアとの対応付け

プログラムの変更が DFD に正しく反映されるかを確

グラフ G p 上に外部実体・データストアのノードを認する．
今回の適用事例では，Java 言語により開発された料理レシピ管理を行う料理レシピ帳プログラム (筆者が作成したもの) を対象とする．

追加し，外部実体・データストアとのデータフローを作り出しているメソッドのノードと依存関係のエッジを追加する．
図 5 の外部実体・データストアと繋がっているデー

表2

表3

図 5 の外部実体・データストアとの対応付け

変更後のレシピ帳プログラムの規模定義されたメソッド数
データフロー107

対応するメソッド

コード行数

1,623

レシピ入力

RegistrationPage.register()

ファイル数

23

レシピファイル

RecipeData.writeObject()

全てのレシピファイル

FileManager.getRecipeData()

フリーワードSearchPage.getText()

検索結果のレシピリスト

SearchPage.showResult()

るとき GED(G p , Gn ) = 8

2. FileManager.getCount()= レ シ ピ 検 索 ，S earchRecipe.S earchRecipe() = レシピ登録とす
るとき GED(G p , Gn ) = 10以上から，GED が最小となる，1 の対応付けを行う．

4. 4 メソッド間データ依存グラフの差異検出
4. 4. 1 ソースコードの変更
変更前のソースコードと，変更後のソースコードの差異検出の準備として，ソースコードの変更を行う．
レシピ帳プログラムにレシピのお気に入り登録機能を追加する．お気に入りに登録でき，お気に入りリストからレシピにアクセスできるようにする．変更後のレシピ帳プログラム
図6

グラフ G p のグループ化結果

変更後の料理レシピ帳プログラムの規模を表 3 に示す．

タフローを作り出しているメソッドを表 2 に示す．

4. 4. 2 差異検出表 2 から，5 個のノードをグラフ G p に追加した．

変更後のソースコードから作成したメソッド間デー

4. 3. 2 メソッド間データ依存グラフのノードのグ

タ依存グラフを Gn とする．グラフ G p でグループ化

ループ化されているノードを，グラフ Gn でもグループ化してDFD との対応を取るため，グラフ G p のノードをグいく．グループ化を行った結果を図 7 に示す．この

ループ化する．4. 3. 1 節で追加したノード以外のノー結果から，FileManager.getCount() ノード内のメソッドの数が，DFD のプロセスの数と同じ数になるまでドとデータ依存関係がある変更が行われたことが分グループ化する．

かる．

グループ化した結果を図 6 に示す．4. 3. 1 節で追加した，外部実体・データストアとの対応付ノードは四角形

4. 5 変更後の DFD 作成

で表し，円の大きさはグループに含まれるノード数を

図 7 を，グラフ G p と DFD との対応関係から外部表している．fileManager.getCount() ノードは 194 個の実体・データストアを追加し，グループ化されたノーノードのグループとなり，SearchRecipe.SearchRecipe()

ドを 1 つのプロセスとしプロセス名を付け，データノードは 8 個のノードのグループとなった．

フローに名前をつける．こうして作られた DFD を図

4. 3. 3 プロセスとの対応付け

8 に示す．また，変更により生じたプロセスは水色でグラフ G p のノードと，DFD のプロセスの対応関示している．

係を求める．

1. FileManager.getCount()= レ シ ピ 登 録 ，S earchRecipe.S earchRecipe() = レシピ検索とすと考えられる．そのため，正しく (DFD 上のプロセスに近づくように) グループ化されたとは言えない結果になった．改善する必要があるため，良い結果が出なかった原因を考察する．
この料理レシピ帳の場合，登録されたレシピデータをファイルで保存している．このレシピデータ (ファイル) を読み書きするメソッドは，レシピ登録・レシピ検索の両方で使われている．そのため，このメソッドのノードによって別のプロセスのノードもグループ化されてしまい，プロセスに合わせたグループ化がで
図7

グラフ Gn のグループ化結果きなかったと考えられる．このような，複数のプロセスで使われる汎用的なメソッドは他にも様々なものが考えられる．汎用的なメソッドを識別してこのノード経由でのグループ化を防ぐか，オブジェクトを識別してオブジェクトごとにノードを分ける等の対策が考えられる．

5. 2 差異検出について
今回の実験では，メソッドの追加によるデータ依存関係の差異を検出できた．追加されたメソッドについて，そのメソッド同士にどのようなデータ依存関係があるかがが分かりやすくなり，保守作業の支援に役立てられると考えられる．
図8

変更後の DFD の作成結果

しかし，この差異は全てレシピ登録プロセスとデータ依存があるとして検出された．これはレシピ登録プロセスのノードグループにノードが偏ってしまったた

5 考察めであり，ノードのグループ化を改善することで正し

今回の実験では，ソースコードの変更によるデータく検出されるようになると考えられる．

依存関係の差異を検出し，可視化することができた．

また，グループ化されたノード内のデータ依存関係

しかし，差異を DFD に反映できたとは言えない結果の差異も可視化することによって，保守作業に有益なとなった．

情報が得られると考えられる．

5. 1 ノードのグループ化について

5. 3 変更後の DFD 作成についてノードをグループ化した結果，194 個のノードから生成された変更後の DFD を見ると，今回の適用事なるグループと 8 個のノードからなるグループが出来

例ではソースコードの変更は小規模なものであった上がった．2 つのプロセスで共通して利用するメソッドが，メソッド名がそのまま出てくるので見難いものにが FileManager.getCount() ノードにグループ化されてなっている．ソースコードの変更の規模が大きくなしまい，この影響で SearchRecipe.SearchRecipe() ノーるとこの問題は顕著になると考えられる．ある程度ドにグループ化されるべきであったノードも FileM-グループ化したものを反映させたり，Javadoc 等のコ

anager.getCount() ノードにグループ化されてしまったメントをプロセス名にする等で対応できる可能性がある．

適用事例では，料理レシピの管理を行う小規模なソースコードに対して本手法を適用した．その結果，

6 関連研究様々なメソッドが追加されたことが検出できたが，変変数間のデータフローを表す変数間データフロー更された箇所が正しく DFD に反映されたとは言えなグラフを作成してエディタに表示し，ソースコード間い結果となった．ノードのグループ化を改善していの移動を支援することで開発者を支援する研究 [3] がくことで変更の DFD への反映が改善できると考えら行われている．

れる．

丸山らは，ソースコードの変更によるシーケンス図7. 2 今後の課題の差異を検出し，変更をシーケンス図に反映させるこ

7. 2. 1 ノードのグループ化の改善とでソフトウェア保守作業を支援する手法 [4] を提案

現状ではグループ化した結果のノードが，DFD のした．

プロセスと対応しているとは言えない．汎用的なメ

本研究では業務アプリケーションの設計でよく使ソッドを識別してこのノード経由でのグループ化をわれる DFD に着目し，ソースコードの変更によ DFD防ぐか，オブジェクトを識別してオブジェクトごとにの差異を検出し，変更を DFD に反映させることでソノードを分ける等の対策が考えられる．

フトウェア保守作業を支援する．メソッド間のデータ

7. 2. 2 抽象化

依存関係を解析し，この依存関係の差異を DFD に反生成された DFD の，変更箇所のプロセスは抽象度映させる．

が非常に低く見難いものとなっている．この抽象度を高めることで，DFD を見た時にどの部分でどのよ7 おわりにうな変更があったのか分かりやすくできると考えら

7. 1 まとめれる．

本研究では，ソースコードのみ変更されたソフト
ウェアに対し，変更前のデータフロー図（DFD) と参考文献

ソースコード，変更後のソースコードから，変更前[1] Bruza, P. D. and Van der Weide, T. P.: The semantics ofdata flow diagrams, University of Nijmegen, Department ofInformatics, Faculty of Mathematics and Informatics, 1989.
[2] Demarco, T., and 高橋智弘: 黒田 順一郎 (訳): 構造化分
析とシステム仕様, 1994.
[3] 悦田翔悟, 石尾隆, 井上克郎, ほか: 変数間データフロー
グラフを用いたソースコード間の移動支援, 研究報告ソフトウェア工学 (SE), Vol. 2011, No. 12, pp. 1–8 (2011).
[4] 丸山翔平, 上田賀一: ソフトウェア保守のための UML
シーケンス図維持支援, 日本ソフトウェア科学会大会論
文集, Vol. 32, 9p (2015).
[5] Zelkowitz, M. V., Shaw, A. C., and Gannon, J. D.: Principles of software engineering and design, Prentice-Hall Englewood Cliﬀs, 1979.と変更後の DFD の差異を検出する手法を提案した．
ソースコードの解析の際にメソッド間データ依存グラフを作成し，コールグラフの情報を利用したノードのグループ化によって DFD の形に近づけ，DFD と対応付けを行う．これにより，ソースコードと DFD の対応関係を解析し，ソースコードのみ変更されたソフトウェアに対し，ソースコードの変更を DFD に反映させる．