目次

C/C++ ソースプログラムのアーキテクチャを見える化 アーキテクチャの崩れとテスト
 アーキテクチャの崩れに気づくには Structure101の紹介
 設計図と実コードの比較

株式会社東陽テクニカ
ソフトウェア・ソリューション

Copyright (c) 2011 Toyo Corporation

アーキテクチャとは(1/2)
アーキテクチャとは

1アーキテクチャとは(2/2)
アーキテクチャとはソフトウェアの全体構成/枠組み

家に例えると・・・
GUI(ユーザ I/F)
屋根

壁通信

土台

汎用計算

Copyright (c) 2011 Toyo Corporation2

Copyright (c) 2011 Toyo Corporation

目次

3

アーキテクチャ崩れの例(1/3)
アーキテクチャ崩れの例
アーキテクチャが崩れると、テストが大変になるアーキテクチャが崩れる アーキテクチャの崩れとテスト
 アーキテクチャの崩れに気づくには Structure101の紹介
 設計図と実コードの比較

 家の場合家の中にいる人は、崩れに気づきにくい＝
ソフトウェア開発者は家の中にいる状態
Copyright (c) 2011 Toyo Corporation

4

Copyright (c) 2011 Toyo Corporation51

アーキテクチャ崩れの例(2/3)
アーキテクチャ崩れの例

アーキテクチャ崩れの例(3/3)
アーキテクチャ崩れの例

 ソフトウェアの場合

 機能拡張時
設計

設計

実装

実装

userInput()userInput()

deviceInput()userInput()

deviceInput()userInput()
communication()communication()communication()communication()encryption()encryption()encryption()
ブラックボックス化

encryption()
ブラックボックス化

このような実装を繰り返すことでアーキテクチャはさらに崩れる
6

Copyright (c) 2011 Toyo Corporation

機能拡張時のテスト範囲

仕様変更の範囲 deviceInput()追加時

 通信フォーマット仕様変更時

設計

userInput()

7

Copyright (c) 2011 Toyo Corporation

設計

実装

deviceInput()userInput()

communication()deviceInput()userInput()

deviceInput()userInput()

communication()communication()encryption()

実装

communication()encryption()encryption()encryption()deviceInput() → encryption()
I/F確認の分、テスト範囲が大きい

Copyright (c) 2011 Toyo Corporation

deviceInput()

影響範囲が大きい8

アーキテクチャの崩れとテスト

Copyright (c) 2011 Toyo Corporation

9

目次

アーキテクチャが崩れていると、影響範囲が大きくなりすぎる アーキテクチャの崩れとテスト
 アーキテクチャの崩れに気づくには Structure101の紹介
 設計図と実コードの比較

テストが大変になる 本来、必要な箇所以上のテストが必要になる
 無関係と思っていた箇所に影響があり、デグレードが発生する
 問題が発生した場合、問題の絞込みに時間がかかる

Copyright (c) 2011 Toyo Corporation

10

Copyright (c) 2011 Toyo Corporation112崩れに気づくには設計と実装の比較手段(1/4)
設計と実装の比較手段

 家を外から見る

実装状態

 ソースコードとディレクトリ構造！

ソースコード

設計図

static double devia
LinkedList* pElem;
double dev = 0.0;
unsigned int coun

関連を示すのはファイル名頼り？

