UMLやSysMLなどのモデリングは“いつ”“何を”“どうするのか”：プロジェクトを成功させるモデリングの極意（3）（3/8 ページ）

「モデリングはいつ誰が何をどのようにするのか」――今回はソフトウェア開発の現場で、モデリングを実際にどのように実施しているのか見ていきましょう。またUMLやSysMLの使いにくいところを、開発現場ではどのようにカバーしているのかも見ていきます。

[五味弘，MONOist]

SysMLの使いにくいところと使いこなすコツ

（1）UMLほど流行っていない

　SysMLの欠点は何と言ってもUMLほど「流行っていない」ことです。このためUMLと比較して、SysMLの欠点とそれを克服するコツも多く出回っていません。教科書的ないいところだけを紹介する情報ばかりになっています。いまは期待先行の期間といえましょう。このため、一緒に悩んでくれる人も周りに少ないのが現実です。ツール群についても、SysMLをサポートする製品こそ増えてきましたが、フリーのツールはまだまだ少ないのが現状です。

（2）要求図に大きな面積が必要

　SysMLでは要求図にUMLのユースケース図以上に面積が必要となります。例えば、要求一覧をExcelで管理してきた今までの方法と比較すると、使用する面積は雲泥の差になります。要求間の関係を書くために、どうしても無駄な空白部分が多くなってしまいます。

　開発現場でのコツとしては（ワンストップでなくなりますが）、要求図には名前のみを書き、その内容は別途書くようにして、なるべく要求とその関係を一覧できるようにします。後々仕様変更があったときに、要求間の関係が重要になってくることが多いことからのコツになります。戦略や企画、要求レベルになるとどうしても、一覧表示やその管理が政治的・技術的・運用的に必要になってきます。

（3）その他の欠点とコツ

その他の欠点とそれをカバーするコツは UML に準じます。UMLでの経験がSysMLでも生かされることでしょう。UMLを知っていてSysMLをこれから使おうとするのはお勧めします。

図3. SysMLとUMLの図の違い

　図3に示すように、SysMLはUMLのサブセットに幾つかの図を加えたものになっています。全体的には SysMLの方が小さな仕様になっていますが、SysMLで採用されなかったUMLの図をSysMLとして表記することも可能ですので、（良くないことでお勧めしませんが）大量に描くことも自由です。

　SysMLのトピックは、新たに加わった要求図とパラメトリック図です。要求図は名前の通り、要求をモデリングする図です。パラメトリック図は実装の制約条件を記述できるモデル図です。それぞれの例は第1回の記事にありますので参照してください。