動詞de!! モデリング ④「考え方編」

Satomi Joba June 15, 2015 Leave a Comment

平鍋

「モデリング」してますか？
今日は「動詞de!! モデリング」の「考え方編」ということで、どうやってこのモデリング手法が機能するのか、という原理について、お話をいただきます。(動詞de!! モデリング – (1)導入編 / (2)実践編 / (3)C言語編)

では、萩原さん、お願いします。

誰でもできるように設けた2つの基準 – 妥当性確認と検証

萩原さん

今回のモデリング、特徴的にはですね、「BeforeからAfterへの変換手順に従って進める」という所です。これはいわゆるトップダウン的な方法ですね。モデリングに慣れた人にとっては冗長に感じるかもしれませんが、やはり「誰でもできる」ということを考えた場合ですね、明確な手順と基準があった方がやりやすくなります。

特徴を言いますと、まず「変換手順」があるという事です。正しいものを正しく変換すれば、「最後まで正しい」というトップダウン的な手法になります。これは、いわゆる構造化プログラムと同じ考え方です。
もう一つの点は、途中で間違いを修正できる、という点です。構造化設計とか構造化プログラミングの問題は、途中で間違っているかどうか、という事を確認しないで、そのまま変換を進めてしまい、最後に、間違っているということが発覚して「ダメだった」という事がありますので、ここら辺はですね、途中で「間違ってるかどうか」「いいか悪いか」を確認する手順になってます。
この為にですね、手順に加えて、解りやすい基準も設定しています。

2つ、基準があります。

1つは「妥当性確認」の基準ですね。これは、正しい事を確認します。「正しい」というのは、「作るものが、目的を満たしているか」いわゆる、お客様に価値を提供できているか、という事を確認します。もう1つは「検証の基準」ですね。「正しく行っていること」を確認します。途中で間違いが混入してないか、ということを確認していきます。
最初に、妥当性を確認する基準について説明したいと思います。

クラス図を読み上げて、モデルの妥当性を確認する

これは簡単ですね。「読み上げた機能が目的を満たしてる」という事です。クラス図は、実は、読み上げると、機能を表現する文章になります。この機能が、お客様に対して価値を提供する機能であるか、を確認していきます。

例えば、下のクラス図は「タイマーは、デバイスを節電する」という形で読み上げることが可能です。

正しく読み上げる為には「を」とか「へ」という助詞も一緒に書いてください。そうすると、日本語でクラス図の良し悪しが確認できるようになります。
よく、クラス図を提供するときに、「センスが良い」「センスが悪い」というような形でレビューすることがありますけど、設計センスというのは、人それぞれですので、「センスが良い」と言われても結構困ることがありますが、このように読み上げてしまえば、日本語で、良し悪しが確認できる。つまり、ドメインに関する知識をベースにいいか悪いかを判断できる形になります。

例えば、ロール名が入った場合も「タイマーは、デバイスを節電する」「その時に、節電支持者の役割になる」というような形で読み上げることができます。
次に、変換の正しさを検証する基準になります。

変換前後のクラス図を読み上げて結果が一致しているかを検証する

BeforeからAfterへの変換手順というのが、今回のモデリング手順になりますが、その変換自体が正しく行われてるか、という事を確認していく手順です。ここで変換に間違いがなければ、原理的には、最初に正しかったものは最後まで正しいという状態を確保できます。これを、どのようなやり方で確認するか、検証するかというと「Beforeのクラス図で読み上げた時の機能とAfterのクラス図を読み上げた時の機能が一致するか」で確認していきます。