立見です。
Tsutomu>こんにちは、永和システムマネジメントの安井です。
はじめまして安井さん。コメントありがとうございます。
Tsutomu> 立見さん、作品公開一番手ですね。ありがとうございます。
目立とうと思って。
皆さんのモデルは、ユースケースからでした。いきなりクラス図にしたのがいけなかったかなぁ。
DFDでも書いてみるかなぁ。UMLでないと突っ込みをいれないで。
Tsutomu> モデル拝見しました。「運用」と「費用」をインターフェースと
Tsutomu> して抽出してるところが、スマートですね。多重度がきちんと入っ
Tsutomu> ているところもいいと思います。
いえいえ、まだまだです。
Tsutomu>
Tsutomu> いっぽう、気になるところもありました。
Tsutomu>
Tsutomu> ・「機能」と「機能構成」が1対多になっています。「機能構成」
Tsutomu> のサブクラスである「ハードウェア」の具体例(オブジェクト)とし
Tsutomu> て、たとえばデータベースサーバーが考えられます。データベース
Tsutomu> サーバーは、1台でいくつもの機能が利用します。このような場合
Tsutomu> を考えると、「機能」と「機能構成」は多対多にするほうが自然で
Tsutomu> はないでしょうか。
そうですね。間違えました。
多重度を書くのは苦手でしたが、
かならず、自分は1、相手はいくつ?で考えて、
その逆から、自分は1、相手はいくつ?
と考えれば多対多は間違えないですよね。
(思いっきり間違えましたが、笑)
自分は多と考え始めると、はまりますねぇ。
皆さんご活用ください。そんなの知ってるかぁ!
Tsutomu>
Tsutomu> ・疑問としてあげられていますが、「カテゴリ」と「サブシステ
Tsutomu> ム」と「機能」の関係が不明瞭です。具体例を考えてみたいと思い
Tsutomu> ます。
Tsutomu>
Tsutomu> 業務:
Tsutomu> 出勤・退勤時刻を記録する
Tsutomu> 営業日報をつける
Tsutomu> 営業案件を管理する
Tsutomu> 研究論文を読む
Tsutomu> 関連する研究者を探して連絡する
Tsutomu>
Tsutomu> 業務のカテゴリー:
Tsutomu> 営業
Tsutomu> 研究開発
Tsutomu>
Tsutomu> 機能:
Tsutomu> 出退勤入力機能
Tsutomu> 営業日報入力機能
Tsutomu> 営業案件登録機能
Tsutomu> 研究論文検索機能
Tsutomu> 研究者検索機能
Tsutomu>
Tsutomu> サブシステム:
Tsutomu> 営業サブシステム
Tsutomu> 研究開発サブシステム
Tsutomu> 共通サブシステム
Tsutomu>
Tsutomu> 今回のお題では、上記のオブジェクトを整理できるようなモデル
Tsutomu> を想定(期待?)しています。このオブジェクトでオブジェクト図を
Tsutomu> 書いてみてはいかがでしょうか。
Tsutomu>
アドバイスありがとうございます。
まだ見切れていませんが、週末に考えてみます。