なぜモデリングをするのか
「モデリングをする」というと、「どうしてモデリングをするのですか？」と
尋ねられることがあります。
仕様を整理し、抜け漏れを探すのに、モデルがあるとないでは大きな違いがあります。
理解を助け、抜けている処理る処理や条件を洗い出すのに、モデリングで可視化することは
非常に役立ちます。
また、可視化された情報は、議論のたたき台として、
ビジネスユーザーと、振る舞いを共有するときにも使えます。
CSの方がUMLで新機能の動きが理解できれば、適切なサポートになり、
これもまた、ユーザーが受ける品質に寄与します。
例えば、状態遷移図から状態遷移表を作って、抜けている箇所を見つけるのは
有名ですね。テストで使われるモデリングには、国際的に使われるものや、
主に国内で使われるものなど、様々なものがあります。
モデリングをすると何が違うのか
モデリングがある場合、ステークホルダーが多い場合の情報共有に便利ですし、
レビューによって、認識のずれを訂正しやすくなります。
「出来上がったものが、思ってたのと違った」
というような行き違いを削減するのに寄与します。
また、モデリングによって洗い出された、エンティティのライフサイクルを
見通してCRUD条件を洗い出したり、操作のリピートのテストが必要であると判断したり、
いろいろな気付きを得ることができます。
なお、少し余談ですが、人の記憶タイプは、読み・書き・両方、などの
個人の特性がありますが、モデリングにも好き・嫌いや、得意・不得意がある傾向がみられます。
モデリングをする時間がもったいない、という現場もあるでしょうから、
適切に判断するのがよいでしょう。
個人的な経験としては、基本的な処理はUMLにしておき、新しいメンバーが入った時の
説明に使ったり、根幹の処理だけでも作って置き、抜け漏れ防止に使うなど
部分的に適用するのが、リソース的にもバランスが良いと思っています。
モデリングには多数の種類があり、それぞれ目的に応じて適切なものを選びたいですね
いろいろなモデリング
UML
国際的に使われるモデリング言語。
現在も拡張されている。
マインドマップ
マインドマップをモデリングに数えていいのかは少し悩みますが、テスト設計には
欠かせないものです。下記の図は、軽いサンプルです。
Xmind というツールでかかれています。TabとEnterの操作だけおぼえれば、
すぐにでも書けます。
状態遷移図
〇〇中、と書くのがコツで、目的によっても書き方が変わります。
書きあがったら、〇〇中（状態）をつなぐ線の部分にテスト条件を組み合わせて
テストを設計することができます。
いまはインターネットで調べれば、たくさんの凡例が出てきますね。
特性要因図
別名「魚の骨」、「石川ダイアグラム」と、いろいろな呼び名がありますが、
古くから使われており、不具合の原因分析や、制作物のタスク分解などに便利です。
これも Xmind で、書くことができます。
あみだダイアグラム
はな丸が考案した、時系列のイベントと条件を整理するときに使っている、見た目があみだくじのようなダイアグラム。
以前はお刺身モデルと言っていましたが、海外ではSashimi modelという
ワークフロー(＝バックスラッシュモデル？）があるようですので、変えてみました。