スライド 1

設計進化
[email protected]
2006/9/4 ゼミ発表資料
1
今回の発表の目的

「設計進化(design evolution)」の用語の使われ
方について考察


道具・物(電話機)の設計進化
アプリケーション(フレームワーク)の設計進化
2
発表内容

今回の発表の目的

設計の分類:外部設計、内部設計

設計進化の調査

考察

まとめと今後の予定
3
設計の分類
外部 or 製品設計
・ユーザインタフェースレベル
・機能レベル
ソフトウェアはユーザ
の要求を満たすように
何を 備えているべき
か?
ソフトウェア
内部設計
・コードレベル
・構造レベル
ソフトウェアはユーザの
要求を満たすためにどう
やって構成されているべ
きか?
・再利用性
・変更容易性
・理解容易性
・拡張容易性
・性能
・etc
モジュール(クラスなど)
4
「設計進化」の調査

調査目的


「設計進化」という用語が、どんな文脈でどんな意味
で使われているか?
調査対象


道具・物(電話機)の設計進化[ノーマン]
アプリケーション(フレームワーク)の設計進化
[tokuda]
ドナルド・A. ノーマン. 「誰のためのデザイン?」 1990.
5
Lance Tokuda. Evolving Object-Oriented Designs with Refactorings. Ph.D. Thesis, 1999.
電話機の設計の進化
電話機を考えてみよう。初期の頃の電話機はゆっくりと 何
世代 かにわたって進化した[ノーマン]。
スピードと目新しさ
の要求
現在の電話機
初期の電話機
大きさや形の改良、信頼
性の向上、機能の向上
便利だった改善点の喪失
受話器とマイクを
それぞれの手に持
たなければならな
い
回転ダイアルやプッシュボタン
の配置は実験の結果で決定
プッシュボタンのめちゃ
くちゃな配置
ボタンの大きさや間隔は幅広
い層にあう
ボタンは大きすぎ・小さ
すぎ
音にフィードバックがある(プッ
シュボタンを押せば受話器に
響く)
ボタンを押してもフィー
ドバックがない
伝わる音声は貧弱
[…] そして、デザインの世界に民間伝承のように伝わっていたデザインのやり方
6
はすべて失われてしまった[ノーマン] 。
ドナルド・A. ノーマン. 「誰のためのデザイン?」 1990.
リファクタリングによる設計の進化

リファクタリングの定義


外部から見たときの振る舞いを保ちつつ、理解や修
正が簡単になるように、ソフトウェアの内部構造を変
化させること[ファウラー]。
tokudaの研究目的

リファクタリングによる設計進化を自動化するツール
の開発
マーチン ファウラー「リファクタリング」, 2000.
Lance Tokuda. Evolving Object-Oriented Designs with Refactorings. Ph.D. Thesis, 1999.7
設計が進化する理由(1/2)

機能性(capability):新しい機能のサポート。既
存の機能の変更。

再利用性:他のアプリケーションで再利用できる
ようにする

拡張性:将来の拡張追加に備える

保守性:再構成により保守のコストを削減する
8
Lance Tokuda. Evolving Object-Oriented Designs with Refactorings. Ph.D. Thesis, 1999.
設計が進化する理由(2/2):
人間的側面

経験:経験ある従業員は、彼らのドメイン知識を
ベースにより良い設計を作る可能性がある。

新しい展望:新しいプロジェクトメンバーは、ある
設計がどうやって構成されるのかついて異なる
アイデアを持っていることがよくある。

実験:適切な設計に達するには、異なる設計パ
スを探索することが要求されるかもしれない
9
Lance Tokuda. Evolving Object-Oriented Designs with Refactorings. Ph.D. Thesis, 1999.
オブジェクト指向における
3つ種類の設計進化

スキーマ変換:オブジェクト指向データベーススキーマ
変換。例:クラス名の変更、新しいインスタンス変数の追
加、クラス階層におけるメソッドの移動

デザインパターン:クラス、オブジェクト、メソッドなどの間
の関係の繰り返し起こる集合。よくあるオブジェクト指向
設計問題に対する望ましい解決策を定義。

ホットスポット駆動アプローチ:フレームワークのどの側
面(=ホットスポット)がアプリケーション間で異なりやす
いのかを特定。
10
Lance Tokuda. Evolving Object-Oriented Designs with Refactorings. Ph.D. Thesis, 1999.
ホットスポット

