オブジェクト指向概論第５講オブジェクト指向開発とは何か立命館大学情報理工学部黄　宏軒 1 5.1 なぜオブジェクト指向開発かソフトウェア開発に対する様々な課題＝ソフトウェア危機(Software Crisis) n  危機をどう乗り越えていったらよいか ⇒その解の1つがオブジェクト指向開発 n  2 ソフトウェア危機（１９６０年代～） 1.  2.  3.  4.  5.  6.  ソフトウェア規模の増大ソフトウェアコストの増大バックログ（開発の積み残し）の増大ソフトウェア生産性の低下ソフトウェア品質の低下ソフトウェア技術者の不足ソフトウェア工学の誕生（1968年） 3 新たなソフトウェア危機ライフサイクルの短期化 1.  競争の激化によりシステムの開発サイクル，バージョンアップの間隔が短くなっている n  n  例：Ｗｅｂサイトの立ち上げ：２～４ヶ月，携帯電話：３～６ヶ月 ⇒ 一から作っていられない＝再利用，部分開発オープンシステム化 2.  ソフトウェア実行のためのハードウェアやＯＳ・ミドルウェアが多様化 n  n  例：ハードウェア：メインフレーム，ＰＣ，携帯，ＯＳ：Unix，Windows ⇒いろいろなものを組み合わせる技術 4 新たなソフトウェア危機（続き）インターネットの発展 3.  インターネットでｅビジネスが現実に n  n  例：ネットショッピング，オークション，宿泊予約，… ⇒ いつでも，誰にでも使え，信頼できるシステムが求められる大規模・分散システム化 4.  ネットワークを使っていろいろなシステムを連携 n  n  例：ショッピングサイトとクレジット決済 ⇒複数個のシステムを連携させて１つのサービスを構築する 5 ソフトウェア危機への対応オブジェクト指向開発で乗り切ろう n  ･･･大規模で複雑なものを分解，整理して考えると 1.  コンポーネント開発 q  コンポーネント単位で開発するので，分散システムを作りやすい部品化 2.  q  部品を組み合わせていくので，短期にできる要求変更に強い 3.  q  部分的な変更がしやすいリスクの限定 4.  q  コンポーネント内にリスクを限定できる 6 5.2 開発プロセス n  開発プロセスとは，システム開発のライフサイクル（開発を開始してから終了するまでの手順）を示したもの q  n  分析，設計，実装，テストなどの進め方代表的な開発プロセスのモデルウォーターフォールモデル q  スパイラルモデル q  オブジェクト指向モデル q  7 ウォーターフォールモデル n  システム開発を幾つかの段階に分けて，滝（ウォーターフォール）のように上流工程から下流工程へと順番に開発を進めていく方法システム要件要求定義の定義基本仕様書機能仕様の作成外部設計機能仕様書プログラム構造の設計内部設計管理がしやすい構成仕様書コーディング，単体テストコーディング結合テスト，システムテストプログラムテスト 8 ウォーターフォールモデルの問題点システム要件要求定義の定義完璧にできていることが前提基本仕様書機能仕様の作成外部設計機能仕様書プログラム構造の設計内部設計構成仕様書コーディング，単体テストコーディングやり直し結合テスト，システムテストプログラムテストしかし得てしてこのころに問題発覚！ 9 ウォーターフォールモデルの問題点（続き） n  システムが要求どおりに出来ているかどうか，最後にならないとわからない要求定義受入テスト外部設計内部設計コーディングシステムテスト結合テスト単体テスト 10 ウォーターフォールモデルのリスクリスクがなかなか減らないリスク要求定義外部設計内部設計実装テスト 11 人月の神話＝？ 4人×6ヶ月＝24人月 8人×3ヶ月＝24人月・問題が発生する ↓ ・遅れを取り戻そうと人を投入しても新規要員への知識移転のために遅れは逆に増加する 12 ウォーターフォールモデルの メリット・デメリット n  メリット q  n  開発の進捗状況がわかり易いので，管理しやすいデメリット問題への気づきが遅れがち q  結合テストの頃に発見される問題が多い q  後になればなるほど手戻りが大きい q  開発リスクがなかなか減らない q  13 スパイラルモデル n  システム全体を一度に作るのではなく，分析／設計／実装／テストという工程を何回も繰り返しながらシステムを成長させていく分析テスト設計実装 14 スパイラルモデルのメリット・デメリット n  メリットサイクル毎に検証をすることで，リスクを早く減少させることができる q  前のサイクルの検証結果を反映させることで，仕様の変更に対応しやすい q  新しいシステムに適用しやすい q  n  デメリット q  システムがうまく分割できない場合には適用しにくい 15 オブジェクト指向モデル n  n  n  システムをいくつかのコンポーネントに分割し，分割した部分の組み合わせを単位として，分析・設計・実装・テストを繰り返して開発を進める方法スパイラルモデルの一種オブジェクト指向の考え方と相性が良い 16 オブジェクト指向モデル（続き）分析設計分析設計分析設計テスト実装テスト実装テスト実装反復１回目反復２回目反復３回目ｻｰﾋﾞｽ A ｻｰﾋﾞｽｻｰﾋﾞｽ A B ｻｰﾋﾞｽｻｰﾋﾞｽｻｰﾋﾞｽ B C A ベースコンポーネントベースコンポーネントベースコンポーネント 17 オブジェクト指向モデルのリスク反復するたびにリスクを軽減できるリスク反復１回目反復２回目反復３回目反復４回目 18 オブジェクト指向モデルの メリット・デメリット n  メリット q  q  q  n  サイクル毎に検証をすることで，リスクを早く減少させることができる前のサイクルの検証結果を反映させることで，仕様の変更に対応しやすい出来上がった機能からリリースできるので，短期でｻｰﾋﾞｽを稼動しやすいデメリット q  q  プロジェクト管理が難しい品質管理や構成管理（バージョン管理）が難しく，コストが増加しがち 19 5.3 開発手法 n  開発手法とは q  開発プロセスを具体化し，開発の進め方を定義したもの n  n  n  作業工程の順序・関係各作業工程の内容，手順と入出力成果物利用する成果物（モデル，文書）の構造，記述法 20 オブジェクト指向開発手法のいろいろ Booch OMT OOSE Coad/ Yourdan Martin/ Odell ・・・ Coad Martin/ Odell ・・・ Booch，OMT， OOSEは UPに統合された Unified Process UML ノーテーション（記述法）は UMLに統合された 21 Ｕｎｉｆｉｅｄ　Ｐｒｏｃｅｓｓ（ＵＰ）とは n  n  n  n  n  さまざまなオブジェクト指向型開発手法を統合して作成されたため，「統一プロセス」と呼ばれている作者はGrady Booch（Booch法），Jim Rambaugh（OMT）， Ivar Jacobson（OOSE）．この三人はスリーアミーゴス（three amigos）と呼ばれる記述法としてUMLを用いるオブジェクト指向型開発手法として，標準になりつつあるより具体的に定義したものとして，IBMのRUP（Rational UP）がある． 22 ＵＰの特徴 n  管理されたインクリメンタルな反復型開発 q  n  ユースケース駆動 q  n  ユースケース（ユーザの要求仕様をシステムの利用法という形で記述したもの）を出発点にして開発アーキテクチャセントリック q  n  要求，成果物，人，リスクなどを管理しながら，マイルストーンを設定した計画のもとで反復開発を実施するアーキテクチャ（システムのベースとなる骨組み）を中心に開発を進めるカスタマイズ可能 q  システムによって柔軟にカスタマイズして使える 23 インクリメンタルな反復型開発イテレーション要求分析設計実装テストフェーズ方向づけバージョン１推敲作成バージョン２移行バージョン３ 24 反復型開発のフェーズ n  インセプション（方向づけ）フェーズ q  n  エラボレーション（推敲）フェーズ q  n  システム構築のための核となるアーキテクチャベースラインを作る．骨組みと黄金ルート（必ず通る基本のルート）を作る．コンストラクション（作成）フェーズ q  n  アイデアのプロトタイプの開発と評価．開発を進めるべきか，止めるべきかを判断する．システムとして仕上げる．β版のリリースが目標．トランジション（移行）フェーズ q  β版のリリースとフィールドでの評価結果の反映． 25 ユースケース駆動要求分析設計実装テストﾕｰｽｹｰｽﾓﾃﾞﾙ分析ﾓﾃﾞﾙ設計ﾓﾃﾞﾙﾃﾞﾌﾟﾛｲﾒﾝﾄﾓﾃﾞﾙ実装ﾓﾃﾞﾙ仕様書設計書ﾃｽﾄﾓﾃﾞﾙ配備図ﾌﾟﾛｸﾞﾗﾑﾃｽﾄ仕様書 26 ユースケースの視点開発者の視点ﾕｰｽｹｰｽ1 ﾓｼﾞｭｰﾙA1とD1 の開発優先度が高いﾓｼﾞｭｰﾙA1 ﾓｼﾞｭｰﾙD1 ーﾕｰｽｹｰｽ2 ﾓｼﾞｭｰﾙA2 ﾓｼﾞｭｰﾙB1 視点ﾕｰｽｹｰｽ3 ﾓｼﾞｭｰﾙA3 ﾓｼﾞｭｰﾙB2 ﾓｼﾞｭｰﾙC1 ﾕｰｽｹｰｽ4 ﾓｼﾞｭｰﾙA4 ﾓｼﾞｭｰﾙB3 ﾓｼﾞｭｰﾙC2 ﾓｼﾞｭｰﾙD2 ﾓｼﾞｭｰﾙD3 ﾓｼﾞｭｰﾙB4 27 アーキテクチャセントリック n  システムのベースとなる骨組み（アーキテクチャ）を優先して開発するクライアント Webサーバ DB サーバ基本 DB アーキテクチャベースラインを確立 28 アーキテクチャセントリックの考え方開発者の視点ﾕｰｽｹｰｽ1 ﾓｼﾞｭｰﾙA1 ﾓｼﾞｭｰﾙD1 ーﾕｰｽｹｰｽ2 ﾓｼﾞｭｰﾙA2 ﾓｼﾞｭｰﾙB1 視点ﾕｰｽｹｰｽ3 ﾓｼﾞｭｰﾙA3 ﾓｼﾞｭｰﾙB2 ﾓｼﾞｭｰﾙC1 ﾕｰｽｹｰｽ4 ﾓｼﾞｭｰﾙA4 ﾓｼﾞｭｰﾙB3 ﾓｼﾞｭｰﾙC2 ﾓｼﾞｭｰﾙD2 ﾓｼﾞｭｰﾙD3 ﾓｼﾞｭｰﾙB4 ﾓｼﾞｭｰﾙA3～D3を優先して開発 29 アジャイルプロセス（Agile Process） n  重厚長大な開発手法（UP）に対するアンチテーゼ q  n  Agile Manifesto q  q  n  小さいシステムはもっと簡単に作ってもいいだろう 2001年2月 Kent Beckを始めとする軽量プロセスの提唱者による宣言 http://www.agilemanifesto.org 状況に対して柔軟にかつ迅速に対応する q  スキルのある開発者が10名以下で作れる開発規模 30 アジャイルプロセスの特徴 n  プロセスやツールよりも q  n  大量の詳細なドキュメントやモデルよりも q  n  検証可能な動くソフトウェアに基づくことが大事契約上の駆け引きよりも q  n  開発者個人の能力や相互コミュニケーションが大事顧客とのコラボレーションが大事計画を硬直的に守ることよりも q  変化に柔軟に対応することが大事 31 いろいろなＡｇｉｌｅＰｒｏｃｅｓｓ n  n  n  n  n  n  XP: eXtreme Programming SCRUM ASD: Adaptive Software Development FDD: Feature Driven Development DSDM: Dynamic Systems Development Method LD: Lean Development 32 ＸＰ（eXtreme Programming） n  n  Agile Processの草分けオブジェクト指向によるインクリメンタルな反復型開発（UPと同じ） q  q  q  n  ただし軽量かつ柔軟で俊敏（Agile）を旨とする短期間（１～２週間単位）でのイテレーション形式的な完璧さよりも動くことを重視少数のメンバによる小規模開発 33 ＸＰの追求する４つの価値 n  コミュニケーション（Communication） q  q  q  n  開発メンバ，顧客と常に対面による的確な情報伝達を心掛ける毎朝ミーティング，常に議論，すぐ顧客に確認（オンサイトカスタマ）ペアプログラミング（デザイン・コーディングとレビュー・テストの同時進行）単純さ（Simplicity） q  q  必要以上に設計に凝らない．いつでも壊せるつもりでいる．大掛かりな事前設計の排除（シンプルな設計，リファクタリング） 34 ＸＰの追求する４つの価値（続き） n  フィードバック（Feedback） q  q  n  推測はやめてプログラムに聞け！（こまめにリリース）テストファースト（まずテストプログラムを書き，成功するように実装）勇気（Courage） q  q  要求や仕様，設計の変更を恐れるな！小さな絶え間なき改善＝こまめにリリース，リファクタリング重視 35 ＸＰの１２のプラクティス n  n  n  n  n  n  n  n  n  n  計画ゲーム→Planninng Game ペアプログラミング→Pair Programming こまめにリリース→Small Releases コードの共同所有→Collective Ownership メタファ→Metaphor 継続的インテグレーション→Continuous Integration シンプルな設計→Simple Design 週40時間労働→40-Hour Week テスティング→Testing オンサイト顧客→On-site Customer 36 ＸＰの１２のプラクティス（続き） n  n  n  n  リファクタリング→Refactoring コーディング規約→Coding Standard オープンな開発スペース→Open Workspace 日ごとのスキーマ進化→Daily Schema Migration 37 ＸＰのメリットデメリット n  メリット短期間の開発が可能 q  顧客とともに仕様を検証していくことで，顧客の要求にあったシステムが作りやすい q  n  デメリット大規模開発には使えない q  開発メンバのスキル（能力）がある程度そろっていないと難しい q  管理がしにくい q  38 第５回のまとめ n  n  n  n  n  新たなソフトウェア危機に対して，オブジェクト指向は解決のベースとなりうる「開発プロセス」とは，システム開発のライフサイクル（開発を開始してから終了するまでの手順）を示したものウォータフォールモデルは分析／設計／実装／テストを段階的に行う．管理しやすいが，リスクが後工程まで残りがちスパイラルモデルは，４つの工程を繰り返しながら開発する．リスクを早く減らせるオブジェクト指向モデルは，スパイラルモデルの一種で，コンポーネント単位に段階的に開発する 39 第５回のまとめ（続き） n  n  n  n  代表的なオブジェクト指向開発手法＝Unified Process．管理された反復型開発，ユースケース駆動，アーキテクチャセントリック，カスタマイズ可能という特徴を持つオブジェクト指向開発手法では，記述法としてUML（Unified Modeling Language）を使う UPのような重厚長大な開発手法のアンチテーゼがAgile Process Agile Processの代表であるXPでは，少人数で短期間の反復開発を行う．４つの価値（コミュニケーション，単純さ，フィードバック，勇気）を追求する 40