モデリングとプログラミングの観点の違い

要求開発の記事を読みながら思ったことをメモ。
＃あくまでもメモ書きであり、ロジカルでない。

モデリングとプログラミングは、根底から考え方が違うと思う。
モデリングできたからと言って、プログラムがすぐにできるわけではないし、モデルだけではシステムは動かない。
でも、モデリングで分析し尽さないと、思想のないプログラムが増殖し、それらのプログラムはすぐにスパゲティになる。
モデリングとプログラミングは相互に補完する関係にある。

モデリング技法には、OOAやDOA、他にも色々あるけど、基本は、エンティティを中心にその関係を考える。
一方、プログラミングは、基本はやはり手続きを考える。

構造化分析とは異なり、モデリングという概念が出てきたのは、DOAからだと思う。
DOAはモデルからデータと処理を区別して、データだけを取り出し、その関係をまとめる手法。
DOAはエンティティという入れ物が最初にありき。

DOAでもT字形ERでは、エンティティをリソースとイベントという2種類に分けて考える。
リソースは、マスタ系Tbl。例えば、顧客・商品など。
イベントは、トランザクション系Tbl。例えば、注文・在庫など。

リソースの関係からイベントが生じるという発想の元に、リソース間の関係にビジネスルールの制約を課す。
この手法によってER図が生まれる。
羽生さんの本(楽々ERDレッスン (CodeZine BOOKS))、渡辺さんの本(業務別データベース設計のためのデータモデリング入門, 業務システムモデリング練習帳 業務システムを効果的に設計するための精選45題)が詳しい。

OOAは、UMLという技法とセットで現れて数年前に流行した(ように思う)。
UMLにある各種のダイアグラムのうち、モデリングで最も重要な技法は、クラス図と状態遷移図だと思う。

ビジネス分析において、OOAもDOAと同じようにエンティティをまず洗い出すのが重要。
そのエンティティは概念モデルに現れて、その概念モデルはクラス図で表現する。

概念モデルはER図のように、クラス同士の関連に動詞を書き込んで、トランザクションを表現する。
つまり、DOAにおけるリソースとイベントが自然に現れる。
児玉さん(UMLモデリングの本質)は、リソースとイベントの関係を「もの-こと-もの」パターンと呼んでいた。

状態遷移図は、概念モデルで現れた一つのオブジェクトに注目し、そのオブジェクトの状態の動的な遷移を表現する。
仕様を理解できているかどうかは、状態遷移図を正確に書けているか、にかかっているように思う。

例えば、小売Webシステムならば、商品は販売中・カート・注文中・配送中・在庫無しなど色んな状態が各タイミングで変わる。
特に、排他制御が絡んだ在庫チェック、注文取消しの業務がとても難しい。

又、組込システムならば、缶ジュースの自動販売機の状態遷移の例が情報処理試験に良く出てくる。
自動販売機の状態も、販売中・販売完了など色々あるけれど、「缶ジュースが詰まってボタンが押せない」とか「在庫切れで販売できない」など色んなパターンも考えると、どんどん複雑になる。

モデリングが難しいのは、二つあると思う。
一つは、エンティティを洗い出すのが難しいこと。
例えば、概念モデルに現れたエンティティで漏れがない、という事を説明するのは難しい。

また、ビジネスルールを理解し切れていないと、エンティティを最初からすぐに導き出せない。
だから、羽生さんの本(楽々ERDレッスン (CodeZine BOOKS))では、最初はトランザクションに注目し、そこからエンティティを洗い出す手法を勧めている。
このやり方が最も自然なように思う。

更に、エンティティをクラスから型(Type)へ抽象化するのが難しい。
アナリシスパターン―再利用可能なオブジェクトモデルは、その構造を知識レベル・操作レベルと呼んでいるが、これを理解するのは至難の技。
児玉さんの本(UMLモデリングの本質)で僕はようやく理解できるようになった。

このやり方は、ビジネスモデリングで最も重要な手法の一つだと思う。
抽象化することによって、新たなビジネスパターンが得られるし、ビジネスで最も重要な概念が何か、が分かるからだ。
例えば、児玉さんの本(UMLモデリングの本質)では、会計システムにおける勘定パターンは物流システムの在庫パターンにも使える、と指摘している。

二つ目は、エンティティ同士の関連にどこまでビジネスルールを反映できているか、すぐに分かりづらいこと。
そこで、クラス図はあくまでも抽象的な図なので、実際に検証する時は、インスタンスの関係を書いたオブジェクト図を使えばよい。
児玉さん(UMLモデリングの本質)はクラス図の検証はオブジェクト図を使うことを推奨している。

また、児玉さん(UMLモデリングの本質)は「揺さぶり」という手法で概念モデルを洗練させる手法を提案している。
つまり、概念モデルに対し、ビジネスルールが反映されているかという観点で概念モデルを揺さぶってみる、ということ。
この辺りは児玉さんの本に詳しく、モデリングで最も面白い部分。

こう書いてきて、やっぱりOOAは児玉さんの本、DOAは渡辺さんの本が一番分かりやすいと思う。
平鍋さんは、渡辺さんの本(業務別データベース設計のためのデータモデリング入門など)を「日本人が書いたアナパタ」と呼んでいた。

オブジェクト納涼祭の感想: プログラマの思索

モデリングはプログラミングに比べると歴史も浅く、その手法も統一されてない。
モデリングの一番の弱点は、プログラミングと異なり、モデルだけではシステムが動かないこと。
だから、モデルの検証作業が難しい点が弱点であるように思う。

モデリング主義者が一番やりたいのは、モデル駆動開発(MDA)。
モデルを書いたら、そのモデルから動くプログラムを自動生成する手法。
でも、MDAは未だ完成していないし、そもそも本当にMDAが実現できるのか、誰も知らない。