1 設計進化 2006/9/4 ゼミ発表資料

2 今回の発表の目的 「設計進化（ design evolution ）」の用語の使 われ方について考察 道具・物（電話機）の設計進化 アプリケーション（フレームワーク）の設計進化

3 発表内容 今回の発表の目的 設計の分類：外部設計、内部設計 設計進化の調査 考察 まとめと今後の予定

4 ・コードレベル ・構造レベル 設計の分類 内部設計 ・ユーザインタフェースレベル ・機能レベル 外部 or 製品設計 ソフトウェアはユーザ の要求を満たすために どうやって構成されて いるべきか？ ソフトウェアはユー ザの要求を満たすよ うに何を 備えてい るべきか？ ソフトウェ ア ・再利用性 ・変更容易性 ・理解容易性 ・拡張容易性 ・性能 ・ etc モジュール（クラス など）

5 「設計進化」の調査 調査目的 「設計進化」という用語が、どんな文脈でどんな 意味で使われているか？ 調査対象 道具・物（電話機）の設計進化 [ ノーマン ] アプリケーション（フレームワーク）の設計進化 [tokuda] ドナルド・ A. ノーマン. 「誰のためのデザイン ? 」 Lance Tokuda. Evolving Object-Oriented Designs with Refactorings. Ph.D. Thesis, 1999.

6 電話機の設計の進化 ドナルド・ A. ノーマン. 「誰のためのデザイン ? 」 電話機を考えてみよう。初期の頃の電話機はゆっくり と 何世代 かにわたって進化した [ ノーマン ] 。 初期の電話機 大きさや形の改良、信 頼性の向上、機能の向 上 便利だった改善点の喪失 スピードと目新し さの要求 現在の電話機 受話器とマイク をそれぞれの手 に持たなければ ならない 伝わる音声は貧弱 ボタンの大きさや間隔は幅 広い層にあう 音にフィードバックがある （プッシュボタンを押せば 受話器に響く） プッシュボタンのめ ちゃくちゃな配置 ボタンは大きすぎ・ 小さすぎ ボタンを押しても フィードバックがな い […] そして、デザインの世界に民間伝承のように伝わっていたデザインのや り方はすべて失われてしまった [ ノーマン ] 。 回転ダイアルやプッシュボ タンの配置は実験の結果で 決定

7 リファクタリングによる設計の 進化 リファクタリングの定義 外部から見たときの振る舞いを保ちつつ、理解や 修正が簡単になるように、ソフトウェアの内部構 造を変化させること [ ファウラー ] 。 tokuda の研究目的 リファクタリングによる設計進化を自動化する ツールの開発 マーチン ファウラー「リファクタリング」, Lance Tokuda. Evolving Object-Oriented Designs with Refactorings. Ph.D. Thesis, 1999.

8 設計が進化する理由（ 1/2 ） 機能性（ capability ）：新しい機能のサポー ト。既存の機能の変更。 再利用性：他のアプリケーションで再利用で きるようにする 拡張性：将来の拡張追加に備える 保守性：再構成により保守のコストを削減す る Lance Tokuda. Evolving Object-Oriented Designs with Refactorings. Ph.D. Thesis, 1999.

9 設計が進化する理由（ 2/2 ）： 人間的側面 経験：経験ある従業員は、彼らのドメイン知 識をベースにより良い設計を作る可能性があ る。 新しい展望：新しいプロジェクトメンバーは、 ある設計がどうやって構成されるのかついて 異なるアイデアを持っていることがよくある。 実験：適切な設計に達するには、異なる設計 パスを探索することが要求されるかもしれな い Lance Tokuda. Evolving Object-Oriented Designs with Refactorings. Ph.D. Thesis, 1999.

10 オブジェクト指向における 3 つ種類の設計進化 スキーマ変換：オブジェクト指向データベースス キーマ変換。例：クラス名の変更、新しいインスタ ンス変数の追加、クラス階層におけるメソッドの移 動 デザインパターン：クラス、オブジェクト、メソッ ドなどの間の関係の繰り返し起こる集合。よくある オブジェクト指向設計問題に対する望ましい解決策 を定義。 ホットスポット駆動アプローチ：フレームワークの どの側面（＝ホットスポット）がアプリケーション 間で異なりやすいのかを特定。 Lance Tokuda. Evolving Object-Oriented Designs with Refactorings. Ph.D. Thesis, 1999.

