[jfriends-ml 11339] Re: 「 UML

[nakahara <nakahara@xxxxxxxxxxx>]

中原です。

話がずれていればすいません。

議論となっているのは経理のモデリングの話ですよね？
オブジェクト指向とは、現実世界の関係を
抽象化してソフトウェアで表そうという考えではないのでしょうか？

UMLモデリングは、現実世界のオブジェクトの関係や仕組みを、
抽象化しビジュアル化して表現することだと考えています。

両者とも、現実世界を抽象化するという事で
共通点を持っていると思います。

つまり、機械に解りやすいか否かは問題ではなく、
あくまでも対象ドメインでどのように扱われているかが
ポイントだと考えます。
「人間が今までこうしてきたから・・・」ではなく、
対象ドメインのビジネスルールをいかにモデリングするかが
重要のではないでしょうか？

ファウラー氏が簿記を知っているか否かはわかりかねますが、
上手さんの話を伺っている限り、少なくとも
ビジネスルールをモデリングしていないように思います。
# 私は簿記を知りませんので、言及できませんが。

新たな簿記の仕組みは専門家に考えていただくとして、
モデラーはビジネスルールをいかにうまくオブジェクトに
マッピングするかに専念するべきなのではないでしょうか？

議論の発端はファウラー氏のアナリシスパターン（分析パターン）
ですよね？

以上、宜しくお願い申し上げます。


> > 経理の世界でどうであろうと，そんなものは人間が扱うための
> > ルールにすぎません．所詮は昔のルール．機械が扱うためのルール
> > とは無関係で，考慮するに値しません．
> 
> 概念レベルのモデルは、顧客側と開発側の間で開発する対象物の
> 要件を合意するためのものなので、機械が扱うためのルールでは
> ないと考えます。間違ったものを作らないために、顧客側と開発
> 側とで合意を形成するためのモデルと考えています。
> ここは、ドメイン（経理システムなら経理ドメイン）の専門家が
> 正しさを検証できるかどうかが焦点となるはずです。
> ＃ よって計算機が扱うことは考慮するに値しません
> 
> 分析レベルのモデルは、扱い方が難しいです。概念レベルのモデル
> は、そのままではとても計算機上で表現できる代物ではないので、
> 何らかの変換（変換では語弊があるかもしれません）が必要になり
> ます。概念モデルからいきなり実装モデルへ変換できれば分析
> モデルは不要です。ですが、それではギャップが大きすぎるので、
> 分析というある種の中間状態を経るようにしていると思います。
> 
> 実装レベルのモデルは、そのままずばり機械が扱うためのルール
> ですね。極論ですが、実装レベルのモデルも、概念レベルのモデル
> から直接コードに変換できるなら不要かもしれません。
> 
> 
> ---
> TAKAHASHI Toru

***********************************
中原　慶 
nakahara <nakahara@xxxxxxxxxxx>
***********************************