その他の動き（設計モデリングと形式手法）

最後にモデリングの理論面での動きに少し触れておきましょう。

現在、ソフトウェア設計の世界において、モデリングの考え方はデザインパターンやアーキテクチャパターンを通して着実に浸透しつつあります。例えば、新たなフレームワークをプロジェクトで採用する際には、そのフレームワークの設計思想や基本APIに関してアーキテクチャドキュメントの文章やそこに描かれているUML図（クラス図、シーケンス図、ステートマシン図などが中心）を読みこなすことになるでしょう。

また、各種のデザインパターンの背後には共通する設計原則が控えていることが近年明らかになり、結合度や凝集度といったモジュール原則に基づく議論をもとにしてソフトウェア工学的にきちんとした説明が付くようになってきました（Robert Martin著『アジャイルソフトウェア開発の奥儀』ソフトバンク2004）。

このソフトウェア設計原則を単なる指針として心がけるのではなく、具体的なメトリクスとして整備し、アーキテクチャの評価に利用しよう、場合によってはツール化しようという動きが出てきました。MIT（マサチューセッツ工科大学）発のベンチャーであるTechM@trix社の「Lattix」などが代表例です。

これはDSM（Dependency Structure Matrix）手法に基づいて大規模なアーキテクチャ内のモジュール間の依存関係を構造分析することで、サブシステム構成を評価したり構築したりするツールです。興味深いことにベースとなるDSM手法はソフトウェアだけでなく、半導体や自動車産業などの業務プロセス構造のアーキテクチャ分析にも応用され成果を上げていますので、今後、ビジネスモデリングとの組み合わせも注目されます（キム・クラーク他『デザイン・ルール—モジュール化パワー』東洋経済新報社2004）。

可能性が広がるモデリング

また近年、ソフトウェア工学の世界では昔から研究されてきた形式手法（Formal Method略してFM）の実務への適用の可能性が盛んに議論され、ライトウェイト・フォーマル手法（LFM）として注目されます。

情報家電や自動車のような日常的に大量に利用される製品の安全性・信頼性の確保のための技術としてのニーズとコンピュータが一昔前には信じられないくらいの計算パワーをもつようになり、技術的に実行可能な範囲が広がったというシーズの交差するところで、形式手法の現実問題への適用可能性が見えてきたのです。

理由としては、モデル検査（model checking）の手法とツールが洗練され（SPINなど）、数学的な素養がなくても現場レベルで取り組むことが可能な状況が生まれたということなのでしょう。モデル検査とは、対象システムを状態機械としてモデル化しその状態空間を網羅的に探索することで要求仕様の検証を行うというものです。

SPINやLFM注目のおかげで、他の形式手法である、ZやVDMとそのオブジェクト指向版であるVDM＋＋、さらに現場よりのDbC（契約による設計Design by Contract）といった技法にも光が当たるようになったのはうれしいことです。心あるプログラマはテストや表明（アサーション）を各プログラムモジュールのコードとセットで作るようになってきていますが、これらはDbCの現場レベルでの実践と捉えることができるでしょう。

またRubyやGroovyのような動的オブジェクト指向言語や、Haskel、Ocaml、Scalaといった関数型言語を用いてDSL（ドメイン特化言語）を作成したり、あるいは直接、実行可能仕様モデルをそれらのプログラミング言語で記述し実行検証するという試みも注目されています。

このようにモデリングとは、何もダイアグラムを描くことに限定されるものではなく、対象システムの振る舞いや性質を正しく実装に依存しない形で記述する試みの総称ということができます。

以上述べてきたように、モデリングに関して応用面・理論面ともに新しい動きが出てきていて目が離せません。また最近の日本での大きなトピックスとしては、UMTP（UMLモデリング技術推進協議会）のL3レベル認定試験の開始があります。

L1はUMLの文法の基本知識、L2はUMLダイアグラムの基本リテラシーの確認でしたが、L3試験ではWebベースの試験でありながら、複雑な業務領域の文章題をA4で1〜2枚程度与えられて、実際に実務的なモデリングスキルを試す画期的なものになっています。また設計原則やOCL（オブジェクト制約言語）に関する基本スキルも問うことになっています。ぜひチャレンジしてみてください。 タイトルへ戻る