2010/12/11 VSUG アーキテクトアカデミー

1. オブジェクト指向設計の原則 NPO アイネタ・ジャパン 理事 日本XPユーザ会 運営メンバー 小井土 亨

2. 自己紹介 仕事 パッケージベンダーで、パッケージを開発 具体的な作業内容 開発のガイドラインを作る 開発プロセスを設計する 開発プロセスを支える環境を構築し、運用する 各種ツールの選択や開発 ビルド環境の整備、各種管理ツールの整備 ソフトウェア・アーキテクチャの決定する 基盤フレームワークの設計と実装 基盤の共通ライブラリの設計と実装 開発上のいろいろな相談を受ける 今日の目的 オブジェクト指向における設計の基本原則やデザインパターンなどについて、良い設計という観点で議論したいと思います 特に、アーキテクチャと設計の関係について、会場のみなさんと考えたいと思います 2

3. 本日のアジェンダ 3

4. ソフトウェア開発とは ソフトウェア開発の本質 解決すべき問題をより単純な問題に分割する 分割した問題に解法を適応する 解法を適応したものを組み立てる 4

5. 設計に関する質問 要求を完全に理解できたとした場合、 設計結果は同じとなる？ Ｙｅｓ /Ｎｏ 5

6. 設計に関する質問 機能仕様が同じ場合、設計は、だれが行っても同じ結果となる？ Ｙｅｓ /Ｎｏ 6

7. 設計に関する質問 去年の自分と今年の自分が同じ仕様に対して設計したら、同じ結果となる？ Ｙｅｓ /Ｎｏ 7

8. 設計とは 設計の本質 要求、分析の結果をどのように実現するかを解決させる活動 設計は、問題を解く作業なので、唯一の正解はなく、あるのは最適解 設計の基本 分析の全ての機能を正しく実現する ソフトウェアの完全な姿を提供すべきである 設計結果は、ドキュメントとして提供されることが多い ドキュメントベースのコミュニケーション 設計結果を利用する人が読みやすく理解しやすい 8

9. 設計の目的 9

10. 悪い設計 良い設計 10

11. 設計の難しさ 11

12. 心がけていること 12

13. 設計の原則 プログラムをモジュールに分割する 分割することで、プログラムが複雑になるのを避ける モジュール間の依存関係を明確にする モジュール間の結合度が低い モジュール間の結合度が低いほうが良い 修正や問題が影響する範囲が少なくなる モジュールの凝集度が高い 各モジュール内の凝集度を高くすることで、モジュール間の結合度が低くなる 再利用率 モジュール分割し、モジュール間の結合度を低くして再利用率を上げる 13

14. イベント駆動型サービス 要求があった場合にサービスを実行する。 例は？ 利点は？ 14

15. バッチ処理型サービス 決められた計画に沿ってサービスを実行する。 例は？ 利点は？ 15

16. アーキテクチャと品質 「人を移動させる」という要求に対して、 イベント駆動型とバッチ処理型のサービスでは、品質にどのような違いがあるでしょうか？ 16

17. イベント駆動とバッチ処理 イベント駆動によるサービス 要求があった場合にサービスを実行する イベント駆動の例 タクシーのサービス 利点 要求された時だけサービスを行うことで運用コストを減らす バッチ処理によるサービス 事前に決められた計画に沿ってサービスを実行する バッチ処理の例 ダイヤを決めて運行する電車やバスのサービス 利点 まとめて行うことでコストを減らす サービスを行う回数を少なくして運用コストを減らす 17

18. ソフトウェアアーキテクチャ ソフトウェアアーキテクチャとは ソフトウェア構造や構造化の原則 ソフトウェアアーキテクチャの目的 ソフトウェアの品質特性を強制（支配）する構造を構築する 品質特性とは ソフトウェアが実現するべき品質の特徴 代表的なもの パフォーマンス（性能・速度） 安全性 信頼性 可用性（Availability） 堅牢性（セキュリティ） ユーザビリティ（使いやすさ） 拡張性 18

19. ソフトウェアアーキテクチャの定義 ソフトウェアアーキテクチャの定義 複数の定義が必要 複数の角度からの表現を組み合わせて定義を行う ソフトウェア開発のビジョンを実現するために必要なソフトウェア構造 構造化原則 抽象的な構造やガイドライン 概念的な構造（モデリング） ANSI/IEEE Std 1471-2000 構成要素を統合したシステムの基本的な構造，構成要素の相互および構成要素と環境間の関係，そしてシステム設計と発展を導く方針 全体の分け方と、分けた部分をどのように関係づけるか 19

