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

Slide 1

Slide 1 text

1人オブジェクト指向勉強会 ̺̽ͪ͌͂͜ଉ،әᨃቻ࿣ 第1章ソフトウェアの品質 Hagihara Ryosuke ( @raryosu ) 2017.12.01 1 Update: 2017.12.03

Slide 2

Slide 2 text

はじめに 2

Slide 3

Slide 3 text

はじめに本スライドは， @raryosu がバートランド・メイヤー著  “オブジェクト指向入門第２版” (翔泳社, 2007) を読みながら，  オブジェクト指向への理解を深めるためのものです．ひたすら読みながら内容をまとめていきます．いつ終わるかな． 3

Slide 4

Slide 4 text

ソフトウェアの品質とは 4

Slide 5

Slide 5 text

ソフトウェアの品質ユーザが認識できる性質 5 外的品質要因 ex: スピード・使いやすさ内的品質要因 ex: モジュール性・可読性その他の性質

Slide 6

Slide 6 text

ソフトウェアの品質外的品質要因内的品質要因設計者やプログラマが保証する必要がある外的品質を保証するために重要最終的に問題になる！！ 6 ユーザにとっては内部のことより興味がある

Slide 7

Slide 7 text

ソフトウェアの品質内的品質要因は外的品質要因を保証する手段に過ぎない 7 全体を見失ってしまわないように注意！

Slide 8

Slide 8 text

外的品質要因 8

Slide 9

Slide 9 text

外的品質要因 ① 正確さ ② 頑丈さ ③ 拡張性 ④ 再利用性 ⑤ 互換性 9 ⑥ 効率性 ⑦ 可搬性 ⑧ 使いやすさ ⑨ 機能性 ⑩ 適時性

Slide 10

Slide 10 text

① 正確さ ϵ൴̞́˹˼ࠬᏭ˫̢˼˙̡˾˟̠́ϵύ̨࠰ᚄ˯̡ ̵̹̺͑ͩ͜ᛂي̄ᑟդ 10 correctness すべきことをシステムが適切に実行すること正確さは第１の要件である．

Slide 11

Slide 11 text

① 正確さ 11 correctness 正確さの保証 ⇒ 前提条件依存システムは複数のレイヤの上に成り立っている

Slide 12

Slide 12 text

① 正確さ 12 correctness 高水準言語Xによる実装の正確さはアプリケーションコンパイラ OS ハードウェアコンパイラの実装が正確である前提「より下の層が正しい」という前提のもとで個々の層が正しいことを保証する！

Slide 13

Slide 13 text

① 正確さ 13 correctness 型付けと表明などの技法により最初から正確なソフトウェアの構築を支援できる typing assertion ※後述その成果を確認する手段として「デバッグ」と「テスト」は欠かせない

Slide 14

Slide 14 text

② 頑丈さ Ⴞऐ̀ಅЄ́ࡠ˭˼᣿Ԫ́᣿ে˯̡ ̵̹̺͍͚͑ͩ͋͜ʹ̄ᑟդ 14 robustness 頑丈さは，正確さを補完するものである．

Slide 15

Slide 15 text

② 頑丈さ 15 robustness 頑丈さ仕様正確さ仕様に記述されている場合のシステムの振る舞い正確さ仕様以外のところで起きることについての特徴頑丈さ

Slide 16

Slide 16 text

② 頑丈さ 16 robustness 頑丈さは，正確さに比べ「曖昧」な概念 ˁᣓऐ̄ခ੓˂ˁႾऐ̀ခ੓˂˾˙˛̄̅ϵ൴́໳˰̡ᴈ⁜ ˩̄ˁႾऐ̀ခ੓˂˾˙˛ࠬᏭˡзݹԘၓ́˺˙˼⁜ ᐉ˝̡˾ˢ́ছ́ቑ˺ᴈ⁜ ˁᣓऐ̄˂̅ˁ᜜ᜍ̄Ϊ˽ᐉ੤˫̢˼˙̡˂˾˙˛˩˾˽˗̠ᴆ⁜ ˁౣ̔˭˙˂˾˙˛˩˾˽̅̀˙ᴂ˳̢̅˗ˤ̔˽ΰ᛼ᴃᴈ

