2007年08月24日

概念クラス図: 概念とその関連を探る

 今回は、いよいよクラス図のお話です。
基礎 第6回: オブジェクトの関連―汎化の記事でもお話ししましたが、クラスとは概念です。
人が何かするとき、そこには概念があります。
いろんな概念があって、それらが相互に作用しあって、その人の考えや行動を構成しているのです。

 だから、人の行動や考え方を理解するには、そこに登場するいろいろな概念と、それらの関連を理解しなければなりません。
ソフトウェアというのは、人の行動や思考を肩代わりするものですので、ソフトウェアの中には、それら概念や関連が再現されていなければならないわけです。

 クラス図には、目的に応じていくつかの書き方があります。
今回は、概念(=クラス)とその関連を探し出し、書き留めることを目的とする、概念クラス図についてお話ししたいと思います。

コンテンツ

  1. 分析ですよ
  2. クラスを探す
  3. 関連を考える
  4. いよいよクラス図
  5. ヒューリスティック

分析ですよ

 「概念(=クラス)とその関連を探し出し、書き留める」と言いましたね。
ここでお話しする内容は、設計や実装のことではありません。
ユースケースと同じく、分析のことです。

 これに対して、設計クラス図とか詳細クラス図とか言われるものもあります。
これらは、設計のことに焦点をあてています。
同じクラス図でも、分析で使う場合と設計で使う場合があるわけです。
書き方だけで見ると、これらに対した違いはありません。
でも、その目的、表現するものはまるで違います。
クラス図を書く場合には、自分が今何をやっているのかを見失わないように気をつけてください。

 さて、ここでもう一度、さきほどの文章を見てみて下さい。
概念(=クラス)とその関連を探し出し、書き留めることを目的とする」
ですね。
クラスとその関連って、誰が探し出すんでしょうか?
もちろん、あなたです。
大切なのは、あなたがこれらを探し出すことです。
探し出せなければ、クラス図で書くものがありません。

 ここでは、クラスや関連を発見する過程と、それを表現するための書き方をお話しします。
でも、書き方は、あくまで表現の仕方に過ぎません。
あなたがクラスを発見できるようになることの方が100万倍大事です。
大切なのは、表現の仕方よりも、何を表現するのかだということを、忘れないで下さい。

クラスを探す

 さて、ユースケースのお話で使用した、料理教室の例を今回も使用します。
クラスの候補を探す一番のヒントは、ユースケースにあります。
ユースケース記述で、普通の文章でイベントフローを書きました。
この文章には、さまざまなモノの名前が出てきますね。
この名前は、ユースケースが実行される際に出てくるオブジェクトを表しています。
だから、この名前一つ一つが、クラス候補です。

  では、ユースケース記述のイベントフロー1. を参考に、クラス候補を探してみましょう。
イベントフロー1:

先生は(和気あいあいと、あるいはさりげなく)出席をとる。
ここで出てくるオブジェクトは…
  • 先生
  • 出席
こんなところでしょうか。

関連を考える

 イベントフローの記述を参考に、クラス同士の関連を考えていきましょう。
すぐにわかるのは、先生と出席との間には、何らかの関連があるということですね。
でも、それだけでしょうか?
この「出席をとる」という場面について、頭に思い描いてみましょう。
先生は「出席簿」を持っていて、それにしたがって順番に生徒さんに「出席してますか?」と問いかけていきます。
生徒さんが「出席してます」と答えると、先生はそれを出席簿に書き込んでいきます。
 「出席簿」という新たなオブジェクトが出現したことに、気がつきましたか?
出席簿とは、出席したかしなかったかをチェックできるようにした、生徒のリストですね。

 このように、分析や設計を1歩進めると、今まで気がつかなかったことが見えてきたりします。
そんなとき、「今まで発見できなかったのは失敗だ」なんて思わないでください。
あなたは神様じゃないんですから、発見できないことがあるのは、当然なんです。
逆に、「どれだけがんばってみても、完璧な分析や設計などできはしない」のだということを、常に意識しておいてください。
今の段階での分析や設計がある程度の完成度に達したら、さっさと次の段階に進んだほうがいいのです。
違う視点から見ることで、新たな発見ができるかもしれませんから。

 そして、新たな発見をしたら、前の段階で作ったドキュメントを、どんどん直しちゃってください。
「ドキュメントは、いったん完成したら、間違いを修正する場合以外には手を入れることはない」なんて、思わないでください。
ドキュメントは生き物です。
開発が終了し、さらに運用も終了し、ソフトウェアの寿命が尽き果て、息の根が止まるまで、ドキュメントは変化を続けなければなりません。

 なかでも、開発期間中はドキュメントが最も活発に変化する期間です。
いったん完成したら終わりなんて、絶対にあり得ません。
(一部、ウォーターフォール型開発が必須の、変化がなく、慎重さが重要なソフトウェア開発は別です)

 さて、ユースケース記述には、「全てのオブジェクトの名前が登場しなければならない」なんて決まりがあるわけではありません。
ユースケース記述で、全てのオブジェクトの名前が登場していた方が、ユースケースとクラス図の関係がきちんと表現できるでしょう。
でも、重要なことは、ユースケース記述を含め、全てのドキュメントをできる限りシンプルに保つことです。
全てのオブジェクトに言及することにこだわるあまり、記述の粒度がまちまちになったり、細かすぎて全体像がつかみにくくなってしまっては、本末転倒です。
オブジェクトの名前を網羅しているかどうかは、重要ではありません。

 今回の場合、ユースケース記述に「出席簿」についての言及がなかったことが発見されたわけですね。

