« 2004年7月 | トップページ | 2004年9月 »

2004年8月

2004/08/29

高凝集性と低結合性

 「良いプログラムを書く」には、プログラミング言語の歴史を辿れば、「高凝集性と低結合性」にたどり着くのではなかろうか?
 下記の2個の記事を読むと、オブジェクト指向という概念よりも、モジュール分割の基準は何なのか、という根本問題が大事である気がする。

 「オブジェクト指向はどうやって身につけるのか?」記事によれば、オブジェクト指向で設計するときに重要な概念は「可換」と「隠蔽」であり、下記の特徴がある、と述べている。

・インターフェイスはオブジェクトの「可換」を実現する手段であり、結合度が低くなる。
・委譲やカプセル化はオブジェクトの「隠蔽」を実現する手段であり、凝集度が高くなる。

 「初心者を卒業した技術者のためのオブジェクト指向再入門」記事によると、結合度と凝集性は、一昔前の構造化プログラミングではすごく意識されていたらしい。

 前者の記事は、オブジェクト指向が「高凝集性と低結合性」を実現する手段を自然に担っていることを示している。
 後者の記事では、オブジェクト指向の世界では「高凝集性と低結合性」という言葉が出てこないからと言って見落としてはいけないことを述べている。

 僕個人の経験では、結合性よりも凝集性の方が重要である気がする。オブジェクト指向設計で自然に現れる「責務」という概念は、クラスの機能が高凝集性を満たすこととほぼ等価だ。だが、凝集性を意識することは、分割する機能を意識することだから、難しいと思う。
 凝集性を突き詰めると、結局、まとまった機能を持つエンティティをどのように見出し、実現させるか、に行き着く。

 システムの情報をRDBに格納する限り、エンティティをオブジェクトでいくら実現しても、最終的にはエンティティはRDBに合うようにマッピングされなければならない。
 結局、ORマッピングの問題に行き着いてしまうのではないだろうか?

| | コメント (0) | トラックバック (0)

2004/08/26

OOAはエンティティレベルの仕様変更に弱くないか?

 ポリモルフィズムを使うとプログラムは綺麗に書けるけれど、保守しにくいのではないだろうか?

 仕様変更によるソースの修正範囲の大小は、仕様変更の中身がエンティティに及ぶのか、それともビジネスルールの修正だけなのか、によって決定されると思う。
 ビジネスルールの修正なら、修正範囲はそれほど大きくない。普通は、一つのクラス内で機能分割すればいい。
 
 しかし、エンティティそのものが修正されるなら、修正範囲は非常に広く、しかも修正範囲を調査するのに手間取る。
 普通は、修正対象のエンティティのgetXXX()/setXXX()がCallされているクラスを全て洗い出し、一つずつロジックを追いかけなければならない。そのロジック内部でポリモルフィズムが使われていたら、どのサブクラスで動いているのか、修正対象データはどのクラスへ委譲されているのか、更にソース解読に手間取る。
 ポリモルフィズムを使う利点は、新しいビジネスルールを追加しやすい所にあるが、エンティティそのものが変更されてしまうと、全てのサブクラスに影響が及んでしまい、ポリモルフィズムの利点が消えてしまう。
 
 他にも、HashMapやArrayListのようなCollectionクラスにエンティティのデータを詰め込んでいる時は要注意。状況によって、データがどの値で設定されているのか、理解しにくいから。
 Genericityが使えれば、詰め込むデータの型チェックが効くので、ソースは読みやすくなるが、それでも複雑さが解消されるわけではない。
 
 結局、プログラム群が一つのコンポーネントとして独立していない設計に問題があるのだが、そもそもビジネスルールはRDBに依存している事が多いため、エンティティに依存してしまう設計は避けられない。
 
 エンティティレベルの仕様変更は頻度は多くないが、サブシステムを新しく追加する時や従来のコード体系が変更される時に要件として出てくる。
 ビジネスルール層のOOAとRDB層のDOAは、設計思想として両立できるのだろうか?

