BETA

知識レベルと操作レベルをざっくり

投稿日:2020-05-23
最終更新:2020-05-23

概要

  • 概念モデリングの基本的な技術「知識レベル」と「操作レベル」をざっくりまとめる

例: 書籍検索

本の検索機能を作る事を考えます。今のところ「カテゴリ」と「ジャンル」という分類軸があるとします。すると、次のようなベン図が書けます。

とりあえずはこれで良いのですが、このようにシステムを構築すると新しい分類軸(価格帯、刊行年など)が増えた場合、その都度オブジェクト型を追加する必要があります。

そこで、次のように「分類型」と「分類」というオブジェクト型にそれぞれを配置しなおしてみます。

もともと、「型名(カテゴリなど)」と「オブジェクト(雑誌・漫画など)」で構成されていたものを、それぞれ「分類型」と「分類」というオブジェクト型のエンティティに定義し直し、リンクで結ぶことで表現しています。

こうすることで、将来新しい分類軸が追加された場合も、「分類型」と「分類」にオブジェクトを追加することで対応できます。

知識レベルと操作レベル

定義は次のように示されています(アナリシスパターン p.25)

  • 操作レベル
    • 問題領域での日々のできごとを記録する
  • 知識レベル
    • この構造を支配する一般的ルールを記録する

概念モデリングは実装技術によらないため、 列挙型で実装するか、DBにマスタデータをもたせて管理させるかといったことは気にしません(してはいけません)。

ここで重視されるのは、 業務の中で オブジェクトが追加されることが想定されるかです。システムの都合ではなく、使う側であるユーザーがそれを使ってどのようなことを実現したいかによってモデリングを行います。

例:図書館の蔵書管理

図書館では同じ本を複数所有することがあります。このとき、次のようにモデリングが可能です。

先の例とは異なり本(本の種類)が操作レベルから知識レベルへ移動しています。これは蔵書管理の対象が実物の本であり、本の種類は「蔵書に関するルール」として捉えたためです。

もちろん、すべての蔵書管理でこのようなモデリングをするべきというわけではなく、ユーザーがどのように使うかによってモデリングを使い分けることが必要です。

まとめ

知識レベルと操作レベルの使い分けについてざっくりと書きました。

とっつきにくい技術ですが、 ユーザーがどのようにシステムを使うか を考えれば自然と使い分けができるのではないかと思います。

参考

  • Martin Fowler (2002) アナリシスパターン: 再利用可能なオブジェクトモデル, ピアソンエデュケーション
技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

いまはモデリングについて雑多に書いてます。そのうち丁寧に書き直すかも。

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう