请教关于泛化的问题，在线等
　

---

系统管理员（系统中最高级管理员）和系统维护员（系统中其他各级机构的管理员）之间是泛化关系吗？如果是，那么谁是谁的泛化呢？

比如说: 矩形 is a 多边形. 正方形 is a 矩形.

就你的问题来说, 可以认为这两种系统管理员不存在 is-a 关系,他们基本上是权限的不同

 回复: 泛化是指存在一种"is-a"关系
　

---

谢谢啦：）
再请教一下<>和<>、refine的关系。比如系统管理员和系统维护员都用到一个叫做“系统管理”的用况，“系统管理”包含“机构设置”、“用户管理”、“统计规则设置”等子用况，其中系统管理员可以使用所有子用况，系统维护员只能使用“用户管理”和“统计规则设置”，该如何正确表示系统管理员、系统维护员、“系统管理”用况和各子用况之间的关系呢？

系统管理员 ->“系统管理”
“系统管理”includes“机构设置”、“用户管理”、“统计规则设置”

系统维护员 -> “用户管理”
系统维护员 -> “统计规则设置”

 回复: 这样做有点像是功能分解,我个人不是很赞成,硬要这样的话...
　

---

您的意思是指“机构设置”、“用户管理”、“统计规则设置”不算真正的用况吗？

我的意思是说,系统管理员在做这些操作时,并不是真正出自他自己的需要.而是在发生了某些业务事件之后,领导或人事部门要求他做这些操作.

以"机构设置"为例,这是一个系统级use case,在这之上,还应该有业务级的use case. 例如,"系统部署" includes "机构设置", "机构重组"要求"机构设置"

"新进员工"和"员工离职" _业务级_ 事件将会导致"用户管理" _系统级_ 用例

换句话说,系统管理员这个actor并不是真正具有自由意志的.他受到一些业务事件的驱使.

如果我来分析系统,会把系统管理员的操作背后的业务级用例列出来.

 麻烦您看看这个图，多多指教
　

---

http://umlchina.smiling.com/group/photo/photoshow.ecgi?photo_id=917919&group_id=9986

税务发票摇奖包括以下业务内容：
1、税务征管部门事先确定参与摇奖活动的机构、参与摇奖的发票种类和范围、摇奖规则等事宜并组织人员分头筹备。每级税务机构都只有一个征管部门，其权力范围是本级税务机构和辖区内的下级税务机构。
2、活动前由专人采集参与摇奖发票的详细信息，包括发票类别、号码、面额等；采集过程中如果发生错误，允许采集人员进行更正；采集人员由本级或者上级税务征管部门确定，可以是一个或者多个，均有权采集本级和下级机构的数据。
3、摇奖通常是在公共场合公开举行的。活动开始前先登录进入摇奖主界面，经公证人公证、主持人宣布开始摇奖之后，由主持人或者特别嘉宾敲一下键盘，即开始摇奖。
4、摇奖的具体形式归纳起来有下列几种：
A、对某一个税务机关某一时期辖区内所有已经用出的发票进行摇奖；
B、对某一个税务机关某一时期辖区内已经用出的特定种类的发票进行摇奖；
C、把某几个税务机关某一时期辖区内所有已经用出的发票合在一起进行摇奖；
D、把某几个税务机关某一时期辖区内已经用出的特定种类的发票合在一起进行摇奖；
E、对某一个税务机关某一时期辖区内已经摇中奖的发票进行二次或者多次摇奖；
F、对某一个税务机关某一时期辖区内已经摇中奖的特定种类的发票进行二次或者多次摇奖；
G、对某几个税务机关某一时期辖区内已经摇中奖的发票合在一起进行二次或者多次摇奖；
H、对某几个税务机关某一时期辖区内已经摇中奖的特定种类的发票进行二次或者多次摇奖。
5、每次活动一般都会摇出数个奖金类别，每个类别若干个中奖发票号码；根据需要，奖金类别可以是顺序（由高到低）出现，也可以是逆序（由低到高）；如果有特别奖（或者特等奖），可以单独指定它最先或者最后出现。
6、奖金额可以按类别指定，也可以按一定规则滚动累计。
7、每次摇奖活动前后，一般都需要由专人按要求对本级和下级税务机构参与摇奖的发票数据进行统计，并打印报表。
8、公众（含纳税人和消费者）可以通过税务网站的特定链接登录并查询发票数据、摇奖结果和统计数据。

