オブジェクト指向入門 第2版 第1章 ソフトウェアの品質 / Object-Oriented Software Construction Chap.1

バートランド・メイヤー著「オブジェクト指向入門 第2版 原則・コンセプト」 第1章を読みながらまとめて行きます．
https://medium.com/@raryosu/o-o-study-1st-298f140afc00

Transcript

1. 1人オブジェクト指向勉強会 ̺̽ͪ͌͂͜ଉ،әᨃ
   ቻ࿣ 第1章 ソフトウェアの品質 Hagihara Ryosuke ( @raryosu ) 2017.12.01 1 Update: 2017.12.03
2. はじめに 2
3. はじめに 本スライドは， @raryosu が バートランド・メイヤー著
 “オブジェクト指向入門 第２版” (翔泳社, 2007) を読みながら，
 オブジェクト指向への理解を深めるためのものです． ひたすら読みながら内容をまとめていきます． いつ終わるかな． 3
4. ソフトウェアの品質とは 4
5. ソフトウェアの品質 ユーザが認識できる性質 5 外的品質要因 ex: スピード・使いやすさ 内的品質要因 ex: モジュール性・可読性 その他の性質
6. ソフトウェアの品質 外的品質要因 内的品質要因 設計者やプログラマが保証する必要がある 外的品質を保証するために重要 最終的に問題になる！！ 6 ユーザにとっては内部のことより興味がある
7. ソフトウェアの品質 内的品質要因は 外的品質要因を保証する手段に過ぎない 7 全体を見失ってしまわないように注意！
8. 外的品質要因 8
9. 外的品質要因 ① 正確さ ② 頑丈さ ③ 拡張性 ④ 再利用性 ⑤ 互換性 9 ⑥ 効率性 ⑦ 可搬性 ⑧ 使いやすさ ⑨ 機能性 ⑩ 適時性
10. ① 正確さ ϵ൴̞́˹˼ࠬᏭ˫̢˼˙̡˾˟̠́ϵύ̨࠰ᚄ˯̡
    ̵̹̺͑ͩ͜ᛂي̄ᑟդ 10 correctness すべきことをシステムが適切に実行すること 正確さは第１の要件である．
11. ① 正確さ 11 correctness 正確さの保証 ⇒ 前提条件依存 システムは複数のレイヤの上に成り立っている
12. ① 正確さ 12 correctness 高水準言語Xによる実装の正確さは アプリケーション コンパイラ OS ハードウェア コンパイラの実装が正確である前提 「より下の層が正しい」という前提のもとで 個々の層が正しいことを保証する！
13. ① 正確さ 13 correctness 型付けと表明 などの技法により 最初から正確なソフトウェアの構築を支援できる typing assertion ※後述 その成果を確認する手段として 「デバッグ」と「テスト」は欠かせない
14. ② 頑丈さ Ⴞऐ̀ಅЄ́ࡠ˭˼᣿Ԫ́᣿ে˯̡
    ̵̹̺͍͚͑ͩ͋͜ʹ̄ᑟդ 14 robustness 頑丈さは，正確さを補完するものである．