Slide 17

Slide 17 text

② 頑丈さ 17 robustness 仕様に明示的に記述されないケースは常にある破壊的なイベントを引き起こさないようにする適切なエラーメッセージを出力し，実行をきれいに終了させる気配りのグレードダウン graceful degradation

Slide 18

Slide 18 text

③ 拡張性 ϵ൴̄ݴ౏́ࡠ˯̵̡̹̺͑ͩ͜ᛂي̄ ᣿ে̄˭̚˯˫̄˩˾ 18 extendibility 「変わる」問題をサポートするのがオブジェクト指向の基本的な目標要求の変更，要求の理解の変化，アルゴリズムの変化，データ表現の変更など

Slide 19

Slide 19 text

③ 拡張性 19 extendibility 分析: 要求を凍結残りの過程: 設計と実現に費やす伝統的なソフトウェア工学理想的なソフトウェアライフサイクルが前提法則を発展させるためにすべきこと  ① 固定された問題について記述し，  ② それを解決する健全な手法を見出す途中で問題が変わっていくことを心配しないため

Slide 20

Slide 20 text

③ 拡張性 20 extendibility 「変わる」という中心的な問題を認識し，対処する． ⇒ 拡張性をもたせることが重要現代のソフトウェア工学基本的なソフトウェア工学技術が整ったソフトウェア開発における変化は全体に，曖昧に発生する！要求の変更，要求の理解の変化，アルゴリズムの変化，データ表現の変更など

Slide 21

Slide 21 text

③ 拡張性 21 extendibility 拡張性を向上させるための重要な原則 ① 設計の単純さ単純なアーキテクチャは，常に複雑なアーキテクチャよりも変更に適用しやすい design simplicity ② 非集中化モジュールの自治性が高まるほど，単純な変更が与える影響が少ない可能性が高く，システム全体に及ぶ変更の連鎖反応を起こさない decentralization

Slide 22

Slide 22 text

③ 拡張性 22 extendibility とにかく「単純」で「非集中的」なシステムの設計を助けるシステムアーキテクチャ手法オブジェクト指向

Slide 23

Slide 23 text

④ 再利用性 ݼுݼ൴̵̀ͫ;̈́ΐ͋ͻ·̄൮኱́г႙˽ˢ̡ᴆ ̵̹̺͑ͩ͜ᑟդ̄ᛧጧ 23 reusability ソフトウェアシステムの共通するパターンを把握し再利用可能なソフトウェア要素を他の開発に応用！

Slide 24

Slide 24 text

④ 再利用性 24 reusability 再利用性の問題を解決すると… 書くソフトウェアが減る！同じコストで正確さや頑丈さなどその他の品質要因の向上に割ける

Slide 25

Slide 25 text

⑤ 互換性 ̵̹̺͑ͩ͜ᛧጧ̄ᴆ ̑ˠ̵̹̺̄͑ͩ͜ᛧጧ˾̄ጷ̕؃̥˱̚˯˫ 25 compatibility ソフトウェアは，相互に作用し合う必要があり，「何もない世界で開発するのではない」！

Slide 26

Slide 26 text

⑤ 互換性 26 compatibility 互換性の鍵 1. 設計が同質であること 2. プログラム間のコミュニケーションの  標準規約が一致していること ex: 標準化されたファイル形式，データ構造，UI

Slide 27

Slide 27 text

⑤ 互換性 27 compatibility ソフトウェアが操作する全ての重要なエンティティに対し標準化されたアクセスプロトコルを定義する抽象データ型・オブジェクト指向の基本になる考え方

Slide 28

Slide 28 text

⑥ 効率性 Ԙၓఓᨌᴆөᤧ᜕੿˟̞̉ݹᤧ᜕੿Κ̄ስᨌᴆ ᣓїᚱᏖ˽г႙˯̡ऋܖक̀˿̄ͣΐ̵̹̺͝៧໲̨ ˽ˢ̡ᨻ̠ীᛧ˾˭̀˙̵̹̺͍͚͑ͩ͋͜ʹ̄ᑟդ 28 efficiency 意味がほぼ同じ言葉に性能がある performance