ホットスポット駆動アプローチ:フレームワークのどの側
面(=ホットスポット)がアプリケーション間で異なりやす
いのかを特定

データホットスポット:


アプリケーション間でインスタンス変数が変わりうるとき、抽象ク
ラスを導入
機能ホットスポット:


特別なメソッドとクラスを導入
テンプレートメソッドパターン
11
Computer Integrated Manufacturing
フレームワークの設計進化
設計進化
CFObject
Version 2
81の個々の
リファクタリング
CNameEnt
CResource
CCompMgr
CFactory
CEquipmentManager
CMoveRes
CPersnMgr
CMachine
CFObject
Version 4
m_objptr
CIcCompMg
CIcEquipM
CIcon
NamedEnt
CResource
Resource
CIcFactory
CIcMoveRes
CIcPersnMg CIcMachine
CPerson
CIcPerson
CompMgr
Factory
MoveRes
EquipMgr
PeronMgr
Machine
Person
12
考察/思ったこと:
設計進化の側面
リファクタリング=設計進
化? or 設計進化=リファ
クタリング?
設計進化の側面(次元?)

設計進化の特性
設計の対象
内部、外部
進化の規模
大きい、小さい
進化の対象
個体、種
進化の速度
速い、ゆっくり
個体/内部設計(リファクタリング)

設計進化に至る組み合わせ
振る舞いを変更せずに、個体
(個々のアプリケーション/フレー
ムワーク/ライブラリ)レベルでの
構造の変更
個体
内部設計

種/外部設計


ハードウェア:電話機[ノーマン]、
タイプライタ[ノーマン]
ソフトウェア:Webフレームワーク
(?)、コンパイラコンパイラ(?)、
プログラミング言語(?)
外部設計
種
(ファミリ)
tokudaの例
(リファクタリング)
電話機の例
ドナルド・A. ノーマン. 「誰のためのデザイン?」 1990.
Mehdi Jazayeri. Species evolve, individuals age. Invited Keynote talk, International
Workshop on Principles of Software Evolution. 2005.
13
考察/思ったこと:設計進化の側面
例:コンパイラコンパイラ
JavaCC
SableCC
ANTLR
種
個体
個体
種(ファミリ)
内部設計
外部設計

個体/内部設計:リファクタリングによるプログラム構造レベルでの設計進化

個体/外部設計:インタフェース(たとえばAPI)の改善などを目的とした設計
進化

種/内部設計:内部構造を設計するにあたって、コンパイラコンパイラ開発に
共通となるようなライブラリ/設計技術(Visitorパターン)/アーキテクチャの検
討や採用?

種/外部設計:コンパイラコンパイラ開発で共通となるような機能やツール
(antタスク、Eclipseプラグインなど)の提供?
14
考察/思ったこと:設計進化の側面:
疑問点

設計進化を引き起こす要因(たとえば環境? そもそも環境とは?)

各組合せ(内部/外部/個体/種)の間の関係

内部/個体の場合の「設計進化」を引き起こすプロセスは、リファクタリングだけ?
 振る舞いを保たずに構造を変化させることを「設計進化」と呼んでいい?
 すべて の「構造変化」は、「設計進化」?
 機能を追加することによって構造が変化したなら「設計進化」?
 機能を追加することによって構造が変化したことにより、リファクタリングの余
地が出た場合は「設計進化」?

そもそもソフトウェアにおける「種」の定義は? 生物の分野でも、色々な定義や考
え(「種」は存在しない)がある[Wikipedia:種 (生物)]

プロダクトラインやアーキテクチャの話はどう関わってくる?
15
まとめと今後の予定

外部設計(インタフェース・機能レベル)と内部設
計(コード・構造レベル)を分けて考えた

「設計進化」の用語の使われ方について調査

「設計進化」の側面について考察

今後の予定:「設計進化」の側面についてもっと
考える
16
簡単な研究ネタ:
種/内部レベルでの設計進化
ver 1.0
世代交代
ア
プ
リ
1
ア
プ
リ
2
ア
プ
リ
3
ソフトウェア
ver x.x
ver 1.0
ver 2.0
ver 1.0
ver x.x
ver x.x
時間
疑問:種レベルでの共通の構造(部分的・全体的なアーキテクチャ)は、生まれてきている
か? Yes なら、どの時期にどのようにしてどの部分において発生してきているのか?
共通になる要因:共通のライブラリの採用、似た設計技術の採用、共通の機能要求など
17
新しい点:時期を考慮している点。