クラス図とは何か
まずはおさらいも兼ねて、システム分析においてクラス図とは何でどういう役 割をするものなのかをお話しします。何度か同じ事の繰り返しになるかもしれ ませんがご容赦下さい。
クラス図はプログラム設計ではない
システム分析においては、システムが対象とする世界が「どうであるか」をモ デル化します。それは当然「プログラムをどう設計すればいいか」とか「プロ グラムはどう動けばいいか」というモデルとは違います。クラス図はプログラ ムを作るためのものではないのです。対象とする世界を理解するためのものな のです。
JavaやC++のようなオブジェクト指向言語からこの道に入った人は、システム 分析でも言語と同じような言葉が使われているため、これを同じものだと思っ てしまいます。これが一番の間違いです。システム分析はプログラム言語とは 別物なのです。 「クラス」とか「インスタンス」とか「継承」といった言葉は言語でも使いま すし、その意味する所も同じです。そしてクラス図ではクラスの「属性」とか 「操作」といった言葉が出てきます。これはプログラム言語でいう「メンバ変 数」や「メソッド」にあたります。だからこれを同じものだと思ってしまうの です。
オブジェクト指向言語を知っている人は、このように、クラス図からすぐプロ グラム言語を連想してしまいます。クラス図を見るときっとプログラムコード が頭の中に浮かんでくるでしょう。しかし、それではいけません。なぜならク ラス図はプログラムコードとは何の関係もないものですから。
例えを出しましょう。もしあなたが株式投資の事を何も知らなくて、証券会社 で説明を受けたとしましょう。株式とはどういうもので、どういう方法で取引 をして、現物だけでなく先物やオプションもある、といったことを教えてもらっ たとしましょう。クラス図はこういった知識を図にしたものです。つまりそも そもソフトウェアとは関係がないのです。もしあなたが株式取引用のソフトを 作ろうとするならば、こうした知識を図にしたクラス図から大いに得るところ があるでしょう。しかしソフトを作ることを念頭に置いてクラス図を書くのは 本末転倒です。
クラス図は静的である
クラス図はオブジェクトとその間の関係を描いたものです。これは「静的」な 関係です。つまり動作は考慮されていないということです。これはクラス図の 本来の役割を考えれば納得がいきます。対象世界が「どうであるか」を示して いるのであって、「どう動くか」を示しているものではないからです。
クラス図が示しているのは、それぞれの瞬間にオブジェクトがどういう属性を 持ち、オブジェクト同士がどう関連しているかです。それぞれの瞬間における 世界の構造を記述できてはじめて、時間経過による世界の移り変わりを記述す ることができるのです。
「どう動くか」を記述するためには状態遷移図やコラボレーション図などを 使います。だから、クラス図はある瞬間における構造だけを記述するようにし ましょう。クラス図における最重要事項は属性と関連を記述することであり、 操作は二の次なのです。プログラミング言語からやってきた人々は往々にして この優先順位を間違えがちです。
クラス図は適当に書け
クラス図を書く時には、何事も「いいかげん」「適当」を心掛けましょう。ク ラス図はあくまで理解のための図なのですから。プレゼンのための資料を作る とき、そこに載せる図の厳密性にこだわりますか?会議の時にホワイトボード に書く図には?クラス図というのは決して珍しいものでも目新しいものでもな く、そういった図の延長線上にあるものなのです。
プログラムを書く時には厳密性にこだわります。あいまいさはバグの元です。 そしてプログラムを書くための仕様書も厳密でなくてはなりません。あいまい な指示ではプログラムを作れませんから。しかしクラス図は何度も言うように プログラムとは関係がありません。だから厳密性にこだわる必要はないのです。
もし、自分の書きたい事がクラス図の記法になかったらどうしますか?心配は いりません。日本語で直接注釈を書けばいいだけです。UMLでは注釈の書き方 も規定されていますから、日本語の文章だらけでも立派にUML準拠なのです。 そしてそれが正しい姿です。どんなことでも、その世界に関係する知見を書い ておくためのものなのですから。
何のためにクラス図を書くのか
UMLのクラス図は本来はとてもシンプルでわかりやすいものです。なぜなら普 通の図とほとんど同じものだからです。書くにはいくつかの約束事を知る必要 がありますが、見るだけなら直感的でわかるでしょう。
もしUMLを知らない人にUMLのクラス図を見せて「この図は難しくてよくわから ない」と言われたとしたら、それはその人がUMLを知らないせいではありませ ん。その人は、UMLの書き方を勉強してもやっぱり「この図は難しくてよくわ からない」と言うでしょう。ほとんどの場合、問題はUMLという形式ではなく 図そのものにあります。
図を「なんのために書くのか」をはっきりさせましょう。自分が何を書きたく て、それを誰に見せたいかです。そうすれば、クライアントに見せるクラス図 に「何とかコントローラ」とか「何とかファクトリー」がたくさん並ぶような 変な事態にはならないでしょう。なぜなら、見せる相手が知らないような情報 はクラス図には入っていないはずだからです。クラス図とは、相手に「あなた の考えていることはこんなことですね?」と確認するためのものですから。