UML とは？
世界共通のモデル言語
Microsoft や Adobe などの大手が提供するアプリケーションファミリや
数十の LAN を Web を介して繋ぎ、データベースを共有し、情報交換が可能で
個別の LAN のニーズに合わせてカスタマイズ可能な Web サービスを想像してください
これらのような、柔軟で、国際的で、大規模なシステムの設計がいかに難しいか
それなりのアプリケーションの開発経験があれば、よくわかることでしょう
しかし、徹底したモデル化による単純化作業と
デザインパターンで最適化された強固なコンポーネントシステムを建築できれば
小規模な企業や個人でも、巨大なシステムを設計することは不可能ではありません
こうした、完成度の高いコンポーネントシステムを開発するためには
行き当たりばったりのプログラミングでは、開発段階で確実に失敗します
犬小屋を作る時に、わざわざ JIS に準拠した設計図を書く必要はありませんが
高層ビルを建築する時に、設計図を用意しなければどうなるか、容易に想像できます
もし、あなたが、小さなプログラムは比較的自由に作ることができるのに
複雑になると、開発に失敗してしまう傾向だとすれば、確実に設計力不足です
複雑なシステムをモデル化を行わずにプログラミングするということは
ビルやマンションを、設計図無しに建築することに等しいくらい無謀なのです
そこで、これまで、様々なモデルの設計手法が考案されました
一時期は、数十に及ぶモデル化手法が混在し、様々な設計が行われたのですが
やはり、開発現場は使いやすく、柔軟で、統一された標準を好みます
そこで、最終的に OMT 法、Booch 法、OOSE 法などが多く使われるようになり
これらのモデルは、デザインパターンの専門書などでよく見かけられます
しかし、これらのモデルも、国際的に統一されたものではありませんでした
そこで、1989 年に設立された 800 以上の会員企業を持つ国際組織
OMG (Object Management Group) が複雑なシステムを図式化し
統一されたモデル化言語を作ろうと、標準化に乗り出したのです
そして、混沌とした手法乱立の時代を超え、生き残った OMT や Booch など
標準的な設計手法を統一し、結集させたものが
1996 年に定義された UML (Unified Modeling Langauge) です
その後も、UML は発展し、これを書いている今では UML 1.3 が主流です
近い将来、UML 2.0 が制定させる見込みなので、動向に注意を払ってください
モデル化言語とは
UML などのモデル化言語はプログラミング言語ではありません
これをどんなに勉強しても、画面に Hello world を表示することはできませんし
可愛い猫耳娘が登場する、ファンタスティックなゲームが作れるわけでもありません
UML は、開発や仕様の決定の段階で使われる図を標準化したものです
世界中の企業や開発者が、標準化された図式を使うことができるようになれば
言語や開発手法の垣根を越えて、目的のプログラムを認識することができます
また、美しい設計は高度なシステムの建築に必要不可欠であり
徹底的に議論を重ねて作られた UML は、まさに最適な設計図なのです
次の図は、UML の静的構造図と呼ばれる、図式化されたモデルです
本来は、クラス名が太字で、抽象クラスが斜体、それ以外はプレーンとなります
ですが、筆者の手元に OMG が定めるスタイルガイドラインに
完全に従ったモデリングソフトウェアがないので、これで我慢します
この図は Image 抽象クラスがあり、Metafile と Bitmap クラスが
Image クラスを継承していることを表しています
モデル設計手法は、このように図として記述するための方法であり
UML はまさに、オブジェクト指向の図式化の世界標準の仕様なのです
図といっても、UML には曖昧さはほとんどありません
仕様書は、下手もすればプログラミング言語の仕様書よりも太くなります
スタイルガイドラインや意味論が徹底されており
手書きで UML を記述する場合は、OMG の定めるスタイルガイドに従う必要があります
例えば、クラスは太字、抽象クラスは斜体といったスタイルが定められています
スタイルガイドは、記法ではないので従う必要はありませんが、強く推奨されています
上の図は、スタイルガイドに従っていないので、やや問題があります
同時に UML では、関係する様々な用語を定義しています
筆者は、可能な限り定義に基づいた正しい表現で解説するように努力しますが
それでも、一部では正確ではない表現が混在する可能性があります
明らかに定義に反し、誤っている文を見つけた場合はご連絡ください
ビューモデル
システムを図式化する場合、ある問題点にぶつかります
図が複雑すぎる場合、特に、プログラミングなどの概念を含んでいる場合
クライアントや要求分析者は、これを理解できないかもしれません
図を利用するのは、設計者と開発者だけとは限らないのです
マーケティング部門や、プロセス管理者にも理解できる必要があります
そうすれば、社全体やクライアントも、何をどう作っているのか理解できます
クライアントが、自分が要求したことが伝わっているかどうか
心配する必要もなくなることでしょう
しかし、図を素人も理解できるように抽象化、単純化させすぎると
今度は設計が曖昧になりすぎて、設計者や開発者の間で意思疎通が難しくなります
このように、図式といっても見る立場によって目的が異なってしまいます
そこで、UML は目的によって異なるいくつかのビューを制定しています
例えば、上記した図は静的構造図と呼ばれるものです
このほかにも、UML は次のような図を定義しています
設計者は、システムのモデリングの目的に応じて図を記述し
利用者や開発者などに、適切な図を用いて説明を行うことができます
例えばユースケース図は、ユーザーの視点でシステムの動作を表した図です
これは、ユーザーが記述して設計者に渡しても良いでしょうし
設計者がシステムの動作を説明するためにユーザーに見せるのという利用方法もあります
設計時に注意するべき問題
UML は単純な図式であり、プログラミング言語のようにエラーがでるものではありません
しかし、多くの人が仕様に基づいた認識で図を理解できるように
設計者は可能な限り OMG が定める仕様に従って記述しなければなりません
さらに、図で表すべき情報は単純に表現しなければなりません
通常は、単色のベクタグラフィックスで表現できる図が好ましく
複雑な色による区別や、ビットマップなどは使うべきではありません
理由は、色を認識する能力に障害のある開発者にも読める図であるべきですし
わずかな違い（プレーンと斜体のテキストなど）は見落とす可能性があるからです
図におけるスタイルは、ある程度ツールに委ねられる部分がありますが
設計者は、色やスタイルでモデルの性質を表現するべきではありません
また、特定のプログラミング言語に依存した図も避けるべきです
他の言語に移植するとき、再度設計図を描くのは効率的ではありません
設計図は、システムの機能をできる限り抽象化した
言語に依存しない図であるべきでしょう
そのために、設計者は複数のオブジェクト指向言語の経験が必要です
実装依存
UML はプログラミング言語ではないので、拡張はかなりの面で自由です
大切なのは、この図を使う人間が理解しやすいように書くということなのです
そのため、UML 実装ツールの多くは、完全に OMG の仕様に従うことはないでしょう
何らかの実装依存レベルの表現が含まれることがしばしばあります
実際に UML の仕様でも、ツールにゆだねている部分がかなりあります
また、上記したように UML のビューモデルは様々であり
これらの図を全てサポートしている UML ツールもそう多くはありません
頻繁に使われる、ユースケースや静的構造図などは、ほとんどのツールでサポートされます
設計技術向上が急務
.NET のような巨大なシステムを、他のシステムでエミュレートするプログラムや
高度な OS の基盤を、たった一人のハッカーが作ってしまうこともあります
大規模システムの開発は、欧米企業の特権ではありません
にもかかわらず、国内では世界を屠る巨大なシステムを建築した例は少なく
事実上、多くのパッケージソフト市場は米国に独占されています
日本の企業が、米産のソフトウェアのようなものを作れないわけではありません
グラフィックエディタや、OS も作ろうと思えば作れますし
確かに、一部の市場では日本のソフトウェアがシェアを伸ばしているものもあります
ですが、国産のソフトウェアは高価で、しかも不安定で機能が悪い場合が多いのです
「これ、本当に法人が開発したの？」と思わせるパッケージソフトもかなり存在します
これらの原因は、抽象化や原理に基づく分析、推論が苦手な日本人の気質にあります
ソフトハウスは、プログラムを打ち込める人材を探し
教育機関も、プログラムを作れる人間を育てることに必死で
デザイン、開発管理、再利用主導型エンジニアリングなどの分野で遅れているのです
設計技術や開発管理が不十分な組織の企業は
これが最適化されている組織に比べて、倍以上の生産コストが発生します
また、設計が未熟だったために抽象化が不十分なシステムは
保守が難しく、開発が進めば進むほど不安定になります
残念なことに、モデル化や設計にお金と時間をかけたとしても
それが自動的にプログラムとして具現化され、売り物になるわけではありません
その後、モデルを参考にさらに開発を進めていく必要があります
一日でも早くソフトウェアを完成させ、人件費を削減したい企業は
設計をおろそかにし、未熟な状態で開発を急いでしまいます
が、高度な設計に基づいたコンポーネントは、再利用や共有、プラグイン可能であり
これは、最終的に生産効率や信頼性の向上につながるということを
開発現場の管理者や、企業の経営者たちがいち早く気づく必要があります
わが国が、ソフトウェアを含む様々な産業で国際的な競争力を取り戻すために
物事のモデル化や抽象化、実体ではなくその過程を分析できる能力を教育し
高度な設計力、開発プロセスの管理を市場に導入する必要が急務なのです