15. ② 頑丈さ 15 robustness 頑丈さ 仕様 正確さ 仕様に記述されている場合のシステムの振る舞い 正確さ 仕様以外のところで起きることについての特徴 頑丈さ
16. ② 頑丈さ 16 robustness 頑丈さは，正確さに比べ「曖昧」な概念 ˁᣓऐ̄ခ੓˂ˁႾऐ̀ခ੓˂˾˙˛̄̅ϵ൴́໳˰̡ᴈ⁜ ˩̄ˁႾऐ̀ခ੓˂˾˙˛ࠬᏭˡзݹԘၓ́˺˙˼⁜ ᐉ˝̡˾ˢ́ছ́ቑ˺ᴈ⁜ ˁᣓऐ̄˂̅ˁ᜜ᜍ̄Ϊ˽ᐉ੤˫̢˼˙̡˂˾˙˛˩˾˽˗̠ᴆ⁜ ˁౣ̔˭˙˂˾˙˛˩˾˽̅̀˙ᴂ˳̢̅˗ˤ̔˽ΰ᛼ᴃᴈ
17. ② 頑丈さ 17 robustness 仕様に明示的に記述されないケースは常にある 破壊的なイベントを引き起こさないようにする 適切なエラーメッセージを出力し，実行をきれいに終了させる 気配りのグレードダウン graceful degradation
18. ③ 拡張性 ϵ൴̄ݴ౏́ࡠ˯̵̡̹̺͑ͩ͜ᛂي̄
    ᣿ে̄˭̚˯˫̄˩˾ 18 extendibility 「変わる」問題をサポートするのが オブジェクト指向の基本的な目標 要求の変更，要求の理解の変化，アルゴリズムの変化，データ表現の変更など
19. ③ 拡張性 19 extendibility 分析: 要求を凍結 残りの過程: 設計と実現に費やす 伝統的なソフトウェア工学 理想的なソフトウェアライフサイクルが前提 法則を発展させるためにすべきこと
 ① 固定された問題について記述し，
 ② それを解決する健全な手法を見出す 途中で問題が変わっていくことを心配しないため
20. ③ 拡張性 20 extendibility 「変わる」という中心的な問題を認識し，対処する． ⇒ 拡張性をもたせることが重要 現代のソフトウェア工学 基本的なソフトウェア工学技術が整った ソフトウェア開発における変化は 全体に，曖昧に発生する！ 要求の変更，要求の理解の変化，アルゴリズムの変化，データ表現の変更など
21. ③ 拡張性 21 extendibility 拡張性を向上させるための重要な原則 ① 設計の単純さ 単純なアーキテクチャは， 常に複雑なアーキテクチャよりも変更に適用しやすい design simplicity ② 非集中化 モジュールの自治性が高まるほど， 単純な変更が与える影響が少ない可能性が高く， システム全体に及ぶ変更の連鎖反応を起こさない decentralization
22. ③ 拡張性 22 extendibility とにかく「単純」で「非集中的」な システムの設計を助ける システムアーキテクチャ手法 オブジェクト指向
23. ④ 再利用性 ݼுݼ൴̵̀ͫ;̈́ΐ͋ͻ·̄൮኱́г႙˽ˢ̡ᴆ
    ̵̹̺͑ͩ͜ᑟդ̄ᛧጧ 23 reusability ソフトウェアシステムの共通するパターンを把握し 再利用可能なソフトウェア要素を他の開発に応用！
24. ④ 再利用性 24 reusability 再利用性の問題を解決すると… 書くソフトウェアが減る！ 同じコストで 正確さや頑丈さなどその他の品質要因の向上に割ける
25. ⑤ 互換性 ̵̹̺͑ͩ͜ᛧጧ̄ᴆ
    ̑ˠ̵̹̺̄͑ͩ͜ᛧጧ˾̄ጷ̕؃̥˱̚˯˫ 25 compatibility ソフトウェアは，相互に作用し合う必要があり， 「何もない世界で開発するのではない」！
26. ⑤ 互換性 26 compatibility 互換性の鍵 1. 設計が同質であること 2. プログラム間のコミュニケーションの
 標準規約が一致していること ex: 標準化されたファイル形式，データ構造，UI
27. ⑤ 互換性 27 compatibility ソフトウェアが操作する 全ての重要なエンティティに対し 標準化されたアクセスプロトコルを定義する 抽象データ型・オブジェクト指向の 基本になる考え方
28. ⑥ 効率性 Ԙၓఓᨌᴆөᤧ᜕੿˟̞̉ݹᤧ᜕੿Κ̄ስᨌᴆ
    ᣓїᚱᏖ˽г႙˯̡ऋܖक̀˿̄ͣΐ̵̹̺͝៧໲̨
    ˽ˢ̡ᨻ̠ীᛧ˾˭̀˙̵̹̺͍͚͑ͩ͋͜ʹ̄ᑟդ 28 efficiency 意味がほぼ同じ言葉に性能がある performance
