@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

権限をクラス図で表現

1
投稿者投稿内容
こま
会議室デビュー日: 2005/07/15
投稿数: 3
投稿日時: 2005-07-15 12:31
初めまして,こまと申します
UMLのクラス図で分からないことがありまして質問させて頂きます

現在,自社のソフトの開発でのたたき台となるユースケースやクラス図を書くように
言われましてUMLの勉強を始めたのですが
開発対象ソフトのクラス図作成で手が止まってしまっております

具体的には,あるクラスに対するユーザーグループクラスの権限を表現した権限クラス
に関する関連のつけ方なのですが

この場合分析段階で
クラスA ← 権限クラス → ユーザーグループクラス
(権限クラスにはクラスA,ユーザーグループクラスを特定するID,そしてどのような権限がユーザーグループに与えられているかの情報を持つ)
のように書いて多重度はそれぞれ一対一とした所までは書けたのですが
これを設計クラス図に落とす所でどうすればよいのか分からないのです.

今は
クラスA ←◇ 権限クラス ◇→ ユーザーグループクラス
として考えているのですが,ライフサイクルを考えるとおかしい気がしますので
どなたかアドバイスお願い致します.

ほげた
ベテラン
会議室デビュー日: 2002/05/08
投稿数: 67
お住まい・勤務地: なごやん
投稿日時: 2005-07-16 01:17
引用:

こまさんの書き込み (2005-07-15 12:31) より:
のように書いて多重度はそれぞれ一対一とした所までは書けたのですが



一対一になるというのは、ユーザグループは常にあるひとつのクラスのみにしか権限を持たないということですか? であれば、ユーザグループクラスにクラスAを持たせることもありですね。
単なる誤記で、一対多関係に落とせたということだと思いますが・・・

引用:

これを設計クラス図に落とす所でどうすればよいのか分からないのです.

今は
クラスA ←◇ 権限クラス ◇→ ユーザーグループクラス
として考えているのですが,ライフサイクルを考えるとおかしい気がしますので
どなたかアドバイスお願い致します.



分析は、対象がどういう概念構造をもっているか、概念間の関係がどうなっているかということを明確にするのが目的であるのに対して、設計モデルはソフトウェアとして実現するために適切な構造としなければなりません。
分析モデルのクラス名や属性をアルファベットに変換するだけでは「設計している」ことにはなりません。

こまさんのケースでも、これらのクラスをどのように使うか、という部分をつきつめないと、適切な設計モデルを作成することは難しいですね。
例えば、シーケンスの大半が、ユーザグループが存在するところから始まって、権限を確認してクラスAにアクセスするという流れが多ければ、ユーザグループクラスに権限クラスのコレクションを保有させることが自然です。
じゃ、権限クラスは誰がインスタンス化するの? と考えると、権限クラスのライフサイクルを管理するようなファクトリが存在して、そこからユーザクラスやクラスAにアクセスするようにポリシーを定めるとか、はたまたクラスAに権限クラスのコレクションをもたせて、ユーザクラスのアクセス時に検証するとか、それならばいっそのことクラスAにユーザグループクラスのコレクションを持たせてしまうとか・・・

で、結局何が言いたいかというと、静的構造を表現するクラス図のみで設計を進めることは非常に困難です。同じ分析モデルから異なる設計モデルにたどり着くことは大いにあります。
まずは分析モデルそのままのクラス図からスタートして、ユースケースごとにシーケンス図を描いてみて、アプリケーション内で実行されるシーケンスや将来的な拡張ポイントを検討してみてはどうでしょう。その過程で、分析モデルには存在し得ないソフトウェアとして必要なクラスや、クラスがもつべき振る舞い等も明確化されます。
こま
会議室デビュー日: 2005/07/15
投稿数: 3
投稿日時: 2005-07-16 08:32
返信有り難うございます

引用:

一対一になるというのは、ユーザグループは常にあるひとつのクラスのみにしか権限を持たないということですか? であれば、ユーザグループクラスにクラスAを持たせることもありですね。
単なる誤記で、一対多関係に落とせたということだと思いますが・・・



説明不足で申し訳ございません
初めは権限について考慮せずに
ユーザークラスとクラスAを多対多の関連としていたのですが

特定のユーザークラスにのみクラスAにアクセスさせたいと考え
ユーザークラスとクラスAの関連クラスとして権限クラスを作りました
こうする事で権限クラスのインスタンスが複数存在する事で
多対多の関連を吸収し一対一の関連に落とせると考えたからです

例)
    クラスA  ユーザークラス
権限1   X      あ
権限2   X      い
権限3   Y      あ
権限4   Z      う


ほげたさんの仰るとおり
ユースケースからシーケンス図を描いてみて
どのクラスがどのようなやり取りをしていて
どのようなクラスが足りないのかをもう一度洗い出してみます
有り難うございました
ほげた
ベテラン
会議室デビュー日: 2002/05/08
投稿数: 67
お住まい・勤務地: なごやん
投稿日時: 2005-07-16 13:35
用語をちゃんと使わないと、相手に意思が伝わらなくなってしまうので老婆心ながら・・・
引用:

こまさんの書き込み (2005-07-16 08:32) より:

多対多の関連を吸収し一対一の関連に落とせると考えたからです



分解しても、一対一関係はどこにもありませんよね。

このようなケースを一般に
 クラス間の多対多関係を、関連クラスの導入によって2つの一対多関係に分解した。
と言います。
それだけ言えば、このドメインに関わる人間なら、こまさんが書いた以下のクラス図を思い浮かべるはずです。
 クラスA ←◇ 権限クラス ◇→ ユーザーグループクラス
こま
会議室デビュー日: 2005/07/15
投稿数: 3
投稿日時: 2005-07-16 18:10
引用:

ほげたさんの書き込み (2005-07-16 13:35) より:
用語をちゃんと使わないと、相手に意思が伝わらなくなってしまうので老婆心ながら・・・

分解しても、一対一関係はどこにもありませんよね。

このようなケースを一般に
 クラス間の多対多関係を、関連クラスの導入によって2つの一対多関係に分解した。
と言います。
それだけ言えば、このドメインに関わる人間なら、こまさんが書いた以下のクラス図を思い浮かべるはずです。
 クラスA ←◇ 権限クラス ◇→ ユーザーグループクラス



指摘有り難うございます
先ほど本屋でいくつかUMLの本を見てきたんですが
関連クラスでの多重度が私が参考にしていたものと違いましたので戸惑いました

私が参考にしていた本では,図と共に
引用:

「多対多」という実装が極めて複雑な構造を,「一対一」という極めて実装が容易な
構造に転化できるメリットに着目してください.
これは「関連」オブジェクト自身が複数存在する事で,多重度を吸収しているからです.



と有ったのでどの場合もそうなると思っていたのが原因です.
私のオブジェクト指向に対する考えも浅いので
少しずつ学んでいきたいと思います
1

スキルアップ/キャリアアップ(JOB@IT)