実務で使えるモデリングをベテラン・エンジニアに学ぶ ―― 20th Open SESSAME Seminar

●状態マシン図を描いてみる

　続いて，同じくSESSAMEのメンバであるセイコーエプソンの島 敏博氏が，モデリングの方法とレビューの観点について，演習問題を交えて解説した（写真4）．

写真4　講演を行う島 敏博氏（SESSAME/セイコーエプソン）

　最初に状態マシン図の記法を説明し，演習が始まった（写真5）．演習問題は「信号機のモデリング」である．「赤」-「青」-「黄」と遷移するシステムから，幹線用と支線用の二つの信号を制御するシステム，夜間は点滅表示に切り替わるシステムへと，機能を追加したシステムをモデリングしていく．

写真5　状態マシン図の描き方の説明

　モデルが描けたら，前に持っていって発表し，そのモデルに対して講師がコメントした．このときに，どのモデルが正解なのかではなく，そのモデルの目のつけどころや良いところを見つけてコメントし，伸ばしていくのが重要であるとして，レビューを実践してみせた．

●「やりたいこと」と「プログラム」をモデルで中継

　C言語やC++言語は，グローバル変数や#include，#if defをいくらでも定義できるなど，制約の少ない言語である．だからといって自由に記述していては，ソフトウェア開発が破たんする原因となりかねない．島氏は，ソフトウェアをきちんと設計したいなら，モデリング云々の前に，自分たちのコーディング規約を設けるべきだという．例えば，「グローバル変数は使わない」，「一つのソースは100行まで」，「#includeを入れ子にしない」，「.hファイルにはpublicな関数定義以外は含めない」，「#if defはヘッダを1回だけincludeするため以外には使わない」などの規約を設けて実践することが重要である．

　ソフトウェア開発は，「やりたいこと」を実現するための「プログラム」を作るものだが，「やりたいこと」と「プログラム」の間の距離は長い．それを中継するのが「モデル」である．さらに，やりたいことを表現するモデル（分析モデル）と，どう作るかを表現するモデル（設計モデル）に分けると分かりやすくなる（写真6）．さらに，モデル駆動開発ツールを使えば，設計モデルと実装コード（プログラム）を一致させることができる（ただし，設計モデルの中に手で書いたコードを埋め込む形のモデル駆動開発ツールでは，コードを自動生成しているからといってバグが減るわけではない）． 

写真6　モデルとは，「やりたいこと」と「プログラム」をつなぐもの

●モデル図は3種類で事足りる

　UMLにはたくさんの図が定義されているが，モデリングを導入する際には，「状態マシン図」，「クラス図」，「コミュニケーション図」だけで事足りるという．

　モデリングの手始めとしては，状態マシン図から考えてみるのがやりやすいという．オブジェクト指向モデリングを始めようとしてクラスの検討から入っても，適切なクラスを見つけるのはとても難しい．それに対して，システムに発生するイベントを見つけるのは容易なので，イベントによって状態を遷移する状態マシン図を描き，状態を持っているものをクラスとして見つけていくとよい．

　また，既存のソース・コードをそのままモデルに置き換えてから，モデルを改善するという方法もある．ソース・コードの中の「XXXX.h」ファイルと「XXXX.c」ファイルの組み合わせをそのままクラスとしてとらえ，クラス図として書き表してみる（写真7）．すると，一つのクラスが意外といろんなことをしていることに気付く．そこで，担っている役割（責務）ごとにクラスを分割してみる．クラス図だけで良しあしを判別できないときは，オブジェクト間の関数呼び出しを表現するコミュニケーション図を描いてみて，オブジェクトが責務を持ちすぎないように改善していけばよいのだという．

写真7　コードをそのままクラス図にする