@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
利用者の個人情報を扱うシステムの概念モデルについて
1
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2005-07-21 12:30
はじめまして、FallenSun と申します。
標題の件についてみなさまの意見をお聞かせください。 現在、利用者の個人情報を扱うシステム(会員制の コミュニティサイトや勤怠管理システムなどをイメージしてください。) の概念モデルを作成しています。 概念モデルのうち、クラス図では、利用者自身が管理対象なので、 利用者をクラスとして表現したいと考えています。 また一方で、利用者はユースケース図のアクターとしています。 UML関連の書籍などを読むと、通常アクターはクラスに含めないと 書いてありますが、その理由はアクターはユースケース図で システム境界の外側に書くものだからですよね? 利用者の個人情報を扱うシステムの場合、 アクターがシステム境界の内側に含まれる事になると思うのですが、 そのようなユースケース図をこれまで見たことがありません。 この場合、管理対象である利用者をアクターとして表現する のがそもそも間違っているのでしょうか? しかし、そうだとすると何をアクターとすれば良いのか分かりません。 漠然とした内容で恐縮ですが、みなさまはこのようなケースで どのように概念モデルを作成されているのか 教えていただけないでしょうか?よろしくお願いいたします。 | ||||
|
投稿日時: 2005-07-21 13:11
ユースケース図で書いている利用者とクラス図の利用者は別物として考えれば良いのではないでしょうか。
ユースケース図の方は実際に存在するシステム外の利用者ですよね。 クラス図の方はシステムで扱われる"利用者"という概念と考えれば良いでしょう。 仮に、勤怠を入力する"勤怠入力係"の人がいて、入力する場合はその人にお願いするという仕組みに変更したと考えてみれば違いがはっきりしませんか。 そうしたからって勤怠を管理される、クラス図上の"利用者"という概念はなくならないでしょ? [ メッセージ編集済み 編集者: 一郎 編集日時 2005-07-21 13:12 ] | ||||
|
投稿日時: 2005-07-21 14:26
って考えるから混乱するのではないでしょうか? システムで管理するのは「利用者」という人そのものではなくて、利用者 の識別情報なり、入力情報ですよ。(まぎらわしいですが) ですから、ユースケースでシステム内にアクターとしての「利用者」が入る ことはありません。 境界内には「認証する」や「勤怠(を入力する)」等をケースとして書くの ではないでしょうか? [ メッセージ編集済み 編集者: Beatle 編集日時 2005-07-21 14:27 ] | ||||
|
投稿日時: 2005-07-21 14:31
両方とも同じ「利用者」という名前を使っているせいで
わかりにくくなっているのだと思います。ここは扱われるものに 「個人情報」という名前をつけて アクター「利用者」はモデル「(利用者自身の)個人情報」にアクセスする アクター「入力係」はモデル「(登録された全ての)個人情報」にアクセスする と考えれば、利用者がシステム境界の内側にくることはないと思います。 | ||||
|
投稿日時: 2005-07-21 17:28
一郎さん、Beatleさん、vincentさん、
ご教示ありがとうございました。 なるほど、私は実体としての利用者とロールとしての利用者を きちんと区別できていなかった為に、 システム境界内にアクターが入ると考えてしまったという事ですね。 確かに、実体としての利用者(アクター)がシステム境界内に 入るわけはないです。 混乱してしまった原因として、両方とも同じ「利用者」という名前を 使ってしまったことの他に、オブジェクト図で利用者クラスの インスタンス名に氏名を使っていたことも大きかったと思います。 そのせいで、ロールとしての利用者に対して実体を連想して しまっていました。これも○○太郎ではなく FallenSun というように 役名を使って表しておくと混乱しなくてすみますね。 とても勉強になりました。どうもありがとうございました! |
1