スレッドメモ

◆ [oosquare-ml] 概念モデルに責務を書いても良いですか？

[03738] Tacchang (10/7)

この本の90〜91ページあたりに
『概念モデルには，責務またはメソッドが適さない』
『責務はほとんどの場合，ソフトウェアの実態と関係し，メソッドは常にソフトウェアの実態と関係しています・・・』
とあります。

しかし，私は概念モデルをクラス図で表す限り責務を定義すべきだと考えています。理由は以下の通りです。
１．クラス図ではクラス間の関連を記述するが，これは他者に対してどのような責務があるかを記すものである。概念（クラス）の責務（その概念が何をするものか）がなければ関連を引くことはできない。
２．クラス名と属性だけでは概念を一義的に定義できない
３．ソフトウェア設計の前に，その概念が何をする者か定義することは可能。もしくはしておいた方がよい。

[03739] Kiminobu Kodama (10/7)

概念レベルのモデルでは「概念」を書くことに専心して，なるべく実装から離れるのがいいと思います。Fowlerは概念レベルでは「型」の構造を書くと（アナパタ）で言っています。

ですから，UMLのクラス図の記法を使って，「型」をクラスシンボルで，属性をデータで，操作をメソッドで仮に表します。実装では現れない多重分類や動的分類も書きます。

[03740] Yoshihiko Yamada (10/7)

要は2つの考え方があるのではないでしょうか。

責務を分析段階で考えるのは CRC カードを使う考え方にみられます。

一方ラーマンは
「レシートは ...モデルの中で提示すべきでしょうか」と問題を提示し、「一般にはレポートに関する情報を概念モデルに提示することは有用ではありません。レポートの情報はすべて、他の情報源からもたらされるからです」
と指摘しています。

ラーマンは概念モデルはソフトウェアのモデルではなく、ドメインのモデルだ、と主張し、「ウィンドウやデータベースのようなソフトウェアの成果物」は概念モデルに含めるべきではない、と主張しています。

そのため、メソッドや責務の分割は概念モデルの段階ではできません。概念モデルの作成の後に、ユースケースからシステムシークエンス図を描き、システム全体としてのメソッド抽出します。

[03750] Tacchang (10/8)

ただ残念なのは，なぜ，クレーグ・ラーマン氏が「概念（モデル）に責務を持つべきでない」「責務はソフトウェアの成果物(*1)」と主張されているのか，私が未だにその理由を理解できないことです。「実践UML」のような中身の厚い本を書かれる方の考えには，それなりの根拠があると思うのです。それを是非知りたい（感じ取りたい）。

[03751] Hidehiko AKASAKA (10/8)

でも概念モデルのメリットってなんだと思いますか？

私は(詳細な設計モデルと比べて)単純なモデルで(問題領域を)理解しやすいことだと思います。また、責務分担することが主目的ではないと思います。

その図が責務を表現することにより、複雑で理解しにくくなるのでしたら、表現したくないということです。

[03756] hiroki kugimoto (10/14)

私の個人的な感想では、「責務」を考えると既にそれは概念モデルといえないのではないかと思います。設計モデルと呼んだほうが適当ではないのか、と。

[03763] 児玉公信 (10/14)

で，最初の問いですが，概念レベルでは概念間の構造を記述するので，概念の境界を定めることが重要になります。そのために責務（操作）の配置を行うことが有用です。しかし，それはそのままメソッドとして実装されることを必ずしも想定しないのです。それは，「型」の実装もそうだし，属性も同じです。そのまま実装されることを想定しないのです。