有关授权后的用例如何表达?
　

---

如果在一个系统中,拥护A拥有a权限,但是B用户没有该权限进行a操作.但是在系统中,A可能对B用户对a操作进行授权,这样B用户也可以进行a操作,请问这样的例子该如何用用例表达呢?

 我觉得这个关系用Use case不能直接表示。因为一直以来：
　

---

Use case 的缺点就是无法表示连接关系。

这里B的a操作必须以A的受权操作未前提， 这种连接关系是无法用一个Use case表示的。

个人觉得UML的目的是用各种类型的图，分别表示问题的各个方面， 它并没有希望用一个图表示出一个（稍微复杂一些的）问题的所有内容。

所以这个问题可以用Use case简单表示A和B都有a操作， 然后用Activity 和 state 图来表示关系。
　

 回复: 有关授权后的用例如何表达?
　

---

以我理解如下：
还是Actor 的问题，Actor的定义是具有相同属性和操作的群集，即是在设计中，可转为类。
用户是一个具体的对象。
Actor colA 拥有两个用例一个是a操作，一个授权。
对于如何授权，即是活动图，交互图描述。

这个Actor问题上次已对geyun说过，注意方法。

 Actor在设计中可转为类? 我想是说具体的Actors能在设计中合并。但是这里问题的
　

---

A & B如果在一个Use case图中表示， 不应合并成一类。 因为A和B拥有不同的Use Case， 即不同的操作: A拥有“受权其他用户”这一操作， 而B没有。


Use case diagram可以参考这个：
http://umlchina.smiling.com/group/photo/photoshow.ecgi?photo_id=821674&group_id=9986

至于，然后是用activity diagram 或者 sequence diagram 还是state chart 来表示受权关系？其实就决定了具体的设计方案：

比如用这张state chart, 表示Actor A的某个Operation会改变B的状态，对应于B, 他必须拥有一个field/column 来存储自己的状态（对应的class diagram应该心中有数了）:
http://umlchina.smiling.com/group/photo/photoshow.ecgi?photo_id=821642&group_id=9986

但是假如您用下面这个activity diagram 和 sequence diagram表示，可能的实现 －－ 用一个单独的table来存储所有已经被受权用户的ID：
http://umlchina.smiling.com/group/photo/photoshow.ecgi?photo_id=821646&group_id=9986
http://umlchina.smiling.com/group/photo/photoshow.ecgi?photo_id=821672&group_id=9986

 举个例子吧，就如这个网站。。。
　

---

角色：管理员和会员

管理员：
1.可以授权会员权限。
2.可以。。。。。

会员：
1.可以发表文章。
2.可以。。。

设计时，你可以把管理员继承会员,并会扩展了管理操作；
也可以把管理员和会员分开。
熊掌和鱼，任君选择。没有必然，只有习惯。

还是老一句，把问题建在自已熟悉的模型上，事半功倍。但不反对学习别人的模型。

 请看spide的帖子：继承关系不必要在use case图中表示：
　

---

把A和B用继承关系实现还是分别两个“类”，不用在use case中表现，应该在其他图中表现。

另外正如您在上面帖子说的“Actor的定义是具有相同属性和操作的群集”， 这里A和B具有不同的“操作”，虽然某一个操作"a"是在某种条件下相同, 但是授权(authorization)这个操作对于B来说完全不存在，所以A和B不能合并。

就算以后您在实现的时候把A从B(这个更一般的用户类型)中继承，然后派生出A，他有一个独有的操作－－授权，这个关系没有必要也不可能在use case 中表现，但是use case图是最贴近用户业务概念的图，它不能太抽象，所以它必须区分A和B.

除非您理解的是authentication -- 每个用户进入系统的“认证”，那么任何Actor都有这个过程，A和B可以合并，但是这里不是讲“认证”而是“授权”