20. ソフトウェアアーキテクチャの構築 アーキテクチャへの要求 達成すべき品質特性への要求 各品質特性は、相反する項目がある トレードオフを考慮し、アーキテクチャを決定する 要求の種類 非機能要求 長期的な機能要求 アーキテクチャ構築時の考慮点 可変性 変わる要求と変わらない要求の分析 リスクの方針 さまざまの視点からリスクの洗い出しと方針を決定 20

21. アーキテクチャの複数のビュー ビューポイントとは ステークホルダの関心事に応じた視点 ビューとは 複数の関連した視点（ビューポイント）によって、アーキテクチャを記述するものがビューである ４つのビュー 論理ビュー システムが必要とされている機能を実現する、論理的な構造 実行ビュー 実行時のプロセスやタスクやスレッドといった実行時の単位の構造 開発ビュー システムが開発時のファイル等を単位とした構造 配置ビュー システムをどのようなマシン上で動作させ、各プロセスがどのマシン（CPU)上に配置されるか等を表した構造 21

22. パターンに関する質問 デザイン・パターンを勉強したことは？ Ｙｅｓ /Ｎｏ 22

23. パターンに関する質問 パターンを書いたことは？ Ｙｅｓ /Ｎｏ 23

24. パターンに関する質問 パタン・ランゲージを説明してください。 24

25. パタン・ランゲージ デザイン・パターン 経験に基づいて、繰り返し考え出されてきた、設計についての解決策を一定の形式で記述したもの 名前/目的/動機/適用可能性/構造/構成要素/協調関係/結果/実装/関連するパターン 名前/問題/解決策/効果（トレードオフ）/関連 パタン・ランゲージ 何らかの活動に必要なパターンの集まり パターンを組合わせて作られる体系 25

26. パターンに関する質問 アーキテクチャをパタン・ランゲージで体系化することについて？ 〇（有効） or ×（有効でない） 26

27. 設計方針に関する質問 仕様変更が繰り返されると、設計は悪くなる（設計の悪臭）？ Ｙｅｓ /Ｎｏ 27

28. 設計方針に関する質問 先を見越して、発生しそうな仕様変更に 対する仕組みを組み込むべきである？ Ｙｅｓ /Ｎｏ 28

29. 設計方針に関する質問 仕様変更は、予測できる？ （予測できない、仕様変更はない）Ｙｅｓ /Ｎｏ 29

30. 悪い設計の兆候 硬さ 変化しにくいシステム １つの変更が全体に影響し、多くの変更が必要になる もろさ １つの変更で、論理的には関連のない箇所まで正常動作しなくなる 扱いにくさ 正しいことをすることが難しいシステム 不透明さ 読みにくく、わかりにくい 不必要な複雑さ 本質的に意味を持たない構造が含まれているシステム 不必要な繰り返し 同じような構造が繰り返し現われ、共通化できる部分がされていない 移植性のなさ 再利用できる部分を切り出すことができない 30

31. 良い設計とは（設計品質特性） 正確性 仕様を正しく満たしていること 理解性 設計結果が読みやすく理解しやすいこと 一貫性（統一性） 設計上の個々の概念が首尾一貫して、ぶれがない 変更容易性 機能強化などに伴う変更が容易であること 頑健性 誤った使い方に対して、システムが適切に対処できること システムの一部のバグが全体に波及しないこと 移植性 いろいろなハードウェア、ソフトウェア環境へ容易に移植できること 効率性 実行効率、資源効率ともに十分実用に適応していること 31

32. テスト容易性と設計 テスト容易性は設計の指針となるか？ Ｙｅｓ /Ｎｏ 32

33. 良いテストの条件 テスト目的が明確である 何をテストするか明確である その目的も明確で、更にひとつであること テストの判定が正しい テストの成功、失敗が正しく判定されている テストを独立して実行することができる テストが他のテストに依存することなく、独立している 繰り返し実行することができる 何度でも繰り返して、テストを実行することができる テストを実行しても、状態が変化しない テストを実行し、成功した場合でも失敗した場合でも、テストを実行する前と後で何も変わらない 33