| | コメント (0) | トラックバック (0)

2004/08/21

言語は思考を決定するのか?

 「言語は思考を決定するのか?」の記事に、「Sapir-Whorfの仮説(言語相対性仮説)」が載せられている。
 「Sapir-Whorfの仮説」について調べたら、

Language shapes the way we think, and determines what we can think about.
(言語は、我々が考える方法を形作る。さらに、我々が考える事ができる範囲も決定する)

ということらしい。
 プログラミング言語も一つマスターするだけでは、その言語に規定された方法や範囲でしか考える事ができないのだろう。ハッカーの記事にあったように、悟りを開くためにLispも勉強しなくちゃ。

| | コメント (0) | トラックバック (0)

2004/08/20

オブジェクト指向プログラミングの本質は
「開放閉鎖原則」にあり

 羽生田栄一さんの「オブジェクト論」は、オブジェクト指向の長所が非常によくまとめられている。
 その中の一節で目を引くのが、「開放閉鎖原則」。
 ソフトウェア工学的に妥当なモジュールのデザイン原理に対するオブジェクト指向からの回答が「開放閉鎖原則」である、と主張し、

・ほとんどのデザイン・パターンはこの原則から導出できる。
・この原理は、オブジェクト指向では個々のデータやアルゴリズムよりもインタフェースが重要であると意味する。

という特徴を示している。

 「開放閉鎖原則」(The Open-Closed Principle) が説明されている本は、「プログラマのためのJava設計ベストプラクティス」しか見当たらない。僕の理解では、「モジュールは拡張に対して開いて (Open) おり,修正に対して閉じて (Closed) いなければならない」と認識している。
 この原則は元々、メイヤーが言い出したらしい。
 この原理は、オブジェクト指向だろうが構造化であろうが、どんなプログラムにも通用するが、オブジェクト指向でより明確に意識され始めたのではなかろうか?

 この原理を生かすには、変更の多い箇所は抽象クラスとし、変化はサブクラスで対応することになる。
 鍵となるのは、オブジェクト指向特有のデザインパターンであるFactoryMethodとObserver。ダイコンは、このパターンを意識せずにポリモルフィズムを実現させているような気がしてならない。

| | コメント (0) | トラックバック (1)

2004/08/19

XPに惑わされるな

 清水さんが3年も前に書いた記事に、こんな一節がある。

オブジェクト指向の時にも、彼らは、構造化手法を否定することで自分たちの手法をアピールするという方法を使ったわけです.
そのことで、多くの日本のソフトウェア技術者がミスリードされました.(中略)
そうしたアジテーションに便乗した代償として、「設計する」というこのと本質を学ぶ機会を失った可能性があります.
結果として、いつまでも「複雑さを解消」しきれないまま要求をコードに変換するはめに陥ったわけです.

 オブジェクト指向という概念は、プログラミングのような下流工程やモデリングのような上流工程だけでなく、XPのような開発プロセス/プロジェクトマネジメントまで影響を及ぼしている。その結果、逆に、IT業界には世代間断層ができてしまい、若い我々は先人の経験を継承する機会を失ってしまったのではなかろうか?
 XPやアジャイル開発が流行しているけれども、CMMのようなきっちりとしたプロジェクト管理手法も知る必要があるのではないか?
 

| | コメント (0) | トラックバック (0)

2004/08/18

DOAを捨てた後OOAが混乱を招いている

DOA+コンソーシアムというDOAの研究・普及を目的とした協議会のHPで、佐野初夫さんが次の鋭い指摘を述べている。

オブジェクト指向が出てきてから、ソフト産業は混乱してると思います。

 オープンシステムを構築する時も、RDBのテーブルがきちんと作成されていないと、アプリケーション層に設計のまずさのしわ寄せが来る。
 オブジェクト指向という概念は、プログラミングの生産性を高めたし、概念の整理術としても使えるけれど、概念そのものを洗い出すには、結局DOAが必要ではなかろうか?

