请教关于泛化的问题.txt

一些关于UML的经典讨论

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

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

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

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

对于这个小系统来说,将几个抽象层放在一张图中是可以接受的
 
 04/06/24 16:16 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 lenyu   能给我一个示例吗？
　
--------------------------------------------------------------------------------
 
下午上班去了，现在才看到回贴，这番话让我明白了不少模模糊糊的地方，感觉自己对UML图的理解有了质的飞跃，真的很感谢：）。 
但我还是不知道该怎么去实现，比如System User层看到的图该是什么样的？System User是第二层Actor的泛化吗？几个抽象层怎么放在一张图中？希望您能给我一个例子，谢谢啦
 
 04/06/24 19:16 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 smilemac  是，后者是前者的泛化。
　
--------------------------------------------------------------------------------
 
 04/06/24 19:41 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 lenyu   修正后的图，请再看看
　
--------------------------------------------------------------------------------
 
http://umlchina.smiling.com/group/photo/photoshow.ecgi?photo_id=918040&group_id=9986
 
 04/06/25 00:37 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 sealw  对OO系统抽象分层研究得比较多的是HOORA
　
--------------------------------------------------------------------------------
 
www.hoora.org 你有兴趣的话可以进一步研究一下 
我前面给出的见议主要受了这一派思想的影响 

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

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

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

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

实现用例则考虑系统内的子系统边界.
 
 04/06/25 10:05 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 浪子建  不是泛化关系。两者都是具体形式。泛化是对具体的抽象，泛化是不能实例化的。
　
--------------------------------------------------------------------------------
 
 04/06/25 10:06 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 lenyu  呵呵，这回真的懂了，看来我的新图把这三层搞混啦
　
--------------------------------------------------------------------------------
 
 04/06/25 11:38 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 smilemac  人物类别关系基本对了，其他部分没有细看。更简洁的表达是将SysAdmin看作是NormalSysAdmin的一个specialization.
　
--------------------------------------------------------------------------------
 
 04/06/25 13:58 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 lenyu  呵呵，我又迷糊了，请看。。。
　
--------------------------------------------------------------------------------
 
http://upload.smiling.com/file/178676/qzj.doc
 
 04/06/25 20:31 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 浪子建  感觉两个图都不准确。
　
--------------------------------------------------------------------------------
 
摇奖活动的机构、参与摇奖的发票种类和范围、摇奖规则的定义者与发票数据进行统计和抽奖主持人员都是具体的执行者，没有泛化关系。
 
 04/06/28 10:17 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 浪子建  回复: 感觉两个图都不准确。
　
--------------------------------------------------------------------------------
 
对于UseCase的泛化是个很特别的事，因为UseCase毕竟是只是行为描述。虽然在具体实现上可以将UseCase以类的形式实现，但是明显在分析设计中这样是不规范的，而且很容易引起错误和混淆。我觉得一般都是可以通过扩展和包含关系实现，似乎更好。 
对于执行者，泛化或是抽象是常用的。我只是认为任何具体存在的实体一定可以通过例化实现的。因此，具体存在的实体一定不是一个泛化的或是抽象的类。举个例子，在公司组织结构设计中，一般设计会是： 
class 雇员 
{ 
..} 

class 经理 extends 雇员 
{ 
..} 

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

class 普通员工 extends 雇员 
{ 
..} 
class 经理 extends 雇员 
{ 
..} 
 
 04/06/30 09:50 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 junrongshen  回复: 泛化是指存在一种"is-a"关系
　
--------------------------------------------------------------------------------
 
maybe 
泛化(Generalization)是is a kind of的关系 
而 
分类（Classification)是is a 的关系 
所以，正方形is a kind of矩形 
而 
矩形A is a 矩形 
呵呵；）