UMLやSysMLなどのモデリングは“いつ”“何を”“どうするのか”：プロジェクトを成功させるモデリングの極意（3）（1/8 ページ）
「モデリングはいつ誰が何をどのようにするのか」――今回はソフトウェア開発の現場で、モデリングを実際にどのように実施しているのか見ていきましょう。またUMLやSysMLの使いにくいところを、開発現場ではどのようにカバーしているのかも見ていきます。
はじめに
連載の第1回では“モデリングとは何か”から始めて、モデリングの目的やモデリングで求められているもの、さらにモデリング手法を一巡りしました。そして第2回ではモデリングツールにどんなものがあるかを紹介し、モデリングの歴史と現在のトレンドを見てきました。
今回はモデリング基礎の3回目ということで、最初に、現在の代表的なモデリング手法として紹介したUMLとSysMLの使いにくいところ、そしてそれを開発現場ではどのようにカバーしているかを見ていきます。次にモデリングの開発現場でのやり方、つまりモデリングはいつ何をどうするのかを紹介し、それがウォーターフォール型開発だけでなく、アジャイル開発や派生開発でどのように実施されているかを見ていきます。前回と同様、最後に今回の記事で学んだ教訓をまとめます。
UML/SysMLの使いにくいところと、それを使いこなすコツ
UMLとSysMLは組み込み系開発で比較的多く使われていますので、ここではUMLとSysMLの使いにくいところと、開発現場でそれを克服して使いこなすコツを紹介していきます。
UMLの使いにくいところと開発現場での実際的対応
（1）階層記述ができない
UMLで大規模なシステムをモデリングするときに、使いにくい欠点としては「階層記述」ができないという点を挙げることができます。大規模なシステムでは、ユースケースやクラス、オブジェクト、シーケンスなどの個数が膨大な量になり、ユースケース図やクラス図、シーケンス図などを描くときに階層記述ができないと非常に大きな紙が必要になります。A3用紙であっても描ききれなくなります。
そこで開発現場では何らかの工夫をして、これらの図を階層記述をしているのが実情です。しかし、階層記述の方法が統一されていないため、各組織や各プロジェクト、さらに個人で違う記述をしていることがあります。結果として、階層記述の方法を確かめるところから、レビューを始めるということになります。
（2）要求図が弱い
UMLで要求をまとめる図はユースケース図とそれを補間するシナリオ記述、さらに詳細に記述するためにアクティビティ図などを用いますが、要求図としての分かりやすさとしては不十分です。
ユースケース図で要求とそれらの概略の関係は分かりますが、要求の一覧や要求間の関係、特に内包関係、要求の差分、要求の優先度などの記述は弱いものになっています。それを補間するシナリオ記述は基本的に自然言語で記述するため、モデラーの表現能力に大きく依存します。逆にアクティビティ図は機能がありすぎて、要求を記述すると別の図のようになってしまいます。
開発現場ではユースケース図で要求の概略を表現し、詳細や一覧は昔ながらのExcelを使って自然言語で記述し、それに要求番号を振って、トレーサビリティを高めているような記述方法をよく見かけます。
（3）仕様が膨大で不統一
UMLはその歴史から分かるように、モデル図と仕様が膨大になっていて、その思想も記述も不統一です。平たく言えば、図がばらばらで多すぎます。図が多いので、真面目なメンバー（融通がきかないメンバー）はどうしても多くの図を描いてしまいます。類似の情報を複数の図やその説明で見かけることになります。さらに悪いことにその用語や使い方がモデル図間で統一されておらず、同じ用語でもモデル図で違う情報になっていることもあり、どれを信用するか分からなくなります。まさしく魑魅魍魎な図になりがちです。
開発現場では新規の開発よりも既存開発（改良開発）が多く、既存の多数のUML図をほぼコピペして再利用していることが多くなっています。コピペで低コストなのはいいことかもしれません（本当はそんなことはありません！）が、図が多いため、差分管理ができずに、全ての図の全ての部分を延々と保守続けることになります。いざ差分を探そうとすると、非常に面倒なことになります。
（4）トレーサビリティが弱い
各モデル図で使用した要求やクラス、オブジェクト、シーケンスなどが他の図でどのようになっているかを追跡するときに、UMLでは弱すぎます。UMLツールによって、ある程度のトレーサビリティは保証されますが、図として見た場合は、トレーサビリティがなく、見にくくなっています。
開発現場では、ここでもUML図とは別にExcelなどを使って、トレーサビリティを保証するようにしている場合が多くなっています。
（5）目的が総花的
仕様が膨大という欠点と同様ですが、UMLを描く目的が曖昧になるとUMLで作ったモデルも総花的になりがちです。このため、モデル図は大きくなり、大きな紙（A3用紙）を必要とします。
（6）コード生成が弱い
UML2.0になってコード生成は強化はされていますが、UMLでコード生成をするのは弱く、はっきり言って、使いものになりません。特に例外処理のコードも含めると面倒なことになります。最初の1回はコード生成をしても、その後、プログラムを変更する必要が生じたときに、モデル図から変更するのは骨が折れます。心が折れます。
（7）差分表記（相違性と共通性の表記）が弱い
これはUML特有の欠点ではなく、多くの図的表現に当てはまりますが、以前のシステムとの差分、以前のモデル図との差分の記述が明示的にできません。ソフトウェアプロダクトラインエンジニアリング（SPLE）で使われるフィーチャー図のように差分を明示的に記述できません。開発現場では前のモデル図とどこが変わったのか、逆にどこが同じなのかを何らかの方法で記述し、共通部と差分（派生部）を明確に示す必要があります。
Copyright © ITmedia, Inc. All Rights Reserved.