| | コメント (0) | トラックバック (0)

2004/08/14

モデリング道場は面白そう

 モデリングを修行する場、『モデリング道場』のMLが始まった。
 道場の師範達の似顔絵が本人に非常に似ているのに笑った(^_^)

| | コメント (0) | トラックバック (0)

2004/08/13

CMMの構成管理はバージョン管理システムと同じか?

 CMMの構成管理は何度説明を聞いても、本質を理解できていない気がする。

 達人プログラマーの本では、バージョン管理システムは、ソースコードのReDo/UnDoをいつでも行えるシステムだ、という説明がある。
 構成管理も同様に、プロジェクト運営に関わる意思決定や成果物のCommit/RollbackをVSS(or CVS)のようなバージョン管理の仕組みでコントロールしたい、という動機があるように思う。

 構成管理には2つのレベル分けがあり、「管理され制御されている」という状態と、 「構成管理下に置かれる」という状態がある。「管理され制御されている」状態は、成果物のバージョン管理とほぼ同じものと理解している。
 だが、「構成管理下に置かれる」状態とは何か?

 CMM導入経験者に構成管理について尋ねたら、単なる成果物のバージョン管理だけでなく、成果物の一貫性を維持するために、利害関係者の同意を経てCommit/Rollbackが決定される機能も含まれるらしい。
 その話が本当だとすると、仕様確定をCommitするたびに会議を開いて、利害関係者の承認を得るという煩雑な作業が加わる事になる。確かにそのやり方ならば、仕様がコロコロ変更されて開発者にしわ寄せが来る、という事態は防げるかもしれないが、仕様確定の作業に高度な根回し技術が必要とされる気がする。

 全てのプロセスが構成管理下に置かれる必要はないようだが、プロセスごとに構成管理のレベルを区別するのが難しいと思う。
 意思決定をもっとAgileにするには、何が必要なのだろうか?

| | コメント (0) | トラックバック (0)

2004/08/10

ホワイトボックステストをやるなら
クラス設計を見直せ

 ひがさんグループの発表メモに思わず手を叩いて納得すると共に、現場とかけ離れた内容に憂鬱な気分になってしまった。

・ホワイトボックステストいりません
・そもそもホワイトボックスの網羅基準を考えなければいけないようなクラスの設計自体がおかしいです
・2時間以内で作れないクラスは作るのをやめましょう

 保守時のテストケースを洗い出す時、結局、ホワイトボックステストになってしまう。ホワイトボックステストでやらないと必ずテストケース漏れが出てしまうから。
 しかし、ホワイトボックステストをする必要性があるのは、そもそも処理が長すぎるので、全てのロジックを網羅するように解読せねばならないから。境界値テストや同値分割を考える手間がかかる。
 結局、粒度の小さいクラス設計になっていない所に根本の問題点がある。

 ホワイトボックステストをやるならクラス設計を見直せ!

| | コメント (0) | トラックバック (0)

2004/08/08

WBS洗い出しは難しい

 最近のシステム開発では、プロジェクトが動き出した途端に、仕様がコロコロ変わる時が多い。
 変化に対応するには、どんな手法が必要か?
 プロジェクトマネジメントは、結局、WBSの洗い出しから始まるように思う。

 だが、WBS洗い出しは難しい。
 理由は、まず、作業分担まで詳細化する手間が大きすぎる。管理工数を開発工数とは別に確保せねばならないが、普通のプロジェクトでは、5~10%以下しか割り当てられないので、高度なスキルが要求される。
 更に、仕様変更やトラブルのために、せっかく作ったWBSにマッピングされたスケジュールを書き直す事が多い。しかも、スケジュール変更をチームメンバーに徹底させる手間がかかるから。

 XPやCMM/CMMIのような開発スタイルでも、同じ問題は発生するのではなかろうか?
 XPなら、開発するスコープを計画ゲームで制限する。更に、タスクカードを作る作業がWBS洗い出しに相当する。

 CMM/CMMIでも、要求管理というプロセスで、要求そのもののスコープをステークホルダーの意思決定の元に決定してしまう。決定した要求仕様を覆すには、ステークホルダーの意思決定を再度行わねばならない。
 WBS洗い出しは、ウォーターフォール型開発のように、開発計画書を作って、プロセスを定義して、タスクを決めて、という風に定められた手順で膨大なドキュメントを作りながら、決めていく。

