クラス図は何も語らない
UMLはすっかりオブジェクト指向プログラミングの構造を図示するためのスタンダードとなった。その中でも，特にクラス図とシーケンス図に関しては，書く機会が多いのではないだろうか。しかし，だからといって，それがプログラマに伝える情報の量は微々たるものである。 ソフトウェア開発プロジェクトにおいて，近年では「基本設計＝外部設計」「詳細設計＝内部設計」というパターンが多い。ここでいう外部設計とは，システムを外から見たときの振る舞いの定義を指し，内部設計とは，システムの内部の振る舞いの定義を指す。つまり，この場合は，詳細設計で決めるべきことは，システムが行う処理，すなわち必要な業務処理をどのような手順で行うか，である。 言い換えると，問題を解決するための処理手順，すなわちアルゴリズムを決定し，それを文書化することが内部設計で最も重視されることなのである。従来では，この処理手順はフローチャートを使用して記述されていた。「フローチャートなど古い」と言う人もいるが，非常に直感的に処理を記述できることもあり，現在もフローチャートを書くことは全然ありだと思う。 大事なことは，アルゴリズムを「図示することが目的ではない」ということ。あくまで「処理の内容が記述されること」が重要なのだ。プログラム言語は，日本語で記述された業務処理をコンピュータのわかる言葉に翻訳しただけのものである。つまり，プログラム言語に翻訳するための，日本語で文書化された元の原稿が必要なのである。そして，定められたアーキテクチャに従って，その元原稿を適切なモジュールに分割することで，詳細設計が完了する。 元原稿，すなわちアルゴリズムの決定は，数多くの情報，ユーザが行う様々な操作，ネットワークの状況など様々な実行環境の変化を事前に想像し，それらの状況に対応するための処理を考えだすことが肝となる。近年では使用するソフトウェアの種類や組み合わせが多岐にわたるため，相当な経験と知識が必要となる。その複雑さ故に，詳細設計で記述しておくべき文書は，非常に多量となってしまうことは簡単に想像できるだろう。この作業の出来如何によって，実装や試験の容易さが変わってくる。 ここまで説明すれば，詳細設計がクラス図やシーケンス図を書くことだけでは済まないことがわかってもらえると思う。あくまでクラス図やシーケンス図は，モジュール分割を図示しただけに過ぎない。いくらクラス図やシーケンス図を書いたところで，業務処理のアルゴリズムをプログラマが得ることはできないのだ。 詳細設計工程の作業について，クラス図やシーケンス図「のみ」を成果物として定義している例や，それらを記述することが設計だと思っている開発者がいることは，非常に残念なことである。業務処理をプログラムするプログラマにとって，クラス図は何も語ってはくれない。必要な業務処理のアルゴリズムを洗い出し，それを正しく整理できてこそ設計なのだ，と多くの開発者が気づいてくれることを願うばかりだ。