Slide 29

Slide 29 text

⑥ 効率性 29 efficiency 効率性に対する業界の人々の態度性能の問題に固執し，最適化と思われることに多大な労力を費やす方向に邁進する． A 効率性の問題を軽視する一般的な傾向．「速くする前に正しいものを作れ」「来年になれば50%は早いコンピュータが出るのだ」 B 状況によって，同じ人に2つの態度が現れることも珍しくない

Slide 30

Slide 30 text

⑥ 効率性 30 efficiency 開発に従事する人は「ミクロな最適化」に異様な関心「正しくなければ効率化はあまり意味がない」（このことから「正しくないならば，速さを気にするな」という教訓を導くこともできる）拡張性や，再利用性など，  他の目標とバランスを取る必要がある効率性を考えるときには…

Slide 31

Slide 31 text

⑥ 効率性 31 efficiency 新しく，よりはやいコンピュータを買った人は以前と同じ問題をより速く解けることを期待するから．効率性が重要である3つの理由其の1 ௝˭˙͇·ͨ͹ΐ̨͓г˹˼ᴆ Շ˾؇ˮٯ᫷̨؇ˮఓᨌ˽Ԙၓ˭˼˙˵̄˽̅ ˶̗˶̗̀̄˶᳻᳻᳻

Slide 32

Slide 32 text

⑥ 効率性 32 efficiency 効率性が重要である3つの理由其の2 良いアルゴリズムほど処理能力の向上の影響を受けるから． ᜅ฽˯̏ˢٯ᫷̷̨͉͎̄n Δ̵ࠬ̄Ϳ͈;͎ʹ˽Ԙၓ˽ˢ̡ౘށ̄ٯ᫷̷̨͉͎N ˾˯̡ᴈ ᜍኟᥤO(n)̟̀ᴆN ˡށˢ˦̢̆2 * N̷͉͎̄̄ٯ᫷̨Ԙၓ˽ˢ̡ᴈ O(n2)̟̀ᴆN ̅ጘ˭ˠ݉զ˭̀˙ᴈ O(2n)˶˾ᴆN ́ˡᣁզ˫̢̡˶˦˽˗̡ᴈ

Slide 33

Slide 33 text

⑥ 効率性 33 efficiency 効率が正確さに影響をあたえる場合があるから．効率性が重要である3つの理由其の3 ࿲̷ࠬ̄ͭ·́͜ࡠ˯̡েኋ̨ ࿲ࠬ̄ఓᨌө́࠰ᚄ˭̀˦̢̟̆̀̀˙ϵ൴̄ܭ؃̀˿᳻

Slide 34

Slide 34 text

⑦ 可搬性 ݼ൴̀ͣΐ̵̹̺͝˟̵̞̹̺̉͑ͩ͜ၵ݆̎̄ ̵̹̺͑ͩ͜ᛂي̄ላഩ˭̚˯˫˽˗̡ᴈ 34 portability 可搬性における対象は，物理的なハードウェアのバリエーションだけではなく，もっと広い「ハードウェア-ソフトウェアマシン」のバリエーション hardware-software machine ※ これをプラットフォームと表現する！ platform

Slide 35

Slide 35 text

⑦ 可搬性 35 portability 既存のプラットフォーム間の非互換性の多くは正当化できない！素人目で見れば，広くは人間全体の狭くはプログラマの人間性を貶める戦略なのでは！？この多様性のために，可搬性はソフトウェア開発者と利用者の双方の重要な関心事の1つに

Slide 36

Slide 36 text