29. ⑥ 効率性 29 efficiency 効率性に対する業界の人々の態度 性能の問題に固執し，最適化と思われることに 多大な労力を費やす方向に邁進する． A 効率性の問題を軽視する一般的な傾向． 「速くする前に正しいものを作れ」 「来年になれば50%は早いコンピュータが出るのだ」 B 状況によって，同じ人に2つの態度が現れることも珍しくない
30. ⑥ 効率性 30 efficiency 開発に従事する人は「ミクロな最適化」に異様な関心 「正しくなければ効率化はあまり意味がない」 （このことから「正しくないならば，速さを気にするな」という教訓を導くこともできる） 拡張性や，再利用性など，
 他の目標とバランスを取る必要がある 効率性を考えるときには…
31. ⑥ 効率性 31 efficiency 新しく，よりはやいコンピュータを買った人は 以前と同じ問題をより速く解けることを期待するから． 効率性が重要である3つの理由 其の1 ௝˭˙͇·ͨ͹ΐ̨͓г˹˼ᴆ
    Շ˾؇ˮٯ᫷̨؇ˮఓᨌ˽Ԙၓ˭˼˙˵̄˽̅
    ˶̗˶̗̀̄˶᳻᳻᳻
32. ⑥ 効率性 32 efficiency 効率性が重要である3つの理由 其の2 良いアルゴリズムほど 処理能力の向上の影響を受けるから． ᜅ฽˯̏ˢٯ᫷̷̨͉͎̄n
    
    Δ̵ࠬ̄Ϳ͈;͎ʹ˽Ԙၓ˽ˢ̡ౘށ̄ٯ᫷̷̨͉͎
    N ˾˯̡ᴈ
    ᜍኟᥤ
    O(n)
    ̟̀ᴆN ˡށˢ˦̢̆
    2 * N
    ̷͉͎̄̄ٯ᫷̨Ԙၓ˽ˢ̡ᴈ
    O(n2)̟̀ᴆN ̅ጘ˭ˠ݉զ˭̀˙ᴈ
    O(2n)˶˾ᴆN ́ˡᣁզ˫̢̡˶˦˽˗̡ᴈ
33. ⑥ 効率性 33 efficiency 効率が正確さに影響をあたえる場合があるから． 効率性が重要である3つの理由 其の3 ࿲̷ࠬ̄ͭ·́͜ࡠ˯̡েኋ̨
    ࿲ࠬ̄ఓᨌө́࠰ᚄ˭̀˦̢̟̆̀̀˙ϵ൴̄ܭ؃̀˿᳻
34. ⑦ 可搬性 ݼ൴̀ͣΐ̵̹̺͝˟̵̞̹̺̉͑ͩ͜ၵ݆̎̄
    ̵̹̺͑ͩ͜ᛂي̄ላഩ˭̚˯˫˽˗̡ᴈ 34 portability 可搬性における対象は， 物理的なハードウェアのバリエーションだけではなく， もっと広い「ハードウェア-ソフトウェアマシン」のバリエーション hardware-software machine ※ これをプラットフォームと表現する！ platform
35. ⑦ 可搬性 35 portability 既存のプラットフォーム間の非互換性の多くは 正当化できない！ 素人目で見れば， 広くは人間全体の 狭くはプログラマの人間性を貶める戦略なのでは！？ この多様性のために， 可搬性はソフトウェア開発者と利用者の双方の 重要な関心事の1つに
36. ⑧ 使いやすさ ጻ᭢̘៧೙̘Ⴞ̡̀Ϩʺˡ
    ˙ˠ́࠽ః̵̹̺́͑ͩ͜ᛂي̄Χ௟̨ࠕᏺ˭ᴆ
    ٯ᫷ᜅ฽́ে႙˽ˢ̡ˠ˽˗̡ᴈ
    ˩̢́̅ᴆ̷·͍͜ΐͿ̚ᴆஉШᴆᄿᛰ̄࠽ః˫̢̡̘ؔ̔ᴈ 36 ease of use ユーザとなる可能性のある人々の専門知識レベルは 一様ではない！ 上級レベルのユーザ → 仕事に即座に取り掛かる邪魔をしない 入門レベルのユーザ→詳細な指示と説明を与える
