上手さん、どうもありがとうございます。
小黒＠制御系です。
> １ 例えば営業システムと、そのシステムの経費をカウントするシステムは性格
> がことなるので、分離した方がいいのではないでしょうか。機能についても同様
> に感じます。
> 業務の本来の目的は、例えば営業支援であり、そのシステムの経費をカウントす
> るのは、別の管理系のシステムのはずです。
そうですね。
そこは、自分も胸に引っかかっていた所なのです。
今回のモデリングの要点は、システムを構築することではなく、モデル化したものを
見て、
あれこれと、これから何某会社が作ろうとしている業務システムを思い描くところに
あると思ったのです。
そのため、少々無理があると思いながらも、このクラス図の業務クラスをみて、
経費についてなどに頭を思い描いてもらいたく、操作として描いてしまいました。
私の考え方は、ありなのか無しなのか？それすらも分からないです。
ああ、締め切りまでにモデル書き換えようか？とても迷います。
> ２ オブジェクト図（ソフトウェア）では、運用とソフトウェアがつながってい
> たようですが、クラス図ではパッケージソフトとつながっています。
> 観点２からこうなっているようですが、これですと、開発したソフトには運用が
> なくなってしまいます。
全くその通りだと思います。
自分でも、朝、出社してから気づいて、お昼休みに手元のファイルは直しました。
> ３ 運用が運用担当者をコンポジットで持つのも強すぎませんか。その運用の
> 専任担当者の意味でしょうが、これでも、実際の人と選任担当者の割り付けが
> いずれ必要になりそうですから、当面、単純な関連位でどうでしょうか。
これも、１に似た話なのですが、「運用にモレがないように、業務システムの図を
チェックできるように」との観点から、コンポジットにしてしまいました。
クラス図として、というよりは、クラス図を読む人間に注意して欲しくて、やった
という感じです。
これも、モデリングではありなのか、無しなのか？、、、。
自分は悩んでしまいます。
↓修正は入れていませんが、、、。
> > http://homepage2.nifty.com/anpanman/sakusaku/1_1.htm
> >