34. 良いテストの効果 メソッドが一つの機能を実現している メソッドが明確な一つの機能だけを提供する メソッドの結果を提供する 外部に対して、メソッドの処理結果を判断できるような何らかの方法を提供する クラスやメソッドの独立度が高いこと クラスやメソッドの、他のクラスやメソッドへの依存度が低い 特定の環境への依存度が低い 特定のファイルやデータベース構造などに対する依存度が低い 34

35. 良い設計の特徴 完全性と十分性 システムが目的を達成するために必要な機能のみを含んでいる 原子性 １つのサービスを実現することに焦点があたっている 高凝集度 少数に絞られた責務を持ち、その責務を実装するためだけの機能を持つ 低結合度 他の部分との連携が必要最低限である 35

36. 設計品質とテスト容易性 良いテストの効果と良い設計の相関関係 36

37. 重複をなくす DRY原則(Don't Repeat Yourself.) 例は？ 有効性は？ 理由は？ 37

38. DRY原則(Don't Repeat Yourself.) DRY原則 重複をなくす 重複コードを書かないための設計を行う ソフトウェア開発全般での適応 設計、プログラミング以外でも、重複をなくす 38

39. 設計の原則 単一責任の原則 SRP（The Single Responsibility Principle） クラスは、１つの役割（責任）だけを持つ １つの理由のみによって、クラスが変更される 役割を単独でテストできる 役割＝変更理由＝テスト単位 凝集（cohesion）と同意 凝集とは、モジュールに含まれる要素間の機能的な結び付き 原則の適用条件 役割の変更が確実に想定される場合 理由なく適応すると、「不必要に複雑な設計」となる 役割をテストする必要がある場合 問題の予兆（もろい設計） ある役割の変更に伴い、本来関係ないと思われる役割のクラスに変更の影響がある 独立したテストが困難なクラスがある 39

40. 設計の原則 オープン・クローズドの法則 OCP（The Open-Closed Principle） ソフトウェアの構成要素（クラス、モジュール、関数など）は拡張に対して開いていて、修正に対して閉じていなかればならない 拡張に対して開いているとは 構成要素の振る舞いを拡張できる 修正に対して閉じているとは モジュールの振る舞いを拡張しても、既存のモジュールは変更の必要がない 原則の適用 長く使い続けられるシステムを開発する システムに機能の追加や変更をし、成長させる必要がある 確実でない変化に対応するための準備は 「無意味に複雑な設計」となる 問題の予兆（硬い設計） ちょっとした変更でさえ、修正箇所と依存関係のある全ての箇所を修正する必要がある 機能の追加や修正を行なったときに、それに伴って修正しなければならないif文やswitch文が数多くある コピー＆ペーストで、大量の同じコード存在する 40

41. 設計の原則 リスコフの置換原則 LSP（The Liskov Substitution Principle） 派生クラスは、その基本クラスと置換え可能でなければならない 派生クラスは、基本クラスが許可する全てを許可しなければならい 原則の適応条件 基本クラスの派生型を作成する場合 契約による設計 派生クラスは、基本クラスの事前条件より等しいか弱いか 派生クラスは、基本クラスの事後条件より等しいか強いか 単体テストによって契約を明記する 問題の予兆（もろい設計） 派生クラスが増えた場合に基本クラスに変更が必要 派生クラスごとの分岐処理が基本クラスに存在する 基本クラスの機能を派生クラスが無力化する 基本クラスの機能を派生クラスで何もしない動作と置き換える 41

42. 設計の原則 依存性逆転の原則 DIP（The Dependency Inversion Principle） 上位モジュールは、下位モジュールに依存してはならない 抽象（目的）に依存させる 実装の詳細に依存させない 原則の適応条件 レイヤ構造によって、システムの複雑性を低くする 変更に耐えられるコードを構築する必要がある コードの保守が想定される 問題の予兆（もろい設計） 下位モジュールの変更が上位モジュールに影響する 42 A A IB B B

43. 設計の原則 インターフェイス分離の原則 ISP（The Interface Segregation Principle） クライアントに、クライアント依存しないメソッドへの依存性を強制してはならない インターフェイス内の強い関連があるものをグループ化して分離する 原則の適応条件 変更に強いシステムを開発する 多目的なインターフェイスを目的ごとに分離し、不用意な結びつきを避ける クラス間の依存度を下げて、低結合度を実現する 目的ごとのテストを作成する 問題の予兆（もろい設計） クライアントが利用していないメソッドの変更に影響される インターフェイスの実装クラスの変更が広範囲に影響する インターフェイスが部分的（グループ単位）にしか強い関連を持っていない 43

44. テスト駆動開発とは TDDの目的 テスト利用して、良いソフトウェアを開発する TDDの定義（規則） 失敗する自動テストコードを作成するまで、プロダクトコードを書かない コードの重複をなくす TDDのテストコードとは プロダクトコードが実現しなければならないこと プロダクトコードのインターフェイスを洗練させるもの TDDの設計（シンプルな設計） すべてのテストにパスする テストにパスするのに必要なコード 最適な範囲で、最小限の数のクラス 最適な範囲で、最小限の数のメソッド 44

45. TDDと設計 ＴＤＤでは、設計せずに、すぐに実装を行う？ Ｙｅｓ / Ｎｏ 45

47. 実装を始める前に、全てのテストを作成する

49. 要件をテストという形で明確化する

50. 自動テストを作成してから実装を行う

51. テストを単位として、小さいステップでソフトウェア開発を進める46

52. コードの位置づけ コードは重要なドキュメントのひとつ 目標「動作するきれいなコード」 詳細かつ正確なドキュメント ドキュメントとして認識して、クリアで読みやすくする テストコードは貴重なリソースのひとつ 継続的な開発で繰り返し利用される 運用で問題が発生した場合 テストを追加する 既存のテストを実行し、修正を確実に行う 47

53. リファクタリング リファクタリング（再設計）は、設計力がない人が行うものである？ Ｙｅｓ / Ｎｏ 48

54. リファクタリング リファクタリングとは 機能や振る舞いを変えることなく、コンポーネントの構造を最適化する 重複をなくす、非効率なアルゴリズムの改修、よりシンプルな構造にするなどを目的に行う リファクタリングの目的 長期的に機能拡張を可能な状態にコードを維持する 変更コストを一定に保つ リファクタリングのサイクル 常にリファクタリングを意識して、コードを良い状態に保つ コメントを書きたくなった時 テストしたいプライベートメソッドがあった時 変更を行う前に、変更しやすいようにリファクタリングする 49

55. リファクタリング どのような時にリファクタリング（再設計）を、行いますか？ 50

56. リファクタリング コードの不吉な匂い リファクタリングのヒント 重複したコード 長すぎるメソッド 巨大なクラス 多すぎる引数 変更の発散 ひとつの変更に、複数のクラスを同時に直さなければならない 変更の分散 ひとつの変更が多くの箇所に影響する プロパティ、メソッドの横恋慕 他のクラスをよく利用するメソッドなど データの群れ 必ず同時に利用されるデータの集まり 51

57. リファクタリング コードの不吉な匂い リファクタリングのヒント スイッチ文 疑わしき一般化 「いつか必要になるかも？」という理由での基本クラス 一時的プロパティ 特定の状況下だけで有効なプロパティ 仲介人 他のクラスに処理を委譲するだけのクラス 不適切な関係 ２つのクラスを常に連動して動作する 相続拒否 親クラスの一部しか利用しないサブクラス コメント 52

58. 参考文献 実践ソフトウェアエンジニアリング ロジャー S・プレスマン 森口 繁一編『ソフトウェア品質管理ガイドブック』日本規格協会(1990) アジャイルソフトウェア開発の奥義 ロバート・C・マーチン 日経ソフトウェア「正しく学ぶソフトウェア設計」 実践UML パターンによる統一プロセスガイド クレーグ・ラーマン UMLによる オブジェクト指向モデリング セルフレビューノート 荒井玲子 UML モデリングの本質 児玉公信 テスト駆動開発入門 ケント・ベッグ ソフトウェアアーキテクチャ 岸知二、野田夏子、深澤良彰 Software Factories ソフトウェアファクトリー Jack Greenfield, Keith Short リファクタリング プログラムの体質改善テクニック Martin Fowler ＩＴ アーキテクチャ・メタモデル セマンティック解説 ITスキル標準 V2 2006 アーキテクトの審美眼 萩原正義 53