Index: [Article Count Order] [Thread]

Date:  13 Sep 2005 18:05:46 +0900
From:  "y-kamite" <y-kamite@....jp>
Subject:  [modeling-dojo:00465] Re: 複数の側面から分類したいとき
To:  modeling-dojo@....jp
Message-Id:  <20050913173414.F4CA.Y-KAMITE@....jp>
In-Reply-To:  <30C5B52F1D8C46mitsuji@....jp>
References:  <30C5B52F1D8C46mitsuji@....jp>
X-Mail-Count: 00465

みつじさん、今日は上手@DTSです。
よろしくお願いします。
#ちょっとバタバタしていて出遅れました。

> みつじ@ホームページ制作です。

@ホームページ制作、ということですので、
以下の要件は、社内ユーザから出ているのかな? と思ってコメントします。
#要件を出す顧客との距離が近いという意味です。

<コメント1:本題>
修正提案と、改善要望/バグは、クラス−ロール関連の定石が使えるのかなと感
じました。
処理状態はどう表現したらいいのでしょうか??
状態クラスとの関連で問題ないような気もします。

<コメント2:拡張>
私の所属している組織は、いわゆるSI業なので、顧客との距離が遠いです。
そこでは、上のような事例は以下のような形で処理されるのが普通と思います。

保守フェーズにはいっているシステムとします。
1 顧客からの要望(修正依頼票):保守窓口に直接連絡
2 切り分け->バグ OR 仕様変更(修正依頼):開発部門依頼?
3 バグなら
  瑕疵期間内(バグは無償対応):
   開発部門に修正工数確認、顧客に回答。修正作業にはいる。
  瑕疵期間終了:
   開発部門に修正工数確認、顧客に回答。営業に処理依頼。
4 仕様変更ならその旨顧客に回答。
5 バグ:瑕疵期間内以外は、営業担当が処理方針を決定、保守・開発部門に指
示を出す。(作業内容と代金請求方針)

そこで提案なのですが、みつじさんの事例を一般的なものに拡張して、モデリン
グを検討してみませんか?
#上のものはあくまでも例なので、どなたかがまとめていただければと思ってい
ます。

(では)

> モデリング道場のみなさま、ご無沙汰しております。
> 暑かった夏も終わり、台風が吹き荒れる季節になりました。
> みなさんいかがおすごしでしょうか。
> 私といえば、「第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で実装することが
> 決まってしまっているかのような表記なので
> 概念モデルでは使いたくない気がします。
> 
> 
> 
> 他にもパターンがあれば教えていただきたいです。
> よろしくおねがいします。
> 
> 
> 

---------------------------------------------------
上手裕 y-kamite@....jp y-kamite@....jp
---------------------------------------------------