11 ホットスポット ホットスポット駆動アプローチ：フレームワークの どの側面（＝ホットスポット）がアプリケーション 間で異なりやすいのかを特定 データホットスポット： アプリケーション間でインスタンス変数が変わりうるとき、 抽象クラスを導入 機能ホットスポット： 特別なメソッドとクラスを導入 テンプレートメソッドパターン

12 Computer Integrated Manufacturing フレームワークの設計進化 CFObject CNameEnt CResource CCompMgrCFactoryCMoveResCPerson CEquipmentManagerCPersnMgrCMachine Version 2 CFObject CIcon CResource CIcCompMgCIcFactoryCIcMoveResCIcPerson CIcMachineCIcEquipMCIcPersnMg NamedEnt Resource CompMgrFactoryMoveResPerson EquipMgrPeronMgrMachine m_objptr Version 4 81 の個々の リファクタリング 設計進化

13 考察 / 思ったこと： 設計進化の側面 個体 / 内部設計（リファクタリ ング） 振る舞いを変更せずに、個体 （個々のアプリケーション / フ レームワーク / ライブラリ）レ ベルでの構造の変更 種 / 外部設計 ハードウェア：電話機 [ ノーマ ン ] 、タイプライタ [ ノーマン ] ソフトウェア： Web フレーム ワーク（？）、コンパイラコ ンパイラ（？）、プログラミ ング言語（？） 設計の対象内部、外部 進化の対象個体、種 ドナルド・ A. ノーマン. 「誰のためのデザイン ? 」 Mehdi Jazayeri. Species evolve, individuals age. Invited Keynote talk, International Workshop on Principles of Software Evolution リファクタリング＝設 計進化？ or 設計進化＝ リファクタリング？ 設計進化に至る組み合わせ 個体種 （ファミ リ） 内部設計 tokuda の例 ( リファクタリ ング ) 外部設計電話機の例 設計進化の側面（次 元？） 進化の規模大きい、小さい 進化の速度速い、ゆっくり 設計進化の特性

14 考察 / 思ったこと：設計進化の側 面 例：コンパイラコンパイラ 個体種（ファミ リ） 内部設計 外部設計 JavaCC SableCC ANTLR 種 種 個体 個体 / 内部設計：リファクタリングによるプログラム構造レベルでの設 計進化 個体 / 外部設計：インタフェース（たとえば API ）の改善などを目的とし た設計進化 種 / 内部設計：内部構造を設計するにあたって、コンパイラコンパイラ 開発に共通となるようなライブラリ / 設計技術（ Visitor パターン） / アー キテクチャの検討や採用？ 種 / 外部設計：コンパイラコンパイラ開発で共通となるような機能や ツール（ ant タスク、 Eclipse プラグインなど）の提供？

15 考察 / 思ったこと：設計進化の側 面： 疑問点 設計進化を引き起こす要因（たとえば環境？ そもそも環境とは？） 各組合せ（内部 / 外部 / 個体 / 種）の間の関係 内部 / 個体の場合の「設計進化」を引き起こすプロセスは、リファクタリン グだけ？ 振る舞いを保たずに構造を変化させることを「設計進化」と呼んでい い？ すべて の「構造変化」は、「設計進化」？ 機能を追加することによって構造が変化したなら「設計進化」？ 機能を追加することによって構造が変化したことにより、リファクタリ ングの余地が出た場合は「設計進化」？ そもそもソフトウェアにおける「種」の定義は？ 生物の分野でも、色々な 定義や考え（「種」は存在しない）がある [Wikipedia: 種 ( 生物 )] プロダクトラインやアーキテクチャの話はどう関わってくる？

16 まとめと今後の予定 外部設計（インタフェース・機能レベル）と 内部設計（コード・構造レベル）を分けて考 えた 「設計進化」の用語の使われ方について調査 「設計進化」の側面について考察 今後の予定：「設計進化」の側面について もっと考える

17 簡単な研究ネタ： 種 / 内部レベルでの設計進化 時間 ソフトウェ ア 世代交代 ver 1.0 ver 2.0ver 1.0 ver x.x 疑問：種レベルでの共通の構造（部分的・全体的なアーキテクチャ）は、生まれて きているか？ Yes なら、どの時期にどのようにしてどの部分において発生してきて いるのか？ 共通になる要因：共通のライブラリの採用、似た設計技術の採用、共通の機能要求 など 新しい点：時期を考慮している点。