出席簿というオブジェクトをユースケース記述に追加しても、記述の粒度を狂わすことにはならないでしょうし、細か過ぎもしないでしょう。
だから、追加してもしなくてもかまいません。

 さて、話を戻しましょう。
さきほど頭に思い描いたストーリーから、関連を考えてみます。
"先生は「出席簿」を持っていて"ということこから、先生は出席簿に依存していることがわかります。
"(先生は)生徒さんに「出席してますか?」と問いかけて"というところから、先生は生徒さんに依存していることがわかります。

 先生と出席簿、先生と生徒の依存関係で、どちらがどちらに依存してるのか?ということについて、迷うかもしれませんね。
基礎 第8回: オブジェクトの関連―依存を振り返ってみていただければ、どう判断したらいいのか、おわかりになるんじゃないでしょうか。

 もうひとつ、出席簿って何でしたっけ?
出席したかしなかったかをチェックできるようにした、生徒のリストですね。
つまり、出席簿は生徒を包含してるわけです。

いよいよクラス図

 この先生、出席簿、生徒の関連を、図にしてみましょう。
クラスは四角い箱の中に名前を書き、関連は箱と箱をつなぐ線で表現します。

 関連には、方向がある場合があります。
先生と出席簿の関連では、先生が出席簿に依存しているのであって、その逆はありませんね。

こういう場合、関連の線に矢印を付けます。

 包含の関連には、含む方に白ヌキの菱形を書き、含まれる方には多重度を書きます。
多重度とは、いくつからいくつまで含まれる可能性があるか?ということです。
たとえば、0個か1個なら0…1。
少なくとも1個は含まれて、上限はないということなら、1…*というかんじです。
ConceptClassDiagram.png
 図は、左のようになります。
簡単ですね。

 ここで、ソフトウェア的に考えると、出席簿は生徒を包含しているのだから、生徒への出席欠席の問い合わせは、先生でなく、出席簿オブジェクトが行うべきだと言えますね。

 そうなれば、先生は生徒に依存する必要がなくなります。
さて、そういう判断は分析の段階で行うべきか、設計の段階で行うべきか?という問題があります。
今行っているのは分析ですので、今やるべきか、後にすべきかということです。

 もう一歩踏み込むと、今その判断を行って、この図から先生と生徒の間の依存関係を削除する場合、それだけでは済みません。
なぜその依存関係が図にあらわれないのかを表現しなければならないからです。
でないと、これを見る人には、どうやって出席がとられるのか、理解できないですよね。

 この場合、「出席簿が生徒に問い合わせをする」というのが理由ですね。
つまり、出席簿に「出席をとる」という操作が記述されなければならないということになります。
今回、クラス図での操作と属性の書き方については、あえて触れません。
概念クラス図の、概念モデルらしさを強調したいからです。
概念クラス図にはそれらを書いてはならないというわけではありませんので、ご注意ください。
操作や属性の書き方については、詳細クラス図の解説のところで触れる予定です。

 今回の図にはあらわれませんでしたが、複数のクラスの共通点から、汎化の関連を見いだすこともあるでしょう。
汎化の関連では、関連線のスーパークラスの方に、白ヌキの三角を付けます。
こんなかんじです。
ClassDiagramGeneralize.png

 こんなふうにして、ユースケース記述の全てのイベントフローを参考にして、クラスを探し出し、関連を定義していって下さい。
ただし、ユースケース記述はあくまで参考です。
そこに書いてある文章だけを見るのでなく、今回やったように、場面を思い描いて下さい。
ユースケース記述の文章には登場しなかったオブジェクトや関連を発見できるでしょう。

ヒューリスティック

 Code Complete第2版の上巻で、ソフトウェアの設計はヒューリスティック(発見的)なプロセスであることが指摘されていますが、これは分析も同じだと思います。
分析の過程でも設計の過程でも、いろんなものをヒントに、試行錯誤を繰り返すことになります。
だからこそ、分析や設計の成果物であるドキュメントも、安定することなく、変化しつづけるのです。
 ヒューリスティックなプロセスでは、
  • できるだけ多くのヒントを見つけ出すこと
  • それらを有機的に結びつけていくこと
  • 発見を以前の成果に継続的にフィードバックしていくこと
が必要です。
「発見」を大事にして下さい。
タグ:UML 分析
posted by craftsman at 00:06 | 東京 ☁ | Comment(2) | TrackBack(0) | UML
この記事へのコメント
分かり易い解説で、勉強になりました。

こういったユースケースありきから分析してクラスを抽出するという作業にあまり馴染みがないためでしょうか。とても新鮮でした。

次回も更新楽しみにしています。

ではでは。(^_^)/
Posted by サンドラ at 2007年08月25日 01:56
 ありがとうございます。

 わかりやすさのためと、「書き方よりも発見が大事」というポイントをはっきりさせるため、細かい説明をだいぶはしょりました。

 「これでよかったのかな?」という不安も多少あったのですが、そう言っていただけるとほっとします。

次回もがんばります。
Posted by craftsman at 2007年08月25日 06:12
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/51651339
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。