SadManです
今回は議論が活性しているようで、嬉しく思います
＞平澤さん
> とはいえ、UMLのクラス図を使ったモデリングでは、
> RDBでの正規化理論のような基準がないため、
> ある意味「何でもあり」です。
コンテストに当たって道場主の総論にも
絶対の正解はないが、絶対の悪方はあるというような事をおっしゃってましたね
何でもアリだからこそ、本質的なところで妥当性を身に付けなければ
上手に業務に活かせないんだと思います
(javaで開発してるからOOPだというような踏み外しが起きてしまう)
＞みつじさん
> そうですね。「概念モデル」「設計モデル」「実装モデル」と段階的にモデルが詳細化されていく
> 過程で、使うのに適したパターンの種類や粒度も変わっていきますね。
概念設計で分解されたものは後から統合しにくいという事だと思います
だからはっきりしない事を細かい粒度にモデリングしてしまうと後から統合しにくいので違和感を感じる
サービスの状態をstateパターンでモデル化してしまうと、状態クラスを作らざるを得ないけれど
サービスは状態を持っているとしておけば、実装モデルでそれを抽出するのは容易なんだろうと思ってます
> なんだか、実装の話ばかりになってすみません。。。
わたくしも頭が実装よりだと指摘されましたが悪いことではないと思います
自然なモデルはそのまま実装に落とせる事が多いし
現実の業務を思い浮かべる時、わたしの場合は自然と実装イメージが伴ってしまいます
例えば、「出来上がった現物をお客さんに渡す」を考える時
その時点で、「伝票を検索して完了マークのついた物を取り出し引渡し済みをチェックする」
というオペレーションを思い描いてしまいます
(マッピングではなく、お題の行動をオペレーションと言う形でイメージしてしまう
＞清野さん
わたしから見ると新鮮な意見です
言ってみれば、ほとんど真逆です
やはりひとそれぞれなのだなぁと強く感じました
非難ではなく議論として反論してみたい
> １．
> もう一つの観点として『状態』をモデリングする必要があるか？
> =>不要。
> 「業務上のイベント」を表現するクラスとして記述すべき。
> 「状態」は「イベント」の記録データから随時生成できる（する）。
>
> ２．
> 今回の概念モデルに『状態』を必要とする範囲が記述されるべきか？
> =>お題のタイミングのシチュエーションでは不要。
> 「受付業務」のみのモデルをベースに検討範囲が狭すぎないか確認し、
> その上で追加する。
>
> ３．
> 概念クラス図で「他のデータからルールで生成できるデータ」を記述すべきか否か？
> =>不要。
> ユーザが意図的に入力する以外のデータは意味の冗長性を生み、可読性が下がる。
> 代わりに、別途「生成のルール」をまとめる。（モデル上のノートや別表等）
オブジェクト指向としてモデルを考えた場合、
OOPの説明に良く出てくるようにまず現実の物体そのものをオブジェクトと考え
次に物体ではないけれどもいろいろな概念をあたかも物体のように考えてモデル化します
とすると、イベントは状態遷移を引き起こしますが状態自体はイベントではないと思います
「受け付けたという行動」が状態なのではなく、「受け付けた結果手元にある実物」が
預り品クラスのシャツインスタンスで状態は お預り/未処理 のオブジェクトなのです
というように考えます
適用範囲について
預った翌日、客が預り品を受け取りに来ましたが、実はまだクリーニングしてなかったとしたら
取りに来たから渡すというわけには行きません
お題のインタビューにあるように「受け取って洗って返す」が基本ですから
業務の行動だけでなく、状態もシステムで管理するべきなのは自明です
なぜなら、現実の業務が暗黙的に状態を把握しそれに依存して遷移するからです
他のデータからルールで生成できるデータについて
これはケースバイケースです
オブジェクトに付随する静的なデータであれば、ルールによって生成するべきではないこともあります
例えば、電力の使用状況を把握するため電源のon/offを記録するシステムがあったとして
そこにスイッチオブジェクトがあるとした場合、現在のスイッチがonかoffかは
管理履歴によって導かれるべきではなく、スイッチ自体の状態としてon/offを持つべきです
なぜなら現実のスイッチとういう物体がそういうオブジェクトだから
一言で言うと清野さんの思考方法は「オブジェクト指向」ではなく
業務指向やデータ指向であると言えるのではないでしょうか？
SadMan