由上述业务内容提取出《税务发票通用摇奖系统》的业务用况（Business Case）分析结果：
1、系统的涉众（Stakeholder）和角色（Actor）。征管部门、信息采集（录入）员、摇奖人、统计员、公众是业务中明显包含的涉众，按照业务内容的描述，不难确定其关系：
l 征管部门负责系统相关信息和规则的设定、人员授权，相当于系统管理员（系统中最高级税务机构）或者系统维护员（系统中其他各级税务机构）。
l 只要得到系统管理员或者本级以上（含本级）系统维护员授权，任何工作人员都可以担任本级的录入员、摇奖人或者统计员。
l 系统管理员可以兼任系统的摇奖人和统计员，系统维护员可以兼任本级的摇奖人和统计员。为简单起见，规定系统管理员即为系统的摇奖人和统计员，系统维护员即为本级的摇奖人和统计员。
l 公众是特殊的涉众，只有查询发票数据、摇奖结果和统计数据的权利。
另外，系统还需要与外部系统（包括其它税务机构使用的《税务发票通用摇奖系统》和其它税收业务软件，例如发票管理软件）交换数据，因而可确定系统包含的角色是系统管理员（Admin）、系统维护员（Vindicator）、录入员（Importer）、公众（People）和外部系统（ExtSystem）。
　

 请问这个系统中Admin、Vindicator和People的关系怎么表示才正确？
　

---

我也知道我的图中Admin和Vindicator看起来完全一样；People好象很多余。但实际上并不是这样的，关键是不知道如何在图中正确体现他们的关系。

图的目的是为了让人能一目了然, 对系统有个基本的了解, 所以不能让读者一看之下存在两个大大的问号.有些小问号是可以的,但那应该是由于图在细节方面的表现能力不够而引起的.

名字首先要取对.当我看到People时,无论如何也不知道那就是指的"彩民",何不就称之为"彩民"?

这样的话,可以分出这些Actor: System User, Lottery buyer, Admistrator, Super Administrator, Normal Administrator

这些Actor之间存在三个抽象层次,System User使用待开发系统,是最高一层抽象;
Lottery buyer和Administrator处在第二层抽象, 分别做查询数据和系统维护,Administrator是否也能查询数据视需求而定,因为在某些系统中,Administrator也不能访问某些核心业务数据的;
Super Admin和Normal Admin处在第三抽象层, 对系统维护的任务进一步细化

站在不同的抽象层上看系统的功能,看到的结果是不一样的.如果把角色的泛化与功能的泛化对应起来,整个图看起来就好懂一些

对于这个小系统来说,将几个抽象层放在一张图中是可以接受的

 能给我一个示例吗？
　

---

下午上班去了，现在才看到回贴，这番话让我明白了不少模模糊糊的地方，感觉自己对UML图的理解有了质的飞跃，真的很感谢：）。
但我还是不知道该怎么去实现，比如System User层看到的图该是什么样的？System User是第二层Actor的泛化吗？几个抽象层怎么放在一张图中？希望您能给我一个例子，谢谢啦

 修正后的图，请再看看
　

---

http://umlchina.smiling.com/group/photo/photoshow.ecgi?photo_id=918040&group_id=9986

www.hoora.org 你有兴趣的话可以进一步研究一下
我前面给出的见议主要受了这一派思想的影响

对于怎样画/写好use case,建议阅读<编写有效用例>, <有效用例模式>以及<掌握需求过程>的第4章

一般在处理use case的抽象分层时,会用另一种方式考虑, 分成业务用例,系统用例和实现用例三层.

业务用例是针对组织/公司的客户和外部组织而言的.对于一个"体彩中心"而言,他的客户是彩民,外部组织可能是上级单位.当我们把"体彩中心"作为对象研究时,分析进出体彩中心的数据流,从而得出与体彩中心有关的外部实体,比如说彩民和上级主管单位.在这个层面上还看不到Administrator,那是在组织边界面的东西.

系统用例讨论的是系统边界,分析哪些人可以直接操作系统,这时会有Admin出现.所以有的文献上将"彩民"这样的actor称为business actor,而将admin称为business worker.

实现用例则考虑系统内的子系统边界.

http://upload.smiling.com/file/178676/qzj.doc

摇奖活动的机构、参与摇奖的发票种类和范围、摇奖规则的定义者与发票数据进行统计和抽奖主持人员都是具体的执行者，没有泛化关系。

对于UseCase的泛化是个很特别的事，因为UseCase毕竟是只是行为描述。虽然在具体实现上可以将UseCase以类的形式实现，但是明显在分析设计中这样是不规范的，而且很容易引起错误和混淆。我觉得一般都是可以通过扩展和包含关系实现，似乎更好。
对于执行者，泛化或是抽象是常用的。我只是认为任何具体存在的实体一定可以通过例化实现的。因此，具体存在的实体一定不是一个泛化的或是抽象的类。举个例子，在公司组织结构设计中，一般设计会是：
class 雇员
{
..}

class 经理 extends 雇员
{
..}

但是更稳定的设计应该是：
abstract class 雇员
{
..}

class 普通员工 extends 雇员
{
..}
class 经理 extends 雇员
{
..}

maybe
泛化(Generalization)是is a kind of的关系
而
分类（Classification)是is a 的关系
所以，正方形is a kind of矩形
而
矩形A is a 矩形
呵呵；）