┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.26 2003/12/10
■ I N D E X
┃
┣【ＰＭ】プロジェクトマネジメント入門 [9]
┗【プログラミング】ソフトウェア原則 [4] ISP(Interface Segregation Principle)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【ＰＭ】プロジェクトマネジメント入門 [9]
プロジェクトマネジメント入門の9回目。今回も「プロジェクトマネジメントの
歴史と手法」に関してお話したいと思います。
前回は、タスクと時間軸から各タスクの作業の期間と実施する関連を表す「ガ
ントチャート（バーチャート）」について話をしました。今回は、ＰＥＲＴ
（パート）について話をします。
ＰＥＲＴは、作業の所要時間と作業の前後関係を表すことでスケジュールを管
理する手法で、1958年にロッキード社が中心となって開発され、米国の国防プ
ロジェクトに多く適用されました。余談ですが、このＰＥＲＴ手法の考え方に
プロジェクトで使用するリソースについても扱えるように拡張した手法
（ＰＥＲＴ／ＣＯＳＴ）が米国国防省により開発され、更にアーンドバリュー
（ＥａｒｎｅｄＶａｌｕｅ）の概念ができ、米国国防省（ＤＯＤ）のプロジェ
クトマネジメントに関する基礎が確立されたと聞いています。
本題に戻ります。ＰＥＲＴは、多分、バーチャートより皆さんに馴染みがない
と思いますので簡単に基本記号を説明します。基本記号は、丸（○）と矢印（→）
の2つから構成されています。ＰＥＲＴでは、丸を「イベント（結合点）」と称
して作業の開始・終了を表し、矢印を「アクティビティ（作業）」と称して作
業を表します。ＵＭＬのアクティビティ図と比べてみると、丸（ＵＭＬは四角
ですが）と矢印が逆さまになっているので、ＵＭＬのアクティビティ図に慣れ
ている方は間違えやすいので注意が必要ですね。
このＰＥＲＴ図は、作業の前後関係が厳密なプロジェクトには有効です。私達
の業界ではどうでしょうか？ また、「クリティカルパス（最長経路）」が明
確になってくるので、納期を短縮する対策には有効でしょう。ちなみに、
ＰＥＲＴ図上には、このクリティカルパスを太い矢印で表します。
このように作業時間とその関係を明確化することで、作業の順番とクリティカ
ルパスが分かり、作業期間の見積もりが可能となります。
次回も今回に引き続き、プロジェクトマネジメントの手法に関してお話します。
（事務局長）
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?F001+8+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?F001+8+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?F001+8+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【プログラミング】ソフトウェア原則 [4] ISP(Interface Segregation Principle)
前回までで、クラスは１つの責務を持つべきである、というSRP
(Single Responsibility Principle)を紹介し、その際、クラスの「名前付け」
が非常に重要である、ということに触れました。
そして、名前にまつわるエピソードとして、JTP(Joshua Tree Principle)と
"Name and Conquer"について話しました。
今回は、どうやってクラス間の結合を減らすか、ということについて考えてみ
たいと思います。
クラスがさまざまな他のクラスと関連を持ち始めると、そのクラスが「太って」
しまうことがよくあります。これを、"fat interface"とか、アンチパターンの
言葉で"The Blob"(肥満児)と呼びます。つまり、関連するクラス毎にメソッド
が多くなり、このクラス用のメソッド群と、このクラス用のメソッド群と、と
いう具合にどんどんクラスが肥大化してしまう。さらに悪いことに、これらの
関連するクラス群すべてが、この大きなクラスに依存関係を持ってしまうので
す。
この肥満児クラスに変更が起こると、その変更はいたるところに伝播し、シス
テム全体に渡る修正インパクトが出てしまします。これをなんとか避けたい、
というのが動機です。
ISP(Interface Segregation Principle)は、Robert C. Martin(*1)による原則
で、
クライアントは自分が使わないメソッドに依存することを強制されない。
Clients should not forced to depend on methods that they don't use.
というものです。クライアントが本当に必要としているインターフェイスのみ
が、クライアントから見えるべきで、他のメソッドには依存したくない。依存
を最小にして、変更の伝播を最小限に食い止めたい。Segregationとは分割、分
離、という意味です。つまり、ISPは「インターフェイスをクライアント毎に分
離しよう」という原則なのです。
では、どのようにインターフェイスを分離するか。例えば、「Buttonが押され
たらDoorが開く」、というアプリケーションを考えてみましょう。素直にやれ
ば、Button クラスのbuttonPressed（）というコールバックメソッドから、
Doorクラスのopen（）メソッドを呼ぶ、という実装が考えられるでしょう。し
かし、この戦略は、ボタンとドアの両クラスを直接依存させてしまします。本
来、ボタンという抽象とドアという抽象は独立しており、これらの間にはほと
んど関係がありません。
１つのISP的な解決策は、ButtonListener というボタンの押下イベントを受け
取るインターフェイスを作成し、Door クラスがこのインターフェイスを実装す
る、というものです。これは、「インターフェイスによる分離」という方法で
す。こうすることで、Button クラスは ButtonListenerというインターフェイ
スのみに依存し、Doorクラスには依存しなくなります。
また、さらに「Timerがタイムアウトしたら、Doorがロックされる」という要求
があれば、ここでも、Timerクラスから直接Doorのlock()メソッドを呼ぶのでは
なく、TimerListener というタイムアウトイベントを受け取るインターフェイ
スを作成し、Doorクラスがこのインターフェイスを実装する。
UMLで記述すると、こんな感じになります（等幅フォントで見てください）。
┌───┐ ButtonListener ┌────────┐
│Button├…→○─────┤ Door │
└───┘+buttonPressed()├────────┤
│+buttonPressed()│
┌───┐ TimerListener │+timeOut() │
│Timer ├…→○─────┤+open() │
└───┘+timeOut() │+lock() │
└────────┘
こうすることで、Button や Timer が直接 Door と依存しなくなります。しか
し、こうしても Door の肥大化は避けられません。さらにもう一段進んだ分離
は、Button と Door の間に ButtonDoorAdapter クラスを、Timer と Door の
間に TimerDoorAdapter クラスを挟むことです。これを「委譲による分離」と
言います。こうすれば、ButtonDoorAdapterクラスがButtonListenerを実装し、
そのbuttonPressed()の中から Door クラスの open() を呼び出す、という構造
になり、Door という抽象を汚すことなく、Door と Button の実行時の連携を
実現できます。
┌───┐ ButtonListener ┌────────┐ ┌────┐
│Button├…→○─────┤ButtonDoorAdapte├─┤Door │
└───┘+buttonPressed()├────────┤ ├────┤
│+buttonPressed()│ │+open() │
└────────┘ │+lock() │
┌───┐ TimerListener ┌────────┐ │ │
│Timer ├…→○─────┤TimerDoorAdapter├─┤ │
└───┘+timeOut() ├────────┤ │ │
│+timeOut() │ │ │
└────────┘ └────┘
* * *
なるべく依存関係を減らすこと。これが、クラス間の結合度(Coupling)を減ら
すポイントになります。その考え方として、ISPという原則と、「インターフェ
イスによる分離」および「委譲による分離」という戦略があります。
ちなみに、イベントを受け取るインターフェイスとしてのListener(リスナー)
というinterfaceは、Javaがイベントモデルを定義してから非常によく使われる
命名となってきており、この流儀はC#にも受け継がれています。現在、Javaや
C#では半ば常識的となっている手法です。
（平鍋）
*1: "Agile Software Development", Prentice Hall, 2003
*文中の図がずれる方はこちらをご参照ください。
http://www.ObjectClub.jp/ml-arch/magazine/magazine26/door_class.html
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E001+5+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E001+5+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E001+5+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
オブジェクト倶楽部クリスマス会まで、あと1週間と迫ってきました。スタッフ
総出で準備におおわらわです。どんなことになるか、不安と期待とが入り混じっ
て、既に緊張感が増しつつある今日この頃です。皆さんとご対面できることを
何よりも、心待ちにしております。
（さとみ）
このメールマガジンの登録会員数が、先週末、とうとう1000人を突破しました。
今年の6月から、最初は300人程度で始めたメルマガでしたが、年末を前に一区
切りとすることができました。これも、開発現場での、オブジェクト指向に対
する需要を表しているといえるのでしょうか。
今後とも、オブジェクト倶楽部では、「より良いシステムを作りたい」と考え
る、システム開発に携わる人々に、より「役に立つ」コンテンツをお届けして
いくことを目指します。ご愛顧、よろしくお願いします。
（いりさ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/mlmagazine_help.html
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/mlmagazine.html
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.