#その意味では、XPもCMMもスコープ管理、WBS洗い出しの手法は似ている。
#しかし、それらの手法が編み出された動機が全く違うのだから、相違点に着目すべきだと思う。

 XPもCMMも、変化に俊敏に対応することを目的にしているように思うが、その目的が本当に達せられたのか、疑問に思う所はある。
 変化に対応するのが難しいのは、変化に対応できる環境作りだけでない。変化を受け入れた時の影響が具体的にどれだけ大きいのか、更に、変化に対応できるだけの手間がどれだけなのか、が分かりにくい事にあると思う。
 例えば、システム保守で、仕様変更のたびに全ソースと全RDBを見直している時、調査工数そのものの大きさと、仕様変更を実施するための見積工数の正確さが結局、プロジェクトの成功/失敗を左右する。

 つまり、WBS洗い出しの調査工数と、WBSの正確さがプロジェクトの成功/失敗を左右しているように思う。
 但し、WBS洗い出しのような管理工数は、プロジェクトの規模によって異なるらしい。(「ソフトウェア開発の定量化手法」参考)
 そこにヒントがある気がする。

| | コメント (0) | トラックバック (0)

2004/08/04

全てのビジネスは金融商品

 最近のビジネスは、全て金融商品に結びつけることが流行しているのではないだろうか?
 そんな事を感じたきっかけが二つある。

 大前研一の本「サラリーマン・サバイバル」に、現代の車・住宅販売の営業マンは、単に車や住宅を売るだけでなく、それらを金融商品として売る能力がなければならない、と書いてあった。例えば、車を売るなら、中古車として売る時に高く売れるように、保険をつけるように勧める、とか。
 つまり、営業マンは、車や住宅に詳しいだけでなく、その価値を高める術を知っている金融コンサルタントでなければならなかったのだ、と。

 ある勉強会で電車の自動改札システムと航空券予約システムをクラス図でモデリングしたのだが、業務フローが似ているのにクラス図があまりにも違うのに違和感があった。
 経験者の人へ「電車の自動改札システムと航空券予約システムはどこまで似ていて、何が違うのか」と質問したら「交通サービスという業種ゆえシステムの構造は似ている。これらのシステムは、座席を在庫と見なしている」と答えられたのが印象に残った。
 「UMLモデリングの本質」では、在庫が出ると、アナパタの勘定パターンを使え、という定石がある。アナパタには、会計と物流システムは似ている、と書かれてあったが、その意味は、お金の流れとモノの流れは基本的に同じ仕組みであるということだった。

 最近の新聞では、トヨタの記事が多い。クレジットカードに車のキーの機能を持たせるとか、有り余るお金で金融に乗り込んだりしてる。トヨタといえば、カンバンで名高い優れた在庫管理ノウハウを持っている。
 結局は、製造業の生産管理を極めた者は、金融ビジネスにも自然に入り込める。
 そんな気がする。

【補足1】
 JR西日本ならICOCA、JR東日本ならSUICAが販売されている。それらは、プリベート・カードみたいなもので、チャージした金額から乗車代が落とされる。JR会社は、乗車券をクレジットカードのように扱いたい動機があるのではないか?
【補足2】
 他の例として、携帯電話に決済機能を持つICチップを載せたFelicaというサービスが始まっている。このサービスもプリベート・カードみたいなもの。クレジットカードのように与信機能まで持たせてはいない。チャージした金額から落とすので、前払いではないから。

|

« 2004年7月 | トップページ | 2004年9月 »