37. ⑧ 使いやすさ 37 ease of use 使いやすさへの鍵 構造の単純さ 明確で，十分に考慮された構造に従って構築された 良い設計のシステムは使いやすい！
38. ⑧ 使いやすさ 38 ease of use ユーザインタフェース設計の原則 ˳̄ͺΐ͊̄˩˾̨ᆂ˹˼˙̡ร̡́̀̀ᴈ
    ˗̀˵̅ᆂ̟̀˙ᴈ ユーザについての前提条件を最低ラインにしよう！ ex: ユーザは人類， 読むこと・マウスを動かし・クリックすること・タイプすることができる
39. ⑨ 機能性 ˳͍͚̄͋ʹˡୌн˽ˢ̡͉ΐ͍ͧ̄ኮۖ 39 functionality どの程度の機能性があれば十分かを判断するのは困難！ 機能主義（忍び寄る機能主義）と呼ばれる， より多くの機能を求める圧力は必ず存在する． featurism creeping featurism
40. ⑨ 機能性 40 functionality 機能主義を構成する２つの問題 featurism 新機能の追加で使いやすさ・一貫性が損なわれる 簡単な問題 機能に集中しすぎるあまり， 他の品質要因を忘れがちになること． 困難な問題
41. ⑨ 機能性 41 functionality 簡単な問題の解決方法 製品全体の一貫性についての作業を何度も繰り返し， すべての要素が，ある共通の性質を持つ 1つのかたまりになるようにする． 良いソフトウェアは，少数の強力な概念を基に作られている！ 特殊な機能も，基本的な概念の結果として説明できる 目に見える「全体図」があって， それぞれの要素がその全体図になければならない
42. ⑨ 機能性 42 functionality 困難な問題の解決方法 オブジェクト指向による品質を向上させる技法を用い， 機能性以外の全ての側面で一定の品質レベルを維持する！ 信頼性や拡張性などについては妥協できない ⇒ 機能に満足できない間は，新しい機能に進まない！
43. ⑩ 適時性 ͺΐ͊ˡীᛧ˾˭˼˙̡ఓᴆ
    ̔˵̅ᴆীᛧ˾˯̡Շ̵̺͍͚́͑ͩ͋͜ʹ̨
    ;;ΐ͍˽ˢ̡˩˾ 43 timeliness 我々の産業に対する「圧力」のひとつ ソフトウェア業界の進化は他と比較してもかなり速い
44. そのほかの品質要因 44 ᜫрΏ࠰႙งᩗ́˟˙˼ᴆΜӤ؃̨രԣ˭ᴆ
    ˳̄ΜӤ؃ˠ̟̻ͽΐ̨˵˿̡઺ፓˢ̄໳ҕ˾ᴆ
    ͚͍͛͜ΐ͓̄ק˦ә̢઺ፓˢ̄໳ҕ̄࠽ః˫ 実証性 verifiability ൴ʺ̀൮ટᛧጧᴂͫ΁̓ͽʹ͛̚ΐ͓ᴃ̨
    ᝂᜣ˫̢˼˙̀˙̵͂͏͍̚ћ෥ˠ̡̟͍͚ࠢ͋ʹ̄ᑟդ 統合性 integrity ෍ᩄ̄ћ঴̨ը˦̡ᑟդ 修復性 repairability ᣿ఓৡ˾ࡠ̨̀˯ᴈ
    Ν˝̢̟˵ϊኟ˽͍͚͋ʹ̨ࠥટ˫˱̡˩˾ˡ˽ˢ̡˩˾ 経済性 economy
