.NETは危険な香り
「今度の開発は.NETでやることになりそうだ」
「しかも、C#.NETらしいぞ」
こんな会話がちらほらと、ようやく私の周りでも聞けるようになりました。
おぉ、ようやくオブジェクト指向を採用する気になったか！と、私には
嬉しい限りなのですが、本当に導入してしまって大丈夫なのでしょうか。
オブジェクト指向での開発はそれまでの開発プロセスとは明らかに異なる
わけですし、分析、設計、開発、テスト方法の全てが異なるのですから、導入には
慎重に検討をし、参加メンバー全員に教育もある程度行わなくてはなりません。
それなのに、検討もせず、教育のスケジュールも全く取られていないのに、
なぜ.NETを使用することだけが先に決まっていたりするのでしょう。
アーキテクチャ（言語を含む）が先にある程度決定されていることは
ままあることとはいえ、全く検討もせずにオブジェクト指向経験ゼロの
メンバーだけでその決定を下すのは危険です。
しかし、そのプロジェクトは.NETで開発する、ということだけを先決し、
走り出してしまいました。
管理者「どう？あれの調子は。」
プログラマー「いやぁ・・・難しいですね」
管理者「難しいの？UMLが難しいの？」
プログラマー「UMLもですけど・・・。色々と。」
管理者「UMLってそんなに難しいの？難しいかもしれないけど、頑張っていこうよ！」
プログラマー「はぁ・・・。」
どうやら管理者はUMLを知らないようです。先にプログラマーにUMLを勉強させて、
ドキュメントを作らせ、それをプログラマーに説明させることで自分は
UMLを習得していくつもりなのでしょう。
そんな方法でUMLは習得できません。管理者はUMLがどういうものなのかを
全く理解していないようです。理解していないのに、なぜUMLでドキュメントを
作らせるのでしょうか。
おや、オブジェクト指向設計は誰がやっているのでしょう？
誰もやっていないようでした。
プログラマーに話を聞いてみると、ユースケースを作っているとのこと。
UMLも勉強しはじめたばかりで、なんのためにユースケースを作っているのかは
わかっていないようでした。
正しく記述できているか誰も判断ができないので、
怪しいユースケースだけができあがるのは目に見えていますね。
そんなユースケースで一体何をしようというのでしょうか。
それにしてもOOA、OODをしないで（できる人がいないから）どうやって
クラス図を作るつもりなのでしょう。
話を聞いてみると、既に見積もりまで出ています。C#.NETという新しい
言語を使うので、見積もりは今までの1.3倍だとか。
・・・。
この人たちはオブジェクト指向で開発するつもりはこれっぽっちも
無いようです。今までのやり方で（ユースケースは作りますが）
ただ、新しい言語で開発するだけのようです。
せっかくクラスベースで開発できる言語を使うのに、ただ新しい言語を
使うだけの意識しかないとは！一体どういうことなんでしょう。
ここでイヤな記憶が甦りませんか？同じような事が過去ありましたよね。
それはCOBOLからVBへの移行です。
COBOL技術者がVBへの移行をした時、SQLもろくに勉強せず、
COBOL時代の設計方法をそのまま使用し、VBの方が開発スピードは
断然速いからなんとかなるはず、というおかしな見積もりのために
結果デスマーチになってしまったプロジェクトに巻き込まれた人も
少なくないと思います。
そうなんです、今回のこの管理者とプログラマーの会社はまさに
COBOLからVBへの移行を行った会社でした。
そして今度はVBからC#.NETへ同じやり方で移行しようとしているのです。
管理者が、今までVBをやってきているのだから、.NETなんてちょっと勉強
すればなんとかなるだろう、最初時間が少しかかるかもしれないが、
慣れたら.NETの方が開発は速いらしいし・・・という甘い認識で
.NETを採用するなんて言語道断です。いや、オブジェクト指向を一切取り入れないので
あればその甘い認識はある程度正しいでしょう。
しかし、どうなんでしょう？オブジェクト指向をまったく取り入れないで.NETを
使用して開発しても、プログラマーレベルではオブジェクト指向を全く知らないで
済むわけではありません。
それでも、必要な技術だけその都度調べ、オブジェクト指向についてはあまり
わからないままなんとかリリースまでたどり着くことは可能でしょう。
私はJavaで仕事をしたことはないのですが、「オブジェクト脳の作り方」
によると、Javaの開発ですら、ちゃんとオブジェクト指向設計をした上での
開発はほとんど見られないとか。
という不幸にも間違ってしまった認識を、今度は
「.NETで開発すればオブジェクト指向なのさ！」
と、同じことになりつつあるということなのですね。
少しずつ理解してきました。
相変わらず、この本を読んでいるのです。
とはいっても、すでに3回目です。
この本は読めば読むほど理解が深まって良いです。
本の例について自分なりにモデリングしてみたりすると、またそこで
疑問がでて、本を読んで納得する。なんて日々を送っていました。
でも、まだなんかすっきりしなかったんです。
どうしても名詞抽出法が気に入らないのです。
で、そこでこの本を買ってみました。
中身をぱらぱらと見てみると、こんなんで本当に役に立つのか？
というような内容だったのですが、読み進めてみると大ショック！
「よくある間違い」として載っていた例にことごとくはまってしまいました・・・。
そこでこの本の正解例を読み、何が自分の考えと違うのかをよく考えみました。
そしてなんとな〜くわかってきた時に再び「UMLモデリングの本質」を読んだときに
モヤが晴れるかのような思いをしたのです！そこには答えがずばり書いてありました。
モデリングとはある概念を図示したもの、とは思っていたのですが、それだけでは
不十分でした。
モデリングとは、エンティティとエンティティがどういう「関連」があるかを図示したもの
だったんですね。
アイスクリームの例が「思考系UMLモデリング即効エクササイズ〜」の最初に出てきます。
アイスクリームをモデリングしろ、と言われたとき、私はすぐにアイスクリームは
アイスとコーンでできている。これは集約の関係だなぁと考えます。
そして、集約の図を書きます。ですが、そこから先が進みません。これではモデリング
したとは言わないわけです。これでは構成図を書いただけにしかすぎません。
モデリングの場合、アイスとコーンの関連を考え、図示します。関連を考えなかったら
ただの構成図にしかすぎません。そして、その構成図はDBレイアウトを作るのと同じ
考え方だったといえます。
そう、DB設計をするのとモデリングするのとではここが一番違うところだとわかりました。
DB設計であっても、関連をエンティティとする場合は多分にありますが、それはその
関連が履歴を持つ場合です。保存する、という目的がないとエンティティとして抽出
されません。
でも、モデリングの場合は違うんですね。この場合、アイスはコーンの上に「乗っている」
という関連で結ばれるのです。そして関連で結ばれたことで、やっとアイスクリームは
モデリングされた、といえるのです。
そしてふと思ったのです。名詞抽出法では名詞をエンティティを抽出しますが、関連は
動詞とした記述されるのでエンティティとしては抽出されません。ですが、モデリングでは
関連が大事なのです。さらに言うなら、動詞＝関連こそがモデリングのポイントな気が
しています。
「注目すべきは名詞ではない！動詞だ！」
どこかの本に書いてあったのですが、ある人が名詞抽出法を説明していると、
このような反論がプログラマから出たそうです。
今の私はその人に賛同します。
だって、動詞＝関連が見出せれば、その動詞がつないでいるものこそがエンティティな
わけですから、そのエンティティを関連で結べばいいだけなのですから。
UMLモデリングの本質
ロバストネス分析はとてもわかりやすかったのですが、
ドメイン分析ができるようになったわけではないですよね。
名詞抽出法はイヤだけれど、どうにかならんかいな、と思って
この本を買ってみました。
最後まではまだ読んでいないのですが、これ、最高です。
最初のクラス抽出はやはり名詞抽出法しか解説されていない
のですが、とりあえず抽出した後の洗練方法が詳細に載っているんです。
ですが、この本を読んでいて思ったのですが、最初のクラス抽出って
本当に難しいようです。本の例として、ミシンの機能をモデリング
する例がありました。
縫う、という機能についてのみモデリングするのですが、このとき、
ミシンの動きを下から観察します。そして、ミシン全部ではなく、
針、上糸、下糸、ボビン、布について注目します。
「針の先端の穴に上糸が通っている状態で布を上から突き刺し、
たるんだでできた穴に下糸が巻いてあるボビンを通す。」
こうやってどのように縫うという仕組みが行われているのかを
観察し、理解することがモデリングの第一歩で、それを図にしたら
クラス図になる、というわけですが、果たして針、上糸、下糸、
ボビン、布だけに注目したのはなぜでしょう。
この５つだけに限定して注目したのがポイントで、これこそが
名詞抽出法に大きく関わっているわけです。
この５つこそが抽出されたクラスなわけですが、通常、いきなり抽出はできないので、
先に動きを文章にし、そこから名詞をクラス候補とするわけですね。
この本で解説しているのは、どうでもよさそうな名詞は最初から抽出する必要はなく、
動きの中心となりそうなオブジェクト、つまり他のオブジェクトと一番関連がありそうな
ものについて、ものすごく簡単にクラス図を作り、少しずつそれを洗練していけば
いい、ということです。
名詞抽出法はイヤだ、とかたくなに思っていたのですが、慣れるまではそれでも
いいのかな、と思いました。
最後まで本を読んでからまた考えてみます。
ドメイン分析をしてみる。
よくある例として、図書館を取り上げてみます。
次のようなユースケースがざっと考えられます。
- 図書を登録する（司書のみ）
- 図書の場所を調べる
- 図書の在庫を調べる
- 図書の貸し出しをする（司書のみ）
- 図書の返却をする（司書のみ）
- 図書の場所を登録する（司書のみ）
粒度は、「ユーザーマニュアルの章」になるようにしました。
（ICONIXプロセスに基づいています。）
さて、ここで私がいつもやっている感じでDBレイアウトを考えてみました。
書籍DB
- 書籍id
- 書籍名
- 著者
- 出版社
- ISBN
- 場所id
在庫DB
- 書籍id
- 在庫数
場所DB
- 場所id
- 棚名
- 分類
司書DB
- id
- pass
書籍DB：在庫DB＝1:1
書籍DB：場所DB＝1:1
という感じです。
さて、全てのユースケースについて分析してたらお試しにはならないので、
1.図書を登録する（司書のみ）
について分析してみます。
まずはユースケース記述を書きます。
基本処理
司書はログイン画面でidとpassを入力し、OKボタンをクリックする。
システムはidとpassが正しいことを確認する。
システムは場所を全て取得し、書籍登録画面を表示する。
司書は書籍名、著者、出版社、IDBN、在庫数、棚名、分類を入力する。
司書は場所リストから場所を選択する。登録したい場所が無い場合は、場所を登録してから選択する。
司書は在庫数を入力する。
司書は登録ボタンをクリックする。
システムは入力漏れが無いことを確認する。
システムは在庫数がゼロでないことを確認する。
システムは書籍を登録する。
代替処理
システムはidとpassが正しくなかった場合、メッセージボックスで警告する。
システムは入力漏れがあった場合、メッセージボックスで警告し、その項目をハイライトし、
在庫数がゼロの場合、メッセージボックスで警告し、在庫数テキストをハイライトする。
基本処理と代替処理しか書かないのは、ICONIXプロセスに基づいているからです。
これらについて、ロバストネス図を書くと、このようになりました。
あ、今みると
- システムは入力漏れが無いことを確認する。
- システムは在庫数がゼロでないことを確認する。
- 代替手順
を書き忘れた・・・。けど、まぁこんな感じでしょう。
うん、すんなりとここまでこれました。
図の作成にはフリーのツールjudeを使いました。作った図を簡単にjpg、pngで保存できるので使いやすいですね。
ドメインモデルはER図と同じ？
この本を読んでみました。
「ユースケース入門―ユーザマニュアルからプログラムを作る」
ちっとも入門書ではないことも、ICONIXという開発プロセスの説明で
あるという題名に偽り有りの本であることはわかっていました。
開発プロセスの具体的な適用方法を体感したかったので丁度いいと
思ったのです。
でも、どうにもわかりづらくてピンときませんでした。
もう一度頭から読んでみたら最初よりすんなり理解できました。
モデリング初心者にはわかりづらく、ある程度わかっている
人にはわかりやすい本なのでしょう。
ある程度理解できたところで、試しに実践してみよう〜と
やってみたのですが、やっぱり名詞抽出法でつっかかりました。
なんかしっくりこないのです。
こんな記述を見つけました。
「オブジェクト指向設計では、構造化手法よりも容易にモデリングが行えます。
例えば、受発注のシステムを考えた時に、データモデリングでは、いきなり「注文」
というエンティティを持ってきたりします。これは、モデリングの経験がある人なら
すぐに思いつきますが、そうでない人にとっては難しいことです。それに比べて
オブジェクト指向設計では、具体的なケースであるシナリオを考えてから、手順を
追って説明に必要な要素を洗い出していきます。こちらの方が、初心者には容易に
入っていけるはずです。」
引用元：オブジェクト指向の広場
どういう初心者を想定しているのかはわかりませんが、私には容易ではありません。
データベース設計に慣れているからでしょうか、「注文」エンティティはすぐに
思いつきます。でも、名詞抽出法だとどうにもやりにくいのです。
この本も読んでみました。
「ワークブック形式で学ぶUMLオブジェクトモデリング―「ユースケース駆動」でソフトウェアを開発する」
これはいいです。最初の本を読んでおくと、とてもわかりやすい。
知識がメキメキとついていくのが実感できます。
しかし、問題領域の名詞抽出法については何も触れられていませんでした。
そこが今一番知りたいとこなのに。
・・・ふと、この本のドメイン分析後のクラス図を見てて気がつきました。
あれ、これって正規化したDBレイアウトにそっくりなんじゃないの？
汎化はDBレイアウトにはないけど、集約って・・・。第2正規化じゃないのか？
よく、クラス図とER図は似ている、あるいは同じものだ、なんて書かれているのを
今まで読んだことをあるけども、ふ〜んそんなものかぐらいにしか思っていませんでした。
でもようやく実感できました。
それに、DBの項目がクラスなら、レコードがインスタンスじゃないですか。
だったら、問題領域に存在する情報を全てDBに格納するつもりで正規化していけば、
問題領域のクラス図ができあがるんじゃないでしょうか。
やってみます。
名詞抽出法はイヤだ
オブジェクト指向での最大の難関はクラス抽出です。
他人事じゃありません。苦しんでいます。
Javaを勉強した。.NETを勉強した。クラスを宣言したり、
オブジェクトを生成したりできるようになった。
本に書いてあることは一通り理解して、使えるようになった。
では、何かオブジェクト指向で作ってみよう・・・あれ？
何をクラスにしたらいいのかわからない・・。
名詞抽出法？なんだこのあいまいな方法は。
気に入らない。
というのが今の私の状況です。
ネットを彷徨って色々調べてすぐわかったのは、
オブジェクト指向でプログラミングするには、オブジェクト指向設計
をしなくてはならず、オブジェクト指向設計するためには、オブジェクト指向分析
しなくてはならない。
ということです。それから数冊本を買って勉強してみたのですが、
結局のところ、名詞抽出法を使わないといけないのか・・・と思っています。
ですが、この名詞抽出法は使いたくない。
ロバストネス分析というのがよさそうだと思って本を買って読んでみたのですが、
これはある程度クラスを抽出できた上で用いるようです。しかも、抽出したクラスは
問題領域のクラスであって、解決領域ではないので、そのまま設計にすんなり使える
わけではなく。
う〜む・・・。