⑧ 使いやすさ ጻ᭢̘៧೙̘Ⴞ̡̀Ϩʺˡ ˙ˠ́࠽ః̵̹̺́͑ͩ͜ᛂي̄Χ௟̨ࠕᏺ˭ᴆ ٯ᫷ᜅ฽́ে႙˽ˢ̡ˠ˽˗̡ᴈ ˩̢́̅ᴆ̷·͍͜ΐͿ̚ᴆஉШᴆᄿᛰ̄࠽ః˫̢̡̘ؔ̔ᴈ 36 ease of use ユーザとなる可能性のある人々の専門知識レベルは一様ではない！上級レベルのユーザ → 仕事に即座に取り掛かる邪魔をしない入門レベルのユーザ→詳細な指示と説明を与える

Slide 37

Slide 37 text

⑧ 使いやすさ 37 ease of use 使いやすさへの鍵構造の単純さ明確で，十分に考慮された構造に従って構築された良い設計のシステムは使いやすい！

Slide 38

Slide 38 text

⑧ 使いやすさ 38 ease of use ユーザインタフェース設計の原則 ˳̄ͺΐ͊̄˩˾̨ᆂ˹˼˙̡ร̡́̀̀ᴈ ˗̀˵̅ᆂ̟̀˙ᴈ ユーザについての前提条件を最低ラインにしよう！ ex: ユーザは人類，読むこと・マウスを動かし・クリックすること・タイプすることができる

Slide 39

Slide 39 text

⑨ 機能性 ˳͍͚̄͋ʹˡୌн˽ˢ̡͉ΐ͍ͧ̄ኮۖ 39 functionality どの程度の機能性があれば十分かを判断するのは困難！機能主義（忍び寄る機能主義）と呼ばれる，より多くの機能を求める圧力は必ず存在する． featurism creeping featurism

Slide 40

Slide 40 text

⑨ 機能性 40 functionality 機能主義を構成する２つの問題 featurism 新機能の追加で使いやすさ・一貫性が損なわれる簡単な問題機能に集中しすぎるあまり，他の品質要因を忘れがちになること．困難な問題

Slide 41

Slide 41 text

⑨ 機能性 41 functionality 簡単な問題の解決方法製品全体の一貫性についての作業を何度も繰り返し，すべての要素が，ある共通の性質を持つ 1つのかたまりになるようにする．良いソフトウェアは，少数の強力な概念を基に作られている！特殊な機能も，基本的な概念の結果として説明できる目に見える「全体図」があって，それぞれの要素がその全体図になければならない

Slide 42

Slide 42 text

⑨ 機能性 42 functionality 困難な問題の解決方法オブジェクト指向による品質を向上させる技法を用い，機能性以外の全ての側面で一定の品質レベルを維持する！信頼性や拡張性などについては妥協できない ⇒ 機能に満足できない間は，新しい機能に進まない！

Slide 43

Slide 43 text

⑩ 適時性 ͺΐ͊ˡীᛧ˾˭˼˙̡ఓᴆ ̔˵̅ᴆীᛧ˾˯̡Շ̵̺͍͚́͑ͩ͋͜ʹ̨ ;;ΐ͍˽ˢ̡˩˾ 43 timeliness 我々の産業に対する「圧力」のひとつソフトウェア業界の進化は他と比較してもかなり速い

Slide 44

Slide 44 text

そのほかの品質要因 44 ᜫрΏ࠰႙งᩗ́˟˙˼ᴆΜӤ؃̨രԣ˭ᴆ ˳̄ΜӤ؃ˠ̟̻ͽΐ̨˵˿̡઺ፓˢ̄໳ҕ˾ᴆ ͚͍͛͜ΐ͓̄ק˦ә̢઺ፓˢ̄໳ҕ̄࠽ః˫ 実証性 veriﬁability ൴ʺ̀൮ટᛧጧᴂͫ΁̓ͽʹ͛̚ΐ͓ᴃ̨ ᝂᜣ˫̢˼˙̀˙̵͂͏͍̚ћ෥ˠ̡̟͍͚ࠢ͋ʹ̄ᑟդ 統合性 integrity ෍ᩄ̄ћ঴̨ը˦̡ᑟդ 修復性 repairability ᣿ఓৡ˾ࡠ̨̀˯ᴈ Ν˝̢̟˵ϊኟ˽͍͚͋ʹ̨ࠥટ˫˱̡˩˾ˡ˽ˢ̡˩˾ 経済性 economy

