はじめまして。スギイと申します。
みつじさんの試み興味深く拝見いたしました。
パターン５まで行くと、"表現の限界に挑戦！"というような雰囲気すらうかがえ
ますね。
さて、私はあまり経験も知識もないので深いことは書けませんが
単純に考えると"処理状態"も"提案種別"も関連で持たせるのが現実的かなと思い
ますが如何でしょう？
+----------+ +----------+ +----------+
| 処理状態 |---◇| 修正提案 |◇---| 提案種別 |
+----------+ +----------+ +----------+
※面倒なのでサブクラスと多重度は省略
パターン３とほぼ同じですが、提案種別も関連とすることで、修正提案インスタ
ンス作成後に"バグ"から"改善要望"に変えることができます。
バグかと思ったら仕様だった、ってみたいなことってありますよね。きっと。
こうなると、処理状態と提案種別は"パワータイプ"っていう感じでしょうか？
あとエラソーなことを書きますが、私は明確な意図のない継承関係を好みません。
多態性とか使いたくてどうしても継承じゃなきゃダメだ、というような場合を除
いては関連で表現することが多いです。
書いていてあまり自信がないですが、変なところがあればツッコンでください。
以上、よろしくお願いします。
MITSUJI Takamasa wrote:
> みつじです。
>
> naka aki さんの話が参考になったので、
> 多重継承を使ったパターンを考えてみました。
>
>
> クラス図をまとめてご覧になりたい方はこちら
> http://blog.goo.ne.jp/tkmsm
>
>
> 【パターン5】
>
> 多重継承を使って表現。
>
> http://blogimg.goo.ne.jp/user_image/37/25/53b011c5b642071e5fd86617e841a619.jpg
>
> やってみたら出来ました。ただ、いわゆるネジや釘に相当する
> クラスが出てきてしまっているので概念モデル的にはどうかと
> 思います。
>
>
>
>
>>みつじ＠ホームページ制作です。
>>
>>モデリング道場のみなさま、ご無沙汰しております。
>>暑かった夏も終わり、台風が吹き荒れる季節になりました。
>>みなさんいかがおすごしでしょうか。
>>私といえば、「第3回モデコンはそろそろかなー？」って
>>勝手に心待ちにしながら毎日をすごさせていただいてます。
>>
>>さて、ちょっと初歩的だったり、的外れだったりする
>>質問かもしれないのですが、仕事でモデリングをしていて
>>疑問に思ったことがあるので投げかけてみます。
>>
>>ある概念を複数の側面から分類しないといけないときの
>>表記法なのですが、なんとなくスッキリ描けないような気がするのです。
>>
>>社内で使うバグトラッキングシステムのモデルを描いているのですが、
>>ユーザから報告されるバグ情報である「修正提案」を「改善要望」と
>>「バグ」に分類し、さらにそれらの「処理済」「未処理」を分類したいのですが、
>>クラス図で描こうとするとなんとなくスッキリしません。
>>
>>4つほどパターンを考えてみたのですが、どれもいまいちなような気がします。
>>状況によって使い分けるということなのかも知れませんが、
>>皆さんならどの描き方を採用するかご意見を伺いたいです。
>>
>>
>>クラス図をまとめてご覧になりたい方はこちら
>>http://blog.goo.ne.jp/tkmsm
>>
>>
>>【パターン1（不正）】
>>
>>2つの側面を両方汎化で表記する。
>>
>>http://blogimg.goo.ne.jp/user_image/57/c2/d3e63873e90f12ce9cdf70cfb5f338ab.
>>jpg
>>
>>いきなりですが、たぶん間違いと思われる表記です。
>>見た目はスッキリしているのですが、オブジェクト図が
>>描けないような気がします。
>>
>>
>>
>>【パターン2】
>>
>>段階的に汎化を使用して表記する。
>>
>>http://blogimg.goo.ne.jp/user_image/11/7b/b87907106eb79d9a017f12e9447bef45.
>>jpg
>>
>>現実を忠実に模写していて正しいと思われるのですが、
>>モデルの変更に非常に弱いと思われる表記法です。
>>分類の側面が増えるとネズミ算式にクラスが増えてしまいます。
>>
>>
>>
>>【パターン3】
>>
>>汎化と関連を使い分ける。
>>
>>http://blogimg.goo.ne.jp/user_image/5c/d2/46312bd3ef1cb376462dc342ef50182d.
>>jpg
>>
>>私としては、もっとも現実的な落しどころかなと思っている表記法です。
>>でも、概念としては別のクラスに分けたくないような気もするので
>>スッキリしません。
>>
>>
>>
>>【パターン4】
>>
>>汎化と属性を使い分ける。
>>
>>http://blogimg.goo.ne.jp/user_image/65/07/314cbc37e1bd2756d0ab6e836dd6771d.
>>jpg
>>
>>属性を使って、いわゆるフラグとして表記する方法です。
>>これもパターン3と同じレベルで完璧とは思えないです。
>>もちろんどうぜDBで実装するんだけど、DBで実装することが
>>決まってしまっているかのような表記なので
>>概念モデルでは使いたくない気がします。
>>
>>
>>
>>他にもパターンがあれば教えていただきたいです。
>>よろしくおねがいします。
>>
>
>
>
>