45. ドキュメントについて 45 ドキュメントの必要性は， これまでに説明した品質要因の結果である
46. ドキュメントについて 46 ユーザがシステムの能力を理解し， 快適に利用できるようにする．（使いやすさの向上） 外部向けドキュメント ソフトウェア開発者が，システムの構造と実装方法を 理解するのを助ける．（拡張性の定義から必要） 内部向けドキュメント
47. ドキュメントについて 47 開発者が，実装方法を理解せずとも モジュールの機能を理解するのを助ける． これがあれば，特定の変更によって， 特定のモジュールが影響をうけるかを判断できる． （拡張性の結果でもある） モジュールインタフェースドキュメント
48. ドキュメントについて 48 ソフトウェア自体をドキュメントにすることが望ましい． ・オンライン「ヘルプ」機能を組み込む ・オブジェクト指向的表現記法によって 情報隠蔽やその他の技法の適用が明確になり， モジュールのインタフェースを実装とは別にできる． ⇒ ドキュメントを自動生成できる ・良い実装言語は，明確さと構造を重視するため， 内部向けドキュメントの必要性はほとんど無くなる
49. トレードオフ 49 外的品質要因についての説明で互いに対立する条件 保護策 使いやすさ 保護策 統合性 経済性 機能性 効率性 可搬性 効率性 再利用性 適時性 拡張性
50. トレードオフ どう対応する？ 1. 正確さのトレードオフはありえない 2. 対立する品質要因を調和させる 3. ある要因のために他の要因を諦める
51. 特に重要な事柄 51 正確さと頑丈さ バグのないソフトウェアを作るのは困難！ バグの修正もまた困難！ ・より体系的なソフトウェア構築 ・より形式的な仕様 ・出来上がってからのテストとデバッグだけでなく， ソフトウェアの構築過程全体に組み込まれているチェック ・欠陥に至らない内に矛盾点を検出するツールの実現を可能にする（静的な型など） 広義の信頼性
52. 特に重要な事柄 52 拡張性と再利用性 プログラムを変えやすくする 自己充足しているコンポーネント群が限定され， 明確に定義された道筋のみ通信するような 非集中化されたアーキテクチャの生成を助ける手法 モジュール性
53. 特に重要な事柄 53 互換性 可搬性 使いやすさ 効率性 適時性，経済性，機能性 先述の4つの品質要因に加え， これらの品質要因の改善にオブジェクト指向は有効
54. ソフトウェアの保守について 54
55. ソフトウェアの保守 55 修正 まっとうな保守 期限を過ぎてからのデバッグ （最初からあるべきではなかったエラーをなくす作業） まっとうではない保守 保守コストの 5分の2以上
56. ソフトウェアの保守 まっとうでない保守に大きなコストを割いている！！ 56 ex: 郵便番号の桁数の変更など 物理的構造のどこかが変更された場合， データの構造がプログラムに埋め込まれている等で 仕様の変更への対応が困難に！
57. 1章のまとめ 57
58. ソフトウェア工学の目的 品質の高いソフトウェアを作る方法の探求 58 品質要因の判断 1つの要因について判断するのではなく， いくつかの異なる指標のバランスを規準に判断 外的品質要因 ユーザと顧客に認識できる要因 設計者や開発者が認識する内的- とは区別すべき
59. 外的品質要因と内的品質要因の関係 最終的に重要な外的品質要因を実現するために 内的品質要因を満たす必要がある 59 オブジェクト指向の守備範囲 安全性に関連する要因 ⇒ 信頼性，モジュール性 ソフトウェアの保守 コストの大きな部分が費やされているが ・ ソフトウェア製品において変更の実装が困難な罰 ・ データの物理構造にプログラムが依存しすぎた罰