while( pElement !
dev += POW(pEcount++;

ディレクトリ構造

外から見ると崩れていることが分かる＝
ソフトウェア全体として設計どおりに実装されているかを見る

ソースコードとディレクトリ構造から設計どおりかを判断するのは困難

12

Copyright (c) 2011 Toyo Corporation

設計と実装の比較手段(2/4)
設計と実装の比較手段

設計と実装の比較手段(3/4)
設計と実装の比較手段

インクルード関係

 インクルード関係や呼び出し関係

13

Copyright (c) 2011 Toyo Corporation

設計図

設計図
GUI(ユーザ I/F)
設計図のどこに対応？
通信呼び出し関係

汎用計算

情報としては必要だがファイルのインクルード関係や関数の呼び出し関係だけでは不十分「グループ化」と「グループの上下関係」で設計図に近づけた形で可視化

Copyright (c) 2011 Toyo Corporation

14

設計と実装の比較手段(4/4)
設計と実装の比較手段

15

目次
 アーキテクチャの崩れとテスト
 アーキテクチャの崩れに気づくには Structure101の紹介
 設計図と実コードの比較

比較
設計

Copyright (c) 2011 Toyo Corporation

実装

ソースコードならStructure101を用いると設計に近づけた形で実装を表示することができる
例えば、次のような問題点が分かる
 下位層から上位層への依存がある 様々な箇所と依存関係があり複雑すぎる
 階層を跨ぐ依存関係がある

Copyright (c) 2011 Toyo Corporation

16

Copyright (c) 2011 Toyo Corporation

173

Structure101とはとは依存関係とは静的解析ツールQA C/QA C++にアドオンして使用するアーキテクチャ分析支援ツール

コードのある要素が別の要素に影響を与えるとき、依存関係がある
フォルダ、ファイル、グローバル変数、関数、クラス・・・【特長】
 コードの構成要素間の依存関係を表示
 コードの構成要素の階層構造を可視化
 構造上、好ましくない依存関係（循環依存など）を検出
 コードの階層構造の設計図（アーキテクチャ図）と実コードの比較
 コードの改版の影響範囲を表示
 コードの改版で追加された要素や依存関係を強調表示
 Webブラウザから参照可能

・includes

ファイルAがファイルBをインクルードする・calls関数Aが関数Bを呼び出す

・references

関数Aがクラスまたはグローバル変数Bを使用する

・has

クラスAがクラスBをメンバに持つ・has param

関数AがクラスBをパラメータに持つ・returns

関数AがクラスBを返す

・specializes

関数AがテンプレートBを特殊化する・subclasses

クラスAがクラスBを継承する

要素Aは要素Bに依存する

18

Copyright (c) 2011 Toyo Corporation

A→B

Copyright (c) 2011 Toyo Corporation

階層構造を可視化(1/2)
階層構造を可視化

19

階層構造を可視化(2/2)
階層構造を可視化
階層構造をグラフで表示する。矢印で依存の方向、数字で依存の数を表す。

ディレクトリ構造

依存関係を元に階層構造を可視化

プロジェクトのディレクトリ構造

選択した要素内の階層構造と依存関係を表示

上位層

循環依存している箇所を赤枠で表示

下位層選択した依存関係の詳細を表示

20

Copyright (c) 2011 Toyo Corporation

Copyright (c) 2011 Toyo Corporation

設計図の作成(1/3)
設計図の作成21

設計図の作成(2/3)
設計図の作成既存のコードから設計図を自動生成することが可能

下位層から上位層への依存関係を検出
設計図

ディレクトリ構造

デフォルトでは同階層および下位層から上位層への依存は違反として検出する

ユーザ I/F

通信
汎用計算

階層構造

自動生成

 設計図にはフォルダやファイルがセルとしてマッピング
 セルの追加、削除、移動、グルーピングなどが可能

Copyright (c) 2011 Toyo Corporation

22

Copyright (c) 2011 Toyo Corporation234

設計図の作成(3/3)
設計図の作成目次

階層を跨ぐ依存関係を検出

上位層から下位層への依存であっても階層を跨ぐ依存を違反として検出する（※）

ユーザ I/F

 アーキテクチャの崩れとテスト
 アーキテクチャの崩れに気づくには Structure101の紹介
 設計図と実コードの比較

通信

また、設計図上の任意の要素間の依存に対して、違反とする／しないを設定可能

汎用計算※設計図のプロパティで、項目StrictをYesに設定する

24

Copyright (c) 2011 Toyo Corporation

Copyright (c) 2011 Toyo Corporation

比較のための準備(1/2)
比較のための準備

25

比較のための準備(2/2)
比較のための準備
少なくとも初回は設計意図を知っている「アーキテクチャ設計者」が設計図を調整

ディレクトリ構造
設計図

階層構造

 階層構造はツールが自動的に判断 ツールがアーキテクチャの設計意図を汲んでくれる訳ではない

Copyright (c) 2011 Toyo Corporation

26

Copyright (c) 2011 Toyo Corporation

問題例１(1/2)
問題例１27

問題例１(2/2)
問題例１ 下位層から上位層への依存がある
実装の誤り
GUIのコード内に本来は汎用計算にあるべき関数が含まれていて下位層から呼び出されている汎用計算(utility)からユーザI/F(GUI)への依存関係がある
この汎用計算のプログラムを別のアプリケーションで使用する場合、GUI画面まで必要になってしまう

対象の関数を分離し汎用計算へ→ 再利用性の低下

Copyright (c) 2011 Toyo Corporation

28

Copyright (c) 2011 Toyo Corporation

295問題例２(1/2)
問題例２

問題例２(2/2)
問題例２

 様々な箇所と依存関係があり複雑すぎるファイルの分割
コードを分割することで依存関係を簡潔にする

下位層から上位層への依存はないがこのソースは、下位の様々なソースから影響を受け、上位の様々なソースに影響を与える→ コードの変更時の影響範囲を小さくする→ コードが肥大化し処理が複雑になっている可能性

Copyright (c) 2011 Toyo Corporation30

31

Copyright (c) 2011 Toyo Corporation

問題例３(1/2)
問題例３

問題例３(2/2)
問題例３
放置すると･･･

 階層を跨ぐ依存関係がある

さらなる意図しない依存を引き起こす

本来の設計意図

下位層から上位層への依存ではないが、設計時には階層を跨ぐ依存は意図していない→ アーキテクチャの崩れ
本来の設計意図

Copyright (c) 2011 Toyo Corporation

32

Copyright (c) 2011 Toyo Corporation

33

まとめアーキテクチャが崩れると、テストが大変になる→
崩れに気づくには、外から見ることが重要→ご清聴ありがとうございました。

「グループ化」と「グループの上下関係」で設計図に近い形でコードの状態を可視化→
崩れたアーキテクチャを早い段階で修正

株式会社東陽テクニカ
ソフトウェア・ソリューション

アーキテクチャの維持

Copyright (c) 2011 Toyo Corporation

34

Copyright (c) 2011 Toyo Corporation

35

6