モデリング技術を学ぼう黒澤 慎太郎

去年まで重視していたこと

• ソフトウェアテスト

• ソフトウェアアーキテクチャ

• リファクタリング

ここ２年くらいで読んだ書籍

• 知識ゼロから学ぶソフトウェアテスト

• ソフトウェアテストの技法

• 実践プログラムテスト入門

• リファクタリング

• エンタープライズアプリケーションアーキテクチャパターン

• レガシーコード改善ガイド

• アジャイルソフトウェア開発の奥義

• アナリシスパターン

気づいたこと

• 「テストを作成する前にモデル化する」

• 「これらのモデルを用いて設計する」

モデリング技術が必須

–Brian Wilson 「システム仕様の分析学」より

“モデルとは、ある人にとっての、ある状況、あるいはある状況についての概念の明示的な解釈”

–児玉公信「モデリングの本質」より

“モデルとは、仕組みや原理を理解したり説明したりするために、それに関わる最小の要素とそれらが互いにどう関わりあうかを記述する”

モデリングとは？

• モデルは、つまるところ「人の解釈」

• 余分なものを排除し、本質だけを抽出する

設計

実装

モデリング

要求仕様

テスト

設計・実装・テストはモデルありき

こんなことはありませんか？

• 仕様を渡されたが・・・

• どのようなクラスを作ればいいのかわからない

• デザインパターンを学んだが、いまいちピンとこない

• どのようなデータベーススキーマを作ればいいのかわからない

• テストをどのように作ればいいのかわからない

それはゴールが明確じゃないからではないでしょうか

どのようなクラスを作ればいいのかわからない

• オブジェクト指向は、オブジェクト同士のメッセージングで表現する

• では、表現すべき「オブジェクト」の定義はどこに？

• 「オブジェクト」という表現すべきゴールが明確に定義されていないから、どのようなクラスが適切かわからない。

• 経験を積むと、勘所が暗黙知として蓄積され、なんとなくわかってきてしまう。

• しかし、その人が「なんとなく」わかっているだけなので、チーム開発では論外。モデル化し、オブジェクトを共通の知識とするべし。

デザインパターンを学んだが、いまいちピンとこない

• デザインパターンは、ざっくり言うと、オブジェクト指向において「オブジェクト」を効率よく利用できるような方法、トレードオフをまとめたもの。

• クラスと同じように、「オブジェクト」が明確に定義されていない状態で適用しても混沌とするだけ。

• 勉強不足なのでおそらくだけども、デザインパターンを適用するとき、「クラス」からスタートするのではない。まずモデルがあって、それを基に設計する。そしてデザインパターンを適用し、そこで初めてクラスを定義するのではなかろうか。

• どうしてもソフトウェア開発者は、まずプログラミングを勉強するので、クラスからデザインパターンを学んでしまう。それでは混乱する。

• 例「デザパタや設計の本を読んでいるけど、抽象的すぎてわからない」→考え方のベースに、「クラス」やコードがあるため。

• 「設計を表現するためのコード」であり、「コードを決定するための設計」ではない。

どのようなデータベーススキーマを作ればいいのかわからない

• これは経験がない人もいるかもしれない

• オブジェクト指向は、「構造化技法」「構造化プログラミング」から発展してきたような雰囲気がある

• 構造化は、データを中心とする考え方

• データに着目してモデリングすることも、わりと一般的

• メタファも豊富「人は様々な属性というデータを持つ。名前、生年月日など。これらがテーブルのカラムやレコードとなる」

• それでもわからない人にはわからない。

テストをどのように作ればいいのかわからない

• 結局は、「正解が定義されていないのにテストはできない」ということ。

• システムテストであれば、要求仕様を正解とすればいいかもしれない。

• しかし、要求を満たすために、私たちは小さい部品を持ち寄る。

• その小さい部品の正解は、要求仕様に無い。

モデリング技術を学ぼう

• まだこれから学ぶのでオススメ書籍とか書けないのが辛い

• とりあえず「モデリングの本質」を購入。

モデリングの恩恵

• 漏れがない適切なテスト

• 読みやすいコード

• 仕様への深い理解

• 円滑なコミュニケーション

• 変更に強い、しなやかな設計

（私の予想です）

レッツ モデリング！モデリングの必要性が伝わったと信じて

その他補足

ソフトウェアテストにおけるモデリング

• 「実践プログラムテスト入門」では、テスト作成前にモデル化する方法を紹介している。

• そして「作ったモデルにもバグが潜む。テストしろ」といってくる

• そもそも「実践プログラムテスト入門」が難しいので心がへし折れる。私は折れた。

設計におけるモデル

• モデルありきで説明しているのが多い印象。

• UMLとか。

• 「そもそもそのモデルってどう抽出したの？」という疑問には答えてくれない。そして実務と結びづらくなる。

アナリシスパターン

• モデルと設計の中間に位置づけられるようなパターンを紹介する稀有な書籍

• そのためか敷居が高い。つまり難解。

• しかし、わかる人には目から鱗的な書籍らしいので、機を見てリベンジしたい。

開発におけるモデリング

• モデルは一回作成したらそれで終わりではない

• モデルにもバグが潜む可能性があったり、より良い表現が見つかったりする

• 開発工程で、何度もモデリングとコーディング、テストを行ったり来たりするはず。

• また、モデルとコーディングをより密にしていく開発手法が話題になっていたりする。ドメイン駆動設計という。

• 個人的にだけどウォーターフォールはもう無理がある気がする。変更する必要があるからソフトウェアで作るのであって、変更がないし、出もどりも発生しない前提の開発であればハードにプログラムできるはず。矛盾を感じる。

ドメインモデル

UI層

アプリケーション層

データベース層

ドメインモデル

レガシーコード改善ガイド

• 「自動テストがないコードはレガシー」と定義して、レガシーコードを排除していく素晴らしいノウハウ集。

• 「リファクタリングを行える状態にするためのノウハウ集」が正しい(リファクタリングの手法も使っているけど)。

• なぜなら、リファクタリングは「振る舞いが変わらない保証がなければリスクを負った単なる書き換えに過ぎない」ので。自動テストがないレガシーコードでリファクタリングは不可。

• 「コードからモデルを抽出していく」という珍しいアプローチを取る書籍だと思う。

おまけ

• ある人に「UML、昔流行ったけど、もう全然聞かなくなった。やっぱり不要だったんだ」と言われた。

• UMLが当たり前になりすぎて、誰も話題にしなくなっただけですよ・・・

ご静聴ありがとうございました