┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.18 2003/10/16
━お 詫 び━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
今回は、編集上の都合により、配信が一日遅れてしまいました。
大変申し訳ありません。本来は水曜日配信です。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ I N D E X
┃
┣【新着記事】「アジャイル開発コンファレンス参加レポート」UPしました
┣【プログラミング】ソフトウェア原則 [3] SRP(Single Responsibility Principle)
┗【ＰＭ】プロジェクトマネジメント入門
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 【新着記事】「アジャイル開発コンファレンス参加レポート」UPしました
〇 〇━━━━━━━━━━━━━ ━━・
先週に引き続き、アジャイルカンファレンスレポートの公開です。
カンファレンス全体を俯瞰した内容で、開始のアイス・ブレイカー・パーティ
から、各セッションの概略、その後の大物アジャイラーとの交流など、現地裏
話満載です。
http://www.ObjectClub.jp/adc/explain.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【プログラミング】ソフトウェア原則 [3] SRP(Single Responsibility Principle)
前回は、IOP(Inside-Out Principle)を説明し、ソフトウェアの設計を、
システム全体をレイアウトする「場」（アーキテクチャ）を作り、
そこに安定性の順序に従って抽象を切り出していく作業。
と再定義しました。アーキテクチャを安定性の順序、すなわちInside-Outで設
計する。まずモデルから、最後にユーザーインターフェイスを設計するという
のが設計活動の大きな指針です。
今回は、後半の「抽象を切り出していく作業」についての原則を紹介します。
ここで、抽象(Abstraction)というのは概念とマッピングできるモジュールのこ
とです。オブジェクト指向設計では、抽象をモジュール（ソフトウェア分割の
単位）と直接マッピングできるのが大きな利点なのです。
すなわち、「クラス」がこの抽象であり、かつモジュールの役割を果たします。
SRPは、どのようにシステムをクラス分割（発見、抽出）するか、に関する指針
です．
SRPでは、「１つのクラスは１つの責務を持つ」を原則とします。複数の責務を
１つのクラスに持たせないこと。１つの分かりやすい役割をクラス分割の境界
とすること。１つのクラス内に入る要素（属性や操作）が、１つの目的に向かっ
て凝集していること。これが原則です。
７０年代に、構造化設計の文脈において Peter Code, Edward Yourdon,
Larry Constantine, Tom DeMarco らがモジュール内の要素の結びつきを
cohesion(凝集度)という名前で具体的に定義しています。凝集度のレベルを５
段階とし、より強い結びつきを持ったものをモジュール内に入れるという原則
を示しています。ここでの「モジュール」という言葉を「クラス」と呼びかえ
ると、この原則は現在のオブジェクト指向の文脈でも十分に通用するのです。
さて、Robert C. Martinは、この原則をさらに現代的に言い換えています。
クラスに変更が起こる理由は、一つであるべき。
A class should have only one reason to change.
「変更」に焦点を当てた定義は、より具体的です。もし、変更の理由が２つあ
る場合、そのクラスは２つに分割すべきだし、もし１つの変更が２つのクラス
にまたがるなら、そのクラスは１つに統合すべきだと言っています。
この原則により、ある変更が起きたとき、その変更の連鎖を最小限に食い止め
ることができます。この定義によって「アーキテクチャの連続性」と同じく、
変更に対して強い設計、という具体的なクラスの責務分割の指針が示されます。
最後に、本当によいクラスが抽出できたかどうかを簡便に判断する方法があり
ます。それは、そのクラスに「よい名前が付けられるか」という基準です。
よい抽象には良い名前がつく。
A good abstraction has a good name.
これは、誰もがいろいろなところで言っていますが、私もこの基準が本質的で
あると考えています。良い名前であることは、SRPの本質です。
また、クラスの候補が見つかったら、良い名前を探してみることが重要です。
私は机上にシソーラス辞書（英語の類義語辞典）を置いており、よい名前を常
に探すことにしています(*1)。ぴったりくる名前を発見したとき、自分の発見
したクラスの輪郭がくっきりと浮かび上がってくるものです。そして、システ
ム全体がクラス群に分割されたとき、その名前群が１つの意味体系を作り上げ
て行くのが理想なのです。
* * *
先日、Tom DeMarcoの79年の著書(*2)に、名前に関する議論を見つけました。
意味あるモジュール名が思いつかないとき（「このモジュール何て呼ぶ」、
「太郎でどう」というような場合）は、まず、容認できない凝集度である。
たどりついた名前が中身のない名前だったり、多義の他動詞と目的語の組み
合わせだったら、これも容認できない凝集度である。１つの他動詞と１つの
目的語を持つ力強い名前にたどりつけば、そのモジュールは強く凝集してい
ると言える。
「力強い名前」。わたしはこの言葉にはっとしました。
上記は構造化設計であるために、「１つの他動詞と１つの目的語」がよいモ
ジュール分割の結論になりますが、オブジェクト指向では、「１つの名詞」が
よいクラス名の、「１つの他動詞と１つの目的語」がよい操作名の典型例です。
今回は、クラス*内*の凝集度(cohesion)について話しをしました。次回は、ク
ラス*間*の結合度(coupling)について話をしたいと思います。
（平鍋）
*1, これは、Ward Cunningham がシソーラスパターンとして書いています。
http://c2.com/cgi/wiki?SystemOfNames
*2, 『構造化分析とシステム仕様』, 1979(邦訳 1986年,1994年新装版)
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E001+2+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E001+2+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E001+2+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【ＰＭ】プロジェクトマネジメント入門
前回に引き続き、「５W１H」の話をしたいと思います。
その前に、ちょっとおさらいですが、なぜこの「５W１H」の話をしているかと
いうと、私たちが日々行っている作業を円滑に行うための基本であり、プロ
ジェクトマネジメントの観点からも当然重要なマネジメント要素となってくる
からです。
前回は、「Ｗｈａｔ」と「Ｗｈｙ」を説明したので、今回は、「Ｗｈｅｒｅ」
からです。
「Ｗｈｅｒｅ」：一般的には「どこで」、つまり、作業を行う場所を明確化す
ることですが、これ以外に、「対象（ターゲット）」や「前提条件」、「制約
条件」も入ってきます。つまり、「どこで、何に対して」作業を行うかです。
「Ｗｈｅｎ」：作業を行うときには「いつから、いつまで」が必要となってき
ます。つまり、開始時期と終了時期です。
「Ｗｈｏ」：作業担当者のことです。ソフトウェア開発プロジェクトでは、こ
の担当者がプロジェクトの成否を決めてしまうところがあり、この作業者の選
択が一番苦労するところですね。実際、筆者も苦労しています。
「Ｈｏｗ」：どのような方法で進めていくかを明確化します。「方法論」「作
業計画」などがこれにあたります。ソフトウェア開発ではこの部分に諸般の課
題があると筆者は思っています。
ちょっと、宣伝になってしまうかもしれませんが、私達は「どのようにすれば
作る側、使う側がハッピーになるソフトウェア作りができるのか」を命題に、
「オブジェクト倶楽部」などを通じて活動をしています。この有効な解として
アジャイル開発のひとつであるXPを考え、啓蒙活動を行っています。
以上が、「５W１H」の説明です。この他、「Ｈｏｗ ｍｕｃｈ」があります。
お分かりの通り、「予算」や「費用」のことです。
2回にわたり、「５W１H＋１H」を説明しました。次回は、プロジェクトマネジ
メントに関する各種手法について、歴史を交えて説明して行きたいと思います。
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?F001+5+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?F001+5+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?F001+5+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。
情報処理試験日が近づいていますが、準備はちっとも進んでません。今年も受
験費が無駄になるのか・・・・(T_T)ちなみにいりさの上長にあたる事務局長殿
には、「まだ受けんの！そんなもん！！」と一蹴されました・・・。
余談そのいち：
今回のカンファレンスレポートで、最終日のパーティの中で、平鍋さんが「一
番嬉しかったこと」としていたLaurie Williamsとのダンスですが、ソルトレイ
クに行った3人が口を揃えて「すっごい美人！！！」とのこと。才色兼備とはま
さに、という感じだったらしいです。（平鍋さんは相当にやけていたとかいな
いとか(笑)）
（いりさ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒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