Slide 45

Slide 45 text

ドキュメントについて 45 ドキュメントの必要性は，これまでに説明した品質要因の結果である

Slide 46

Slide 46 text

ドキュメントについて 46 ユーザがシステムの能力を理解し，快適に利用できるようにする．（使いやすさの向上）外部向けドキュメントソフトウェア開発者が，システムの構造と実装方法を理解するのを助ける．（拡張性の定義から必要）内部向けドキュメント

Slide 47

Slide 47 text

ドキュメントについて 47 開発者が，実装方法を理解せずともモジュールの機能を理解するのを助ける．これがあれば，特定の変更によって，特定のモジュールが影響をうけるかを判断できる．（拡張性の結果でもある）モジュールインタフェースドキュメント

Slide 48

Slide 48 text

ドキュメントについて 48 ソフトウェア自体をドキュメントにすることが望ましい．・オンライン「ヘルプ」機能を組み込む・オブジェクト指向的表現記法によって情報隠蔽やその他の技法の適用が明確になり，モジュールのインタフェースを実装とは別にできる． ⇒ ドキュメントを自動生成できる・良い実装言語は，明確さと構造を重視するため，内部向けドキュメントの必要性はほとんど無くなる

Slide 49

Slide 49 text

トレードオフ 49 外的品質要因についての説明で互いに対立する条件保護策使いやすさ保護策統合性経済性機能性効率性可搬性効率性再利用性適時性拡張性

Slide 50

Slide 50 text

トレードオフどう対応する？ 1. 正確さのトレードオフはありえない 2. 対立する品質要因を調和させる 3. ある要因のために他の要因を諦める

Slide 51

Slide 51 text

特に重要な事柄 51 正確さと頑丈さバグのないソフトウェアを作るのは困難！バグの修正もまた困難！・より体系的なソフトウェア構築・より形式的な仕様・出来上がってからのテストとデバッグだけでなく，ソフトウェアの構築過程全体に組み込まれているチェック・欠陥に至らない内に矛盾点を検出するツールの実現を可能にする（静的な型など）広義の信頼性

Slide 52

Slide 52 text

特に重要な事柄 52 拡張性と再利用性プログラムを変えやすくする自己充足しているコンポーネント群が限定され，明確に定義された道筋のみ通信するような非集中化されたアーキテクチャの生成を助ける手法モジュール性

Slide 53

Slide 53 text

特に重要な事柄 53 互換性可搬性使いやすさ効率性適時性，経済性，機能性先述の4つの品質要因に加え，これらの品質要因の改善にオブジェクト指向は有効

Slide 54

Slide 54 text

ソフトウェアの保守について 54

Slide 55

Slide 55 text

ソフトウェアの保守 55 修正まっとうな保守期限を過ぎてからのデバッグ（最初からあるべきではなかったエラーをなくす作業）まっとうではない保守保守コストの 5分の2以上

Slide 56

Slide 56 text

ソフトウェアの保守まっとうでない保守に大きなコストを割いている！！ 56 ex: 郵便番号の桁数の変更など物理的構造のどこかが変更された場合，データの構造がプログラムに埋め込まれている等で仕様の変更への対応が困難に！

Slide 57

Slide 57 text

1章のまとめ 57

Slide 58

Slide 58 text

ソフトウェア工学の目的品質の高いソフトウェアを作る方法の探求 58 品質要因の判断 1つの要因について判断するのではなく，いくつかの異なる指標のバランスを規準に判断外的品質要因ユーザと顧客に認識できる要因設計者や開発者が認識する内的- とは区別すべき

Slide 59

Slide 59 text

外的品質要因と内的品質要因の関係最終的に重要な外的品質要因を実現するために内的品質要因を満たす必要がある 59 オブジェクト指向の守備範囲安全性に関連する要因 ⇒ 信頼性，モジュール性ソフトウェアの保守コストの大きな部分が費やされているが・ソフトウェア製品において変更の実装が困難な罰・データの物理構造にプログラムが依存しすぎた罰