モデリングとプログラミングの観点の違い
要求開発の記事を読みながら思ったことをメモ。
#あくまでもメモ書きであり、ロジカルでない。
モデリングとプログラミングは、根底から考え方が違うと思う。
モデリングできたからと言って、プログラムがすぐにできるわけではないし、モデルだけではシステムは動かない。
でも、モデリングで分析し尽さないと、思想のないプログラムが増殖し、それらのプログラムはすぐにスパゲティになる。
モデリングとプログラミングは相互に補完する関係にある。
モデリング技法には、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が実現できるのか、誰も知らない。
| 固定リンク
「IT本」カテゴリの記事
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
- 実践した後に勉強するのがエンジニアの本来の道(2022.01.09)
- OODAループの時代は、大事なのは使命であり、目標は使命達成のための手段に過ぎない(2021.08.01)
- INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントの感想~日本に足りないのはプロダクトマネジャーだ(2021.08.01)
- CISOは経営がわかる情報セキュリティ最高責任者である(2021.08.01)
「モデリング」カテゴリの記事
- 超高速開発でアジャイル開発を実現する話に違和感がある(2022.05.06)
- 事業活動のシステム化は非差別化しない汎用ドメインや支援ドメインに注力すべき(2022.04.13)
- 「大国政治の悲劇」の感想~現代はパワーポリティクスの歴史に戻ったみたいだ(2022.03.25)
- マイクロサービスはアトミックな操作で閉じるべきシステム分割論に基づいたアーキテクチャなのか(2022.03.20)
- 諸問題を組織論に持っていくのは目的を手段化していないか(2022.02.02)
コメント