オブジェクト指向開発とは何か

オブジェクト指向概論
第５講
オブジェクト指向開発とは何か
立命館大学
情報理工学部
黄 宏軒
1
5.1 なぜオブジェクト指向開発か
n
ソフトウェア開発に対する様々な課題
＝ソフトウェア危機(Software Crisis)
n
危機をどう乗り越えていったらよいか
⇒その解の1つがオブジェクト指向開発
2
ソフトウェア危機（１９６０年代～）
1.
2.
3.
4.
5.
6.
ソフトウェア規模の増大
ソフトウェアコストの増大
バックログ（開発の積み残し）の増大
ソフトウェア生産性の低下
ソフトウェア品質の低下
ソフトウェア技術者の不足
ソフトウェア工学の誕生（1968年）
3
新たなソフトウェア危機
ライフサイクルの短期化
1.
競争の激化によりシステムの開発サイクル，
バージョンアップの間隔が短くなっている
n
n
例：Ｗｅｂサイトの立ち上げ：２～４ヶ月，携帯電話：３～６ヶ月
⇒ 一から作っていられない＝再利用，部分開発
オープンシステム化
2.
ソフトウェア実行のためのハードウェアやＯＳ・ミドルウェア
が多様化
n
n
n
ハードウェア：メインフレーム，ＰＣ，スマホ
ＯＳ：Unix，Windows，macOS，Android，iOS
⇒いろいろなものを組み合わせる技術
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
ユースケースの視点
開発者の視点
ﾓｼﾞｭｰﾙA1とD1
の開発優先度
が高い
ﾕｰｽｹｰｽ1
ﾓｼﾞｭｰﾙA1
ﾕｰｽｹｰｽ2
ﾓｼﾞｭｰﾙA2
ﾓｼﾞｭｰﾙB1
ﾕｰｽｹｰｽ3
ﾓｼﾞｭｰﾙA3
ﾓｼﾞｭｰﾙB2
ﾓｼﾞｭｰﾙC1
ﾕｰｽｹｰｽ4
ﾓｼﾞｭｰﾙA4
ﾓｼﾞｭｰﾙB3
ﾓｼﾞｭｰﾙC2
ﾓｼﾞｭｰﾙD1
ユ
ザ
の
視
点
ﾓｼﾞｭｰﾙD2
ﾓｼﾞｭｰﾙD3
ﾓｼﾞｭｰﾙB4
27
アーキテクチャセントリック
n
システムのベースとなる骨組み（アーキテクチャ）を
優先して開発する
クライアント
Webサーバ
DB
サーバ
基本
DB
アーキテクチャベースラインを確立
28
アーキテクチャセントリックの考え方
開発者の視点
ﾕｰｽｹｰｽ1
ﾓｼﾞｭｰﾙA1
ﾕｰｽｹｰｽ2
ﾓｼﾞｭｰﾙA2
ﾓｼﾞｭｰﾙB1
ﾕｰｽｹｰｽ3
ﾓｼﾞｭｰﾙA3
ﾓｼﾞｭｰﾙB2
ﾓｼﾞｭｰﾙC1
ﾕｰｽｹｰｽ4
ﾓｼﾞｭｰﾙA4
ﾓｼﾞｭｰﾙB3
ﾓｼﾞｭｰﾙC2
ﾓｼﾞｭｰﾙD1
ユ
ザ
の
視
点
ﾓｼﾞｭｰﾙ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
ＸＰ （eXtreme Programming）
n
n
Agile Processの草分け
オブジェクト指向によるインクリメンタルな反復型開発
（UPと同じ）
q
q
q
n
ただし軽量かつ柔軟で俊敏（Agile）を旨とする
短期間（１～２週間単位）でのイテレーション
形式的な完璧さよりも動くことを重視
少数のメンバによる小規模開発
32
ＸＰの追求する４つの価値
n
コミュニケーション（Communication）
q
q
q
n
開発メンバ，顧客と常に対面による的確な情報伝達を
心掛ける
毎朝ミーティング，常に議論，すぐ顧客に確認
（オンサイトカスタマ）
ペアプログラミング（デザイン・コーディングと
レビュー・テストの同時進行）
単純さ（Simplicity）
q
q
必要以上に設計に凝らない．いつでも壊せるつもりでいる．
大掛かりな事前設計の排除（シンプルな設計，
リファクタリング）
33
ＸＰの追求する４つの価値（続き）
n
フィードバック（Feedback）
q
q
n
推測はやめてプログラムに聞け！（こまめにリリース）
テストファースト（まずテストプログラムを書き，成功するよ
うに実装）
勇気（Courage）
q
q
要求や仕様，設計の変更を恐れるな！
小さな絶え間なき改善＝こまめにリリース，リファクタリン
グ重視
34
ＸＰのメリットデメリット
n
メリット
q
q
n
短期間の開発が可能
顧客とともに仕様を検証していくことで，顧客の
要求にあったシステムが作りやすい
デメリット
q
q
q
大規模開発には使えない
開発メンバのスキル（能力）がある程度
そろっていないと難しい
管理がしにくい
35
第５回のまとめ
n
n
n
n
n
新たなソフトウェア危機に対して，オブジェクト指向は解決の
ベースとなりうる
「開発プロセス」とは，システム開発のライフサイクル（開発を
開始してから終了するまでの手順）を示したもの
ウォータフォールモデルは分析／設計／実装／テストを段階
的に行う．管理しやすいが，リスクが後工程まで残りがち
スパイラルモデルは，４つの工程を繰り返しながら開発する．
リスクを早く減らせる
オブジェクト指向モデルは，スパイラルモデルの一種で，コン
ポーネント単位に段階的に開発する
36
第５回のまとめ（続き）
n
n
n
n
代表的なオブジェクト指向開発手法＝Unified Process．管
理された反復型開発，ユースケース駆動，アーキテクチャセ
ントリック，カスタマイズ可能という特徴を持つ
オブジェクト指向開発手法では，記述法としてUML（Unified
Modeling Language）を使う
UPのような重厚長大な開発手法のアンチテーゼがAgile
Process
Agile Processの代表であるXPでは，少人数で短期間の
反復開発を行う．４つの価値（コミュニケーション，単純さ，
フィードバック，勇気）を追求する
37