┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.46 2004/05/26
■ I N D E X
┃
┣【Topics】オブジェクト倶楽部納涼イベント開催！
┣【お知らせ】オブジェクト倶楽部関連サービス一時停止のお知らせ
┣【プログラミング】ソフトウェア原則 [5] パッケージ分割
┣【ＰＭ】プロジェクトマネジメント入門 [13]
┗【アンケート】気になるシステム業界 ホントのところ
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 オブジェクト倶楽部納涼イベント開催！
〇 〇━━━━━━━━━━━━━ ━━・
今年もイベントがやってきます。今回のテーマは「失敗から学ぶオブジェクト
指向」。暑い夏に、オブジェクト指向開発にまつわる「怖い話」はいかがです
か？今回は、みなさんの怖い話（＝失敗談、経験談）をライトニングトークス
にて大募集。お手伝いくださる方はご連絡ください。
もちろん、オブジェクト指向業界での著名人の講演から、前回好評ワークショッ
プも開催決定。登録開始は目前です。乞うご期待！
詳細はこちら：http://www.objectclub.jp/event/2004summer
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【お知らせ】オブジェクト倶楽部関連サービス一時停止のお知らせ
5月30日(日) 7:00〜12:00 A.M、オブジェクト倶楽部がホスティングを依頼し
ているビルの受変電法定試験に伴い、オブジェクト倶楽部関連サービスを停止
します。下記停止時間中は、オブジェクト倶楽部HPは閲覧不可、および、下記
アドレスと、その関連アドレス（-ctl、-adminなど）に宛てたメールはエラー
となります。ご了承ください。
extremeprogramming-jp@ObjectClub.jp
webservice-jp@ObjectClub.jp
refactoring-jp@ObjectClub.jp
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【プログラミング】ソフトウェア原則 [5] パッケージ分割
先日、ある人から次のような質問を受けた。
クラスが多くなったので、パッケージ分割をしたい。
パッケージ分割をする時の、指針を教えて欲しい。
話を聞いてみると、１つパッケージが大きくなってしまい管理が煩雑になって
しまったため、今更ながら一旦整理をする決心がついたという。いわばパッケ
ージ分割のリファクタリングを行おうというわけだ。
さて、ここで読者の皆さんに問題である。パッケージ分割の「観点」（指針）
をできるだけ多く出してみてほしい。あなたなら、どんな観点で分割するだろ
うか？可能なら数分時間を取って、自分の観点をできるだけたくさん書き出し
てから次に読み進めて欲しい。
＊ ＊ ＊
以下が、私が現時点で持っている観点である。１つ１つ説明しながら見ていく。
解説には、設計原則との関わりについて考察を加え、さらに、私が感じている
ことを書いてみた。
(1) 名前
クラス名を意味的に近いもの同士でパッケージングする。これは最も自然な考
え方だと思う。
クラスの名前に注目してもよい。クラス名を並べて、分類学的な思考を使うこ
とになる。これとこれは仲間、これは仲間はずれ、これはよく似てる、これは
違う、という思考である。この観点で分割されたパッケージは、クラスを探し
やすい、という利点がある。「このクラス、どのパッケージにあったかな？」
という場面で、クラスからそれが属するパッケージが連想しやすい。この観点
は非常に重要だ。ただし、私の経験では、この観点のみではソフトウェアはよ
い構造を生まない。
(2) 粒度
パッケージの中にいくつのクラスがあるか？という観点である。具体的には、
１パッ ケージの大きさを、クラス数で５〜５０にする（この数は恣意的であ
る）。
例えば、意味的にほとんど同じようなクラス群を分割するのであれば、機械的
にpackage1〜package9というように区切ることも可能だ。この観点は、一見、
根拠が弱いような印象を与えるかもしれない。しかし、現代的なオブジェクト
指向においては、「粒度」という観点はますます重要になっている。計測した
り、管理したり、認識したりする単位の粒の大きさがそろっていることの効果
を、軽視するべきではない。もともとのパッケージ分割の動機が、「大きすぎ
るパッケージ」にあるのであれば、純粋にこの観点のみで分割する、という手
もアリだ。
しかし、私はこの観点を二次的に考えている。つまり、他の観点でうまく分割
し、その後で、この「粒度」をチェックする。もし粒度が大きいならば再度分
割を試みるし、小さすぎるならば、パッケージを統合してもよい。例えば、論
理的にパッケージ分割をした結果、クラスが１つだけのパッケージができたと
しよう。私はそのパッケージを、他のパッケージに統合してしまうだろう（そ
のパッケージが今後、大きくなるような予想が立つのであれば別である）。
(3) 依存関係
分割後のパッケージ依存関係に注目する。双方向依存や循環依存が発生したら、
そのパッケージ分割はよくない。分割後のパッケージ依存関係は、一方向に整
列すべきである。もし、他の観点と、この観点が競合した場合、強制的に依存
関係を逆転させることができる。JavaやC#, C++では、オブザーバー(Observer)
やリスナー (Listener)と呼ばれるデザインパターン、さらにC#では、delegate、
C言語では、関数ポインターという機構を使うことによって、パッケージの依存
関係を逆転させることが可能である。
この観点をサポートするオブジェクト指向設計原則に、
ADP(Acyclic Dependencies Principle)(*1)、
DIP(Dependency Inversion Principle)(*2)、
ISP(Interface Segregation Principle)(*3)がある。
私は、パッケージ分割後に、この観点を必ずチェックするようにしている。そ
れは、(5)で述べる再利用性に強く影響するからだ。
(4) 変更可能性
クラスの変更可能性（あるいは逆の指標であるクラスの安定性）に着目し、高
いものと低いものを分割するようにパッケージを分ける。
この視点は、ソフトウェアの「アーキテクチャ連続性」を高めるという点で重
要である。パッケージの変更周波数（変更頻度）は、その中の最も変更周波数
の高いクラスと同じである。変更周波数が違うものが同じパッケージに混ざる
のはよくない。できれば、全体の変更周波数の成分を特定して、その成分ごと
にパッケージ化していく。そして、依存性の方向を、変更周波数の高い方から
低い方に向かうようにそろえる。これによって、ソフトウェアの変更伝播をで
きるだけ避けることができる。例えば、よくMVCというアーキテクチャを採用
することがあるが、これは、変更周波数の低いもの(M=Model)と、変更周波数
の高いもの(V=View)を分割し、それらを中程度のもの(C=Controller)で接続す
る、というパターンだ、と言う事もできる。
この観点をサポートする設計原則に、SDP(Stable Dependencies Principle)(*4)、
SAP(Stable Abstractions Principle)(*5)がある。
実は、私は、この観点を最も重視している。
(5) 再利用性
変更可能性とよく似た観点として、再利用性をあげよう。もし、他のプロジェ
クトや他のサブシステムでも再利用できそうな部品が混じっている場合、それ
を個別にパッケージとして取り出す。パッケージとして取り出すことで、再利
用性が促進される（パッケージとして分離しないと、再利用されない）。この
観点をサポートする設計原則に、CRP(Common Reuse Principle)(*6)、
REP(Release-Reuse Equivalency Principle)(*7)、がある。
私は、最近、ナイーブな意味での「再利用性」を信じていない。特にプロジェ
クトをまたぐ再利用は、企業の組織的なサポートがない限り難しい。「プロダ
クトライン」などの、製品ファミリー全体に渡っての計画的な再利用手法が必
須なのだ。
それよりも、(4)の変更可能性に注目する方が、よりシンプルで効果がある。
XPなども、再利用性よりも変更可能性に積極的に注目する。「再利用」という
将来のできるかどうかわからないものに先行投資するよりも、現プロジェクト
の「変化を抱擁」する方に力点を置く。
(6) 凝集度・結合度
Myers, Constantine や Code, Yordon, らが80年代後半から90年代前半に、構
造化設計の文脈で提示した、ソフトウェアのモジュール分割の指針である。
詳しくは他にゆずるが、結合度を弱く、凝集度を高く、という指針は、クラス
分割の指針でもあり、パッケージ分割の指針でもある。
凝集度と結合度は、そのレベルも詳しく定義されているのだが、オブジェクト
指向の文脈でのパッケージ分割の指針としては、少し具体性に欠けると私は感
じている。そこで、この方針による、２つのガイドラインを提示してみた。
(6-1) クラス間の関係に注目
クラス図を描いてみる。そして、そのクラス図には、関連、継承、依存などの
クラス間関係をすべて書き込む。こうすると、どのクラス同士が強い関係を持
っているか、が見えてくる。その強い関係のクラス群を囲う線を描く。当然、
その境界線をまたぐ関係線があるが、その線ができるだけ少なくなるようにす
る。この境界線がパッケージの候補である。ここで、パッケージ内の関係線は
凝集度に、パッケージ間の関係線は結合度に対応する。クラスをパッケージ間
で移動して調整しながら、凝集度を高く、結合度を低くしていく。
(6-2) 変更のソースに注目
凝集度のより現代的な定義として「同一の変更理由」という解釈がある。パッ
ケージ分割においては、「変更のソースを特定し、同種の変更を閉 じ込める」
ように、パッケージを区切るという考え方である。例えば、「データベースス
キーマ」という変更のソースに関して、１パッケージで変更が食い止められる
ように、「セキュリティポリシ」という変更ソースに関して、１パッケージで
変更が食い止められるようにパッケージを分割するのがよい。これは、
CCP(Common Closure Principle)(*8)と呼ばれている原則だ。
これは、クラスに対する「１つの責務原則」SRP(Single Responsibility
Principle)(*9)のパッケージ版とも捕らえられる。さらに、実は(4)の「変更
可能性」で上げた「変更周波数の特定」と、この「変更ソースの特定」は同じ
ものであり、私がもっとも重要視している観点である。
＊ ＊ ＊
さて、以上が私の持ち札すべてなのだが、どうだろうか。みなさんの中には、
もっと違う観点をお持ちの方も多くおられると思う。他の観点をお持ちの方は、
ぜひ、このメールに返信願いたい。次回に議論していきたいと思っている。
ちなみに、このコラムでは、多くの設計原則を名前のみ紹介した。これらは、
Robert C. Martin の"Agile Software Development"(*10)から引用している。
以下に、簡単な日本語訳とともに紹介しておく。また、これらの原則の幾つか
は既に紹介済みである。残りは、これからの記事で順に紹介していこうと考え
ている。（平鍋）
(*1) ADP(Acyclic Dependencies Principle)
パッケージは循環依存してはならない。
(*2) DIP(Dependency Inversion Principle)
抽象は詳細に依存してはならない。
(*3) ISP(Interface Segregation Principle)
インターフェイスは最小であるべき。
http://www.ObjectClub.jp/ml-arch/magazine/27.html
(*4) SDP(Stable Dependencies Principle)
パッケージの依存方向は安定性の方向と一致すべき。
http://www.ObjectClub.jp/ml-arch/magazine/17.html
(*5) SAP(Stable Abstractions Principle)
安定したパッケージは抽象的であるべき。
(*6) CRP(Common Reuse Principle)
１パッケージ内のクラス群は同時に再利用される。
(*7) REP(Release-Reuse Equivalency Principle)
再利用の粒度はリリースの粒度と一致する。
(*8) CCP(Common Closure Principle)
１パッケージ内のクラス群は同種の変更に対して閉じている。
(*9) SRP(Single Responsibility Principle)
１つのクラスに１つの責務（責務＝変更理由）。
http://www.ObjectClub.jp/ml-arch/magazine/19.html
(*10) Robert C. Martin, "Agile Software Development", Prentice Hall, 2003
http://www.amazon.co.jp/exec/obidos/ASIN/0135974445/xpjp-22/
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/cgi-bin/question.cgi?E001+6+0
普通：
http://www.ObjectClub.jp/cgi-bin/question.cgi?E001+6+1
イマイチ：
http://www.ObjectClub.jp/cgi-bin/question.cgi?E001+6+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【ＰＭ】プロジェクトマネジメント入門 [13]
「プロジェクトマネジメント入門」です。今回のお話しは、お約束の通り「リ
スクマネジメント」です。
殆どのプロジェクトマネージャと言われる方は、プロジェクトを円滑に進める
ために将来起こるであろう事象を予想し、それがプロジェクトに対してプラス
かマイナスかを判断し、マイナスの事象（リスク）に対して何かしらの手を打
ってきたいと思います。この将来起こりうるマイナスの事象が予想でき、適切
に対応が取れればプロジェクトが上手く行くからです。
以前、私達のソフトウェア開発の現場では、ベテラン技術者がプロジェクトマ
ネージャ（リーダ）として活躍してきました。その背景には、このベテラン技
術者が多くのプロジェクトを経験してきているため、将来プロジェクトで起こ
りうる技術的なこと以外、さまざまな事象を経験から予想し、その事象に対し
て、上手く対応できる「やりかた」を知っていたからではないでしょうか。
このようにプロジェクトに対して上手く事象を予想できるベテラン技術者がに
らみを聞かせていればいいのですが、必ずしも今日のプロジェクト状況はそう
とも言えません。それは、様々な理由でベテラン技術者の絶対数が少なくなっ
てきたことと、また、プロジェクトの内外環境の変化により、プロジェクトで
将来起こりえる事象が変わってきた（予想もつかない事象が起こってきた）の
ではないかと思います。
また、プロジェクトに対するマイナスの事象に対応する「やりかた」は、属人
化し、共有化出来ていないような気がします。また、それぞれが異なった「や
りかた」をしているので、それが最適かどうかはわかりません。
このような状況から、プロジェクトを円滑に運用するために、プロジェクト計
画・実施時にプロジェクトに対するマイナス事象を的確に予想し、そのマイナ
ス事象が起こらないように、また、起こった時でも最小限の影響で収まるよう
にする方法が必要かと思います。
次回は、これらを行うための方法についてお話しします。（事務局長）
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/cgi-bin/question.cgi?F001+12+0
普通：
http://www.ObjectClub.jp/cgi-bin/question.cgi?F001+12+1
イマイチ：
http://www.ObjectClub.jp/cgi-bin/question.cgi?F001+12+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━4 t h ■━
■
┗気になるシステム業界 ホントのところ
今週は「一人でじっくり仕事をするのが好きですか？みんなでワイワイ仕事す
るのが好きですか？」のホントのところ。
一人でじっくり仕事をするのが好きです。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+11+0
どちらかと言えば一人で仕事している時が好きです。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+11+1
一人で仕事するのも、誰かと仕事するのも好きです。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+11+2
どちらかと言えば誰かと一緒に仕事をするのが好きです。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+11+3
常にみんなでワイワイ仕事していないとダメです。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+11+4
仕事？どう仕事しても仕事は非常に嫌いです。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+11+5
それは秘密です。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+11+6
ちょっと語らせて！
editors@ObjectClub.jp まで詳細を！！
アンケート結果はオブジェクト倶楽部HP上にて公開します。お楽しみに。
なお、前号「週刊オブジェクト倶楽部にどんな記事を期待していますか？」の
結果は公開中。是非ご覧下さい。
⇒http://www.ObjectClub.jp/special/kininaru
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。オブジェクト倶楽部がついにリニューアルされて嬉
しい編集人です。意味もなくサイトを訪ねてはニッコリ(^_^)しております。
アジャイルな動物らしいから（XPな動物がいたら良かったんですが…）虎を描
いちゃおー、と思って描いた虎の仲良しペアプロ風景
<http://www.objectclub.jp/technicaldoc/xp/>がお気に入りです。これが
まことの自画自賛です。はい…
前回メルマガについて、記事内容に関するアンケートを取りましたが、一般に
サイトとメルマガでは求められるものが違うらしいですね。メルマガはサイト
に比べると、読みやすく軽い内容のものが好まれるらしいです。しかし、今回
の結果を見る限りでは、週刊オブジェクト倶楽部の皆さんが、かなり真剣にオ
ブジェクト指向適用の道を探っておられる感じがしますね。今度のオブジェク
ト倶楽部のイベントでは、サイトでもメルマガでも得られないようなオブジェ
クト指向体験ができると思います。とってもリーズナブルですし、密度も濃い
ですよ。是非、奮ってご参加くださいね。
今週の強引な一言
*** 巧遅は拙速に如かず（格言）***
漏れのないドキュメントを作成しようとして時間ばかり無駄に過ごすよりは、
機能が少しぐらい足りなくても実際に動くソフトウェアのほうがよっぽど価値
がある場合が多いです。先に進むのが不安で、ドキュメント作成に逃げ込んで
いませんか。（さわ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml_help/
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003-2004 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.