ATC网友的问题：
请教一下在实际的项目中是如何真正做到迭代的?
例如,任何的需求变更,都从重新分析业务模型开始?
谢谢
解答：
首先我说明一点，并不是任何的需求变更都一定要从重新分析业务模型开始的。这是对迭代的误解，如果什么需求变更都要迭代，那么工作量根本是无法承受的，迭代也会变得无法控制，谁知道需求什么时候变更？迭代并不是因为需求变更而来的。
我们知道RUP倡导迭代的软件过程，RUP定义了四个阶段和九个核心工作流，也知道RUP是可以裁减的。先澄清一个观点，RUP中每一个迭代都可能贯穿这四个阶段和九个核心工作流，但不是一定就会。
要实现迭代的软件过程要做以下一些事：
首先，要定义软件生命周期，即根据项目实际情况和你所处组织的情况，从RUP中裁减出适合本组织和本项目的软件过程。简单说就是规划出本项目要产生哪些可交付物，而可付物决定了你要做哪些过程来产生它们。然后根据RUP定义出这些可交付物产生的流程，例如业务建模过程--->概念建模过程--->分析过程......
其次，要有里程碑计划。即将把上面定义出来的可交付物归纳出来，形成某个阶段我们应该完成哪些可交付物。例如里程碑一要完成业务用例模型、概念模型、分析模型.......；里程碑二要完成界面原型......
上面的工作是制定迭代计划的基础。一个迭代计划是说，在整个软件开发阶段中，根据实际情况，我们需要用几次反复来完成。而每一次反复，我们要完成哪些里程碑里的哪些可交付物。例如第一次迭代，我们要完成里程碑一里的业务用例模型、概念模型和里程碑二里的界面原型；第二次迭代我们要完成全部的里程碑一和全部的里程碑二；第三次迭代我们要完成.....而每一次的反复，我们都要重新检查和更新上一次反复的可交付物。
为什么制定迭代计划一定要先定义生命周期和里程碑呢？这是因为生命周期计划规定了每一次迭代要遵循的标准过程，即怎么做；里程碑计划规定了每个阶段交付哪些产品，即每一次迭代要做什么。迭代，是事先计划好的，不一定因为需求变更而变更，除非这个变更通过变更委员会评审决定后，才有可能调整迭代计划，事实上，如果迭代计划要调整，基本上整个软件计划可能都需要变更了。
所谓的迭代过程，就是在每一次反复的时候，按照生命周期计划里规定的实施流程一步步的，把每一个产生的可交付物根据新的需求，变更的需求，精化的要求，补充的内容再次完成一遍。
很多人混淆了迭代与变更管理，从形式上看，它们的确比较类似。但它们的目标和范围是不同的，或许可以类比为战略和战术的关系。在一个成熟的组织里，迭代是计划性的，不同的项目有不同的迭代次数和计划，而变更管理是管理性的，所有项目都遵循同样的管理流程。迭代是解决软件生命周期问题的，变更管理则是解决质量控制问题的。
不知道我的表述是否清楚了。很感谢你提这个问题，给我提供了一个想法，某天我会就RUP中软件过程是怎么实现的写点东西的。
re: 系统分析，业务建模，UML，RUP相关 [回复]coffeewoo@263.net，这个邮箱不知您是否还在使用，曾发过邮件，未得到回复，呵呵，不知能否得到您的即时联系方式，我的MSN是abel_zhyb@hotmail.com，期待中。。。
审核能作为一个业务用例吗？ [回复]在业务流程中，审核是经常的必须的环节，不知道在业务建模阶段，是否应该作为一个用例？如果是，则又导致用例非常多！麻烦解答一下！谢谢！
谢谢回答！ [回复]我的意思主要是审核某种申请或文件，例如是审核物品申请，如样品申请、办公用品申请的审核等，
是否就可以算是一个用例呢？显然，这是存在受体的！也存在可观测的结果，如已审核后的申请表等。
如果把审核申请这一类也算是用例，可能会导致用例粒度太细。如果不包括审核XX申请这一类东西，似乎需求描述不太明确。
re: 系统分析，业务建模，UML，RUP相关 [回复]另外，在商业模型中，通常一个角色，如部门经理或总经理，
大多会存在大量的申请需要审核，例如营销部门经理通常会审核退换货申请、发货申请、人员招聘申请等，而部门经理通常不是具体的申请流程的起点！
用例粒度的问题 [回复]coffeewoo,非常感谢您的OO系统分析员之路系列！
这是难得的一个系统分析入门的好东东！
对我的触动和启发很多！非常感谢！
这里有些问题想请教一下，是关于用例粒度的！
你的文章提到：
"在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。"
”在用例分析阶段，用例的的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。“
"在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。"
因此,如上所述，在业务建模阶段，似乎一个用例对应一个业务流程，如 申请费用 就对应一个费用申请的业务流程。
假设费用申请的流程或者过程是： 业务员提出费用申请，部门经理审核申请，财务主管审批。
显然，按照业务建模阶段 用例的粒度说明，业务员对应的用例是申请费用。是一个完整的业务流程
而部门经理对应的审核费用申请，财务主管的审核费用申请似乎也应该算是用例。
但是审核费用同时也是费用申请流程的一个步骤。也即审核费用的粒度应该与用例分析阶段的用例的粒度一致。
因此，我想问的是：
业务建模阶段，费用申请这个由业务员启动的用例可以描述一个完整的业务流程。
那么，类似部门经理的审核费用这样业务应该如何在业务模型中描述呢？因为审核费用是费用申请流程中的一个步骤，
若审核费用作为一个用例，它的粒度与业务员的费用申请的粒度应该是不一致的。
用例规约的事件流描述中可以引入其它的actor吗？ [回复]大赞
这两天一直在咖啡小驻学习，对我这么一个初学者是莫大的帮助。
接着cloud的问题继续提问：
最近在做考勤系统的分析，也是遇到了cloud类似的苦恼。
针对“申请出差”这个用例，我是如下这样描述事件流的
1、员工提出出差申请
2、部门领导审批申请
3、人事专员审批申请
请问这样描述合适吗？应该怎样描述比较好，谢谢！
re: coffeewoo [回复]非常感谢coffeewoo及时地解答我的问题。
可能是我刚才没有描述清楚我的问题，我再详细描述一下。
我现在想做一个公司考勤系统，用于员工签到签退，各种假勤和加班等的申请与管理，人力资源部制定排班计划等。
本来已经画了一个rose图，不过现在手头没有，那我就用文字描述一下：
目前我抽象了几个actor：员工、人事专员、部门领导、公司主管
各个actor相关的usecase如下：
1、员工：签到、签退、申请加班、申请调班、申请休假、申请外出、查询个人排班、查询个人考勤
2、人事专员：排班、管理加班、管理调班、管理休假、管理外出、查看考勤统计报表
3、部门领导：管理加班、管理调班、管理休假、管理外出、查看考勤统计报表
4、公司主管：查看考勤统计报表
由于考勤系统中很多业务都是一个流程，所以我写的用例规约就是描述该用例对应的业务流程的步骤，以“申请出差”为例：
用例规约：申请出差
1. 用例名称
申请出差
1.1 简要说明
此用例描述员工通过考勤系统是如何进行申请出差操作的。
2. 事件流
计划外出的员工登录系统并选择“申请出差”后开始该用例。
2.1 基本流
1、员工提出出差申请
员工填写计划出差时间、地点和缘由
2、部门领导审批申请
系统提示部门领导审批申请，部门领导审批申请
3、人事专员审批申请
系统提示人事专员审批申请，人事专员审批申请
2.2 备选流
……
3. 前置条件
员工已登陆系统并选择“申请出差”操作。
我对用例规约的理解是描述actor为了实现usecase的目的，actor与业务系统交互的过程。
那么，我有几个问题：
1、用例规约中可以出现其它actor吗？比如说“申请出差”中的部门领导和人事专员
2、当actor发起一个usecase时，会产生一些信息，由系统主动传递给其它的actor，这个需要出现在用例规约中吗？比如说“申请出差”中的系统提示部门领导审批申请
3、当一个usecase的业务场景中，需要其它actor的行为，需要在用例规约中出现吗？比如说“申请出差”中的部门领导审批申请
coffeewoo，不知道我这样是不是说清楚了，谢谢
re: 上面那个问题 [回复]coffeewoo，我还有一个想法就是引入工作流系统，不过想法还不成熟
每次申请时，都是员工提出申请，传递申请信息给考勤系统，然后考勤系统将申请信息传递给工作流系统，工作流系统将审批结果传递给考勤系统，考勤系统将审批结果传递给员工
不过感觉这样把部门领导审批给遗漏了。
请coffeewoo指点一二，谢谢！
re: 系统分析，业务建模，UML，RUP相关 [回复]想问一下LittleD 您的UC是在什么阶段？业务用例还是系统用例？
业务用例的话太细化了，比如：签到、签退、申请加班、申请调班、申请休假、申请外出、查询个人排班、查询个人考勤
这些整个其实可以作为一个用例，就叫做“管理考勤”。
如果做在系统用例是可以的，但是您的前置条件又太少。
而且还有个很大的问题，从您对基本流的描述来看，您不是针对一个用例在描述。您是在描述全部的工作流程。这是不正确的，每个用例都有其自身的场景，您所描述的不是用例，这是常见的甬道图的工作流程。
另外我先回答一下您的问题：
1。用例规约中可以出现其它actor，多个actor对一个用例的使用是没问题的
2。这样的信息是可以出现的，不过请注意是在系统用例的阶段才可以出现
3。这个问题是粒度的问题了
我先代替coffeewoo回答一下哦，回答得不对不要怪我，呵呵
3。
re: rwyx&coffeewoo [回复]非常感谢rwyx和coffeewoo的回答。
发现自己是有点把业务用例和系统用例搞混了，可能是没有经验的原因吧
，希望以后不要搞混了。
to coffeewoo，我定义的管理加班的确只有审批，浏览、查询、统计等都归到查看考勤统计报表
之所以这样，我可能是有点仿coffeewoo给的那个图书馆的例子
在那个例子中，借阅管理员的所有用例（除了查看借阅记录）都应该是借阅人的操作驱动的，而不是借阅管理员自己发起的
这样我就有一个疑问：
在业务阶段，像“管理加班”和“颁发借阅证”这种不是由actor主动发起的事件，是不是应该作为用例出现？
如果不作为用例出现，那这种事件如何体现在业务建模阶段？
谢谢
re: 系统分析，业务建模，UML，RUP相关 [回复]今天真是失策呀，没有比coffeewoo 快，不过这里是他的领地，也得给他点面子是吧^_^
关于“业务、概念和系统阶段分别应该产出哪些内容和图？”这个问题确实很难回答，因为每个公司对其需求规格说明书的要求是不一样的。
通常来说，业务用例虽然常见的是用例图，但是对每个用例的说明却有很多很多，前置条件、后置条件、基本流、可选流等等，而且在业务用例前做得规范一点还要做组织机构图、角色说明等等工作。再做得具体一点，可以产生一份专门和客户以交流的甬道图，当然这些并没有规定你是必须去做的工作。
系统用例则相对更细节，它的画法相信 LittleD已经明白了，不过，我猜测LittleD可能对每个系统用例的描述有困惑。其实在系统用例来说可以有两种描述，一种是利用用例实现图，将实体和实体间的交互在用例实现图中表述出来，然后配合文档的说明，另一种是纯文档形式，纯文档形式就和业务用例的说明差不多了，基本要包括“前置条件、后置条件、基本流、可选流等”这些内容，此外，纯文档形式还必须抽取业务对象（一般这个算是分析模型的一种）。
就如同coffeewoo所说的“业务就是明确需求范围，概念就是用例分析，形成关键业务的框架和解决方案，系统就是决定开发范围”，抓住这个主要概念就可以了。
评论比较短可能说得不够清楚，有什么问题还请包涵
re: rwyx&coffeewoo [回复]非常感谢二位的回答。
我又有几个问题：
1、如果在业务用例阶段，有一个actor A1和相关联的usecase UC1,如果在系统用例阶段，UC1可能会扩展或包含一个usecase UC2，请问UC2 是必须与actor A相关联还是可以与其它的actor B相关联？
2、其实这个问题也与第一个问题有关：用例规约是在什么阶段写，是在业务阶段？系统阶段？还是都有可能？
3、是不是所有的用例都应该写用例规约？比如说第一个问题中的UC1包含UC2，那么这两个用例是不是都需要写用例规约？
4、用例规约与时序图有啥关联吗？
呵呵，又提了一些基本而且教条的问题
re: 系统分析，业务建模，UML，RUP相关 [回复]我只想回答第一个问题,可以的,两个actor同时对一个用例起作用是没问题的,关键在于如果你这么画了,那么在描述时就有必要在两个actor工作的这个用例场景中分别详细描述,因为归根结底,它属于两个不同场景的工作.用两个用例或许更清晰,不过你画成了一个,这说明你抽象了,但是在描述时还要描述清晰的.
而且在系统用例阶段,并不是人才是actor,连一个子系统也可能是actor,所以,你既然已经得到了一个子系统,那么一个用例也可能指向另一个子系统.
正好说到了子系统的概念,我想问一下coffeewoo,除了使用常见的UC矩阵(use/creat)方法来划分外,还有其他比较好的方法吗,或者你一般是怎么分的?(拍脑瓜,凭经验的方法除外)^_^
re: coffeewoo [回复]谢谢，明白了许多。
以后可能还有很多问题向coffeewoo和rwyx请教
有一个问题就是
在coffeewoo上面的回答中，提到检查和借书两个用例，我怎么感觉检查这个用例也不是主动用它，而是由读者的借书用例驱动
还有一个小问题：
正如coffeewoo提到业务阶段的用例规约是描述业务流，基本上是actor之间如何交互完成一个业务用例目标，如果一个UC1只与一个actor A相关联，即只有A主动用UC1，那么在UC1的用例规约中，actor栏是不是也可以出现其它的actor B，C之类的，因为完成UC1的业务目标需要actor A与B，C进行交互。
re: coffeewoo [回复]不得不说的是,你的这个做法是有效的,不过并没有解决我的提问.
为什么呢?呵呵
因为你这个做法其实就UC矩阵的做发呀,只不过UC矩阵用的是矩阵中Create和use来归纳工作和实体,然后手动将U/C两类数据进行不断移行,形成U/C交集点得到各个子系统.
而你的做法,虽然没有这么做,但你是将控制类和边界类与实体类进行分析合并,这个就等于是默默得在将use动作和create动作在不断的移行.到达user和create的交集.(coffeewoo式做法?)
re: 系统分析，业务建模，UML，RUP相关 [回复]受教，也许是我错了，不过我还是觉得使用UC矩阵是划分子系统的好方案，这点不管在OO还是非OO的项目中，而且，我觉得划分子系统最好是在越前面越好，甚至可以指导UC的包的划分。因为这么做的话在系统用例的时候就可以利用子系统作为角色来引导整个系统用例了。
另外control类和bandage类通常是在描述用例实现时才划分的，这个阶段属于的是逻辑模型中的分析模型阶段，和系统用例视图是有区别的。
系统用例关注的是系统做些什么，而逻辑模型则关注怎样做。
但是子系统的出现却是在系统用例阶段就有了。那么系统用例阶段的子系统该如何出现呢？
re: 系统分析，业务建模，UML，RUP相关 [回复]你的观点很清楚,也很明确,看起来我们最大的分歧点的确是在于子系统的定义,你的子系统的定义是为设计服务的,而我的子系统的定义则是为系统用例服务做指导的.
另外,你用MVC模式和门面模式来阐述你的观点,还真是第一次
见到有人这么说啊^_^
以武会友的话,最后应该说一句"佩服"
请教个问题 [回复]我是个学生，
这几天一直在coffeewoo看这些文章，
深深体会到您理解的深刻，这几天收获很多，对我以后的继续学习打下了很好的基础。谢谢您把经验与我们分享。
在学习中，我遇到了问题。想问问您。
问题：先创建了business usecase，在业务建模之后，是否还要创建use case,我觉得两者好像没什么差别。是不是可以直接拷贝过来，然后改变一下类型就可以了？
怎么从业务用例过渡到系统用例？
还有些不理解 [回复]谢谢您的回答.
那我能不能做这样的理解,您给的那个例子中,业务过程视图部分是属于业务视角方面的,而用例实现是属于系统用例方面的,因为用例实现是有加入计算机进行理解与设计了;
如果是这样的话,是不是要把用例实现的部分放到系统用例模型的文件夹中来.
我有点搞蒙了.
....... [回复]恩,谢谢!
我把Coffeewoo推荐给了同学朋友，他们现在都在学习。
我们也一直在进行着讨论，期待您的文章能再写下去，给我们以指导。有您作为明灯，我们不会觉得前进困难。
re: 系统分析，业务建模，UML，RUP相关 [回复]关于用例实现，我想说明一下，用例实现通常是被作为分析视图来给出的，因为它想告诉的是系统究竟怎样完成这个用例，而用例实现的每一个用例都是系统用例。
所以具体做的时候就应该在逻辑视图下建立一个分析视图，然后把系统用例的每一个用例拉进来做用例实现。
还要说明的是用例实现和用例描述是两个概念，用例实现更倾向于用例中对象的合作（这个对象的概念是业务对象），而用例描述则专注于对用例本身的描述。前者已经说过了是属于分析模型，后者则属于系统用例部分的工作
求助 [回复]现在学习UML有点晕了
请问coffeewoo 和rwyx：
同一个用例可能有多个actor发起吗？
比如说加班业务：
员工申请加班，直接主管审批，然后部门助理可以设置加班，人事专员也可以设置加班
这个时候是不是可以把部门助理和人事专员合并？
但是部门助理可以查看部门考勤情况，而人事专员可以设置考勤参数、查看公司考勤情况等（部门助理不可以）
请问这种情况下，可以合并两个actor吗？
这两天和同事讨论了很久都没有结果
re: 系统分析，业务建模，UML，RUP相关 [回复]多谢coffeewoo的回答
为什么部门助理也可视为发起加班业务的actor，那人事助理是不是也可以？
应该说只有员工申请加班，其他的actor才会共同奉献于加班业务
re: 系统分析，业务建模，UML，RUP相关 [回复]呵呵，我觉得吧，coffeewoo还是把系统用例和业务用例分出来吧，不然大家都会问这个问题的哦。
re: 系统分析，业务建模，UML，RUP相关 [回复]另外，回复duxiangyun一下，当你觉得几个actor多用例都有动作的话，那我建议你不要考虑对多个actor都明确分为“员工，主管，助理”，而是可以抽象一个actor，因为这个在设计人员设计时他会考虑某个actor有某些权限，而不会以职位来定死这个actor做什么。
也就是说权限、职能、角色三者的关系：
一个角色多个权限
一个角色一种职能（纯业务角度上讲，理论上这个需求只有在客户明确要求的情况下才应该实现）
一种职能多个权限（这个是考虑默认职能和权限的关系，但最终还是角色和权限的关系）
求助... [回复]coffeewoo，感谢您的文章和您的例子。
不在偶在学习您的例子中，有一个疑问：如何一个用例可以有多个用户发起，那么在泳道图中如何表示啊？
是不是要抽象出一个用户来啊?
re: 系统分析，业务建模，UML，RUP相关 [回复]多谢 coffeewoo 的解答心中疑问.
您回答的好快呀!感动中ing...
偶刚开始学uml,刚学着使用Rose,再次感谢您的导航.
以后可能很多疑问请教您哦!
re: 系统分析，业务建模，UML，RUP相关 [回复]不知怎么就进到这儿来了，觉得非常不错，就把你的文章都下载打印出来，认真的看了几遍，非常谢谢。最近也在想用这种模式来分析设计，但对于用户涉众的关系这块儿有个问题想问问，图书管理员与借阅管理员和书架管理员是一个什么关系，包含还是派生，包含的话是不是说把图书管理员的业务划分成借阅管理员和书架管理员的业务，那是不是也可以不定义图书管理员这个涉众，如果是派生的话是不是在图书管理员那儿要定义些基本的业务，而借阅管理员和书架管理员在继承这些业务的基础上，还有自己的业务。
re: 系统分析，业务建模，UML，RUP相关 [回复]不知怎么就进到这儿来了，觉得非常不错，就把你的文章都下载打印出来，认真的看了几遍，非常谢谢。最近也在想用这种模式来分析设计，但对于用户涉众的关系这块儿有个问题想问问，图书管理员与借阅管理员和书架管理员是一个什么关系，包含还是派生，包含的话是不是说把图书管理员的业务划分成借阅管理员和书架管理员的业务，那是不是也可以不定义图书管理员这个涉众，如果是派生的话是不是在图书管理员那儿要定义些基本的业务，而借阅管理员和书架管理员在继承这些业务的基础上，还有自己的业务。
re: 系统分析，业务建模，UML，RUP相关 [回复]关于边界类和控制类有点疑问：
比如我有一个对话框用来接收用户输入的e_mail，同时该对话框对该e_mail的合法性进行验证，比如不能缺少@符号....
这个当然是设计好以后的，但是在分析阶段我是作为两个类出现的：边界类、控制类。但最后确实只有一个类，疑惑......
re: 系统分析，业务建模，UML，RUP相关 [回复]上面的疑问不知我写的是不是清晰？我在重新解释一下：我有一个业务，检验输入E_mail的合法性，分析模型我是这样建的：用户--边界类--控制类，实现的时候我是这样做的，建立一个Dialog类，其中含有bool IsValid();这个函数实现合法性检验。疑问产生了我发现这个控制类所作的一切实际上是这个边界类的一个功能。
我想问：是我的分析模型建的不对，还是我的设计有问题？按你前面说的“需求可追溯”，我这里应该设计边界类和控制类，并给出实现，但我的做法是控制类所作的成了边界类的一个功能。
在实际中是不是有这种情况？分析模型中的一些个分析类成为另一个分析类的一部分（作为这个类中的一个功能出现）。
re: 系统分析，业务建模，UML，RUP相关 [回复]看了啡哥的文章，收获还是挺大的。
现在对如何完成一个完整的项目开发，从需求一直到交付，虽然整体上有一个认识：先做需求，在分析，然后设计....
但是再细一点就不太明确了，啡哥能否为给小弟写一个类似于流程的东西，比如：开发一个项目总共分为几个阶段；每个阶段由那些个具体的小阶段组成；在这个小阶段里我们应该干什么(用例分析？场景分析？...)，怎么做(使用类图？活动图？时序图...)，形成一个什么基线或里程碑式的东西，他和下个阶段的关系.
小弟现在缺少这样一个宏观性的了解，因此对于什么业务建模、用例实现、业务场景分析、用例场景分析、领域模型.....太多的概念有些混淆，脑子里有些乱。
希望大哥给予指点！！
re: 系统分析，业务建模，UML，RUP相关 [回复]现在我是这样认识这一个流程的：
需求分析：
用户交谈---->业务用例（用例图）--->业务场景分析（活动图）---->用例实现（用例图）---->用例场景分析(活动图)
分析阶段：
(接上一阶段)---->捕获实体---->分析模型（时序图、类图)
设计阶段：
..............
我这个认识还相当粗浅，而且自己也感觉别扭，望啡哥给写个详细的。
re: 系统分析，业务建模，UML，RUP相关 [回复]收获很大.....
谢谢啡哥.
另外我想和啡哥交流一些个关于实际开发方面的东西.
我现在还是个学生,没到过什么公司干过,仅仅天天在实验室跟老师干项目,我们现在作项目,是这样一个流程:老师给我们说一下需要作个什么系统,然后我们几个学生和老师稍微一讨论,也没有什么正式的用例图、分析模型甚至都没有类图.....然后我们几个人大体考虑一下功能模块划分，然后就是直接做，最终也能把系统作出来。
感觉好像开发项目就是需求和编码，也没那么复杂，只要自己编程强，好像要什么功能基本都能实现，而且一些个设计模式我感觉自己用的还挺好、一些类自己写的也合理......在我们看来这些个建模、各种文档纯粹是形式、没什么作用，我们写那些个文档仅仅是应付一下，有那么个东西而已，实际开发、编码根本也不看！！
作为一名计算机的学生，我也知道这是不符合软件工程思想的，但这种开发方式确实好用，而且我们从未失过手，呵呵.如果要让我们按照正规的套路，一步一步来，感觉没有必要。
我想知道这种做法在实际中是不是普遍？？？需求---->编码，当然其间也有分析和设计，只是它们太微乎其微，我们可以忽略。也就是说有了需求之后脑袋里直接就蹦出功能模块、设计、编码.
希望啡哥发表一下看法。
re: 系统分析，业务建模，UML，RUP相关 [回复]您真是年轻的ＩＴ高手，因为某些原因，要学习＂系统分析＂有关知识，也就借这机会认识您了（昨晚才认识您哦），真有点相见恨晚的感觉！！！呵呵
您的聪明我是永远学不到的（我天生是个笨脑袋，呵呵），但可以跟你学到很多ＯＯ实践经验，但愿您能一如既往地跟我们分享您的知识、经验。
求解：Logic View中的Business Model是分析还是设计的产物 [回复]俺是菜鸟，说过错了表打。
看那个例子中，use case view和logic view各有三个过程，其他都明白，就是不太清楚logic view中的Business Model是需求分析的产物还是系统设计的产物，或者说，Business Model是在什么阶段产生的，分析员做的还是设计师做的？谢谢
re: coffeewoo [回复]谢谢coffee兄这么快回复，我还是有些不清楚，能不能简单说一下Business Model 和Business usecase Model的关系。
为什么要把Business Model放到逻辑试图中？
我个人感觉放到用例视图中不是更合逻辑，层次更清楚吗？因为这样所有需求分析的产物都在用例试图中了。。。
re: 系统分析，业务建模，UML，RUP相关 [回复]hi..你好。这几天一直在学习你的提供的那个html的demo.有一些疑问：
一：
在你的目录分层的结构的基本用意是什么呢？如
-Use Case View
|---Business usecase model (A)
|---Analysis usecase model (B)
|---System usecase model (C)
-Logic View
|--System Model
|--Analysis Model
|--Business Model
|---Business Entity Model (D)
问:
1）“A“是否存放着业务建模的business actor,business usecase?
2） 那么"B"它会放什么呢?
3) 你在前面有谈到，你现在做的是系统用例实现，而不是"业务用例实现"？那么，请问，系统用例是从何推断出来的呢？它跟"业务用例"是什么关系吗？有没有可能，系统用例是通过"业务用例实现"的活动图来推断出来的？
4）同上述3）的问题，那么，系统actor是如何从business actor 推断出来的呢?
4)
re: 系统分析，业务建模，UML，RUP相关 [回复]如你第2点所述：
从"业务用例A"的实现过程(活动图)里有三个主要的业务模块,即用概念用例来表示"概念用例A-1","概念用例A-2","概念用例A-3"。
那么，从一般情况来说，就可能会推导出"系统用例A-1","系统用例A-2","系统用例A-3"呢?
有没会简要的例子来说明"业务用例"-->"概念用例"-->"系统用例"的推导过程呢?（哈，好象要求有过份了，如果没时间就算了...呵，不管如何，还是很感谢你在百忙之中抽时间回复 ^_^ )
re: 系统分析，业务建模，UML，RUP相关 [回复]呵呵,什么时候书会出来呢?给个大概时间啦...估计这个问题，是N多你的fans想问的...对了,在你的书出来之前，有没有可以推荐的这方面的其它方面的书呢？
re: 系统分析，业务建模，UML，RUP相关 [回复]呵呵,什么时候书会出来呢?给个大概时间啦...估计这个问题，是N多你的fans想问的...对了,在你的书出来之前，有没有可以推荐的这方面的其它方面的书呢？
系统管理的问题 [回复]你在用例分析系列中提到，业务建模应该完全是用户语言，业务视角，最终的产品的需求规格说明书，我想问个问题：一般的应用系统都会有“系统管理”这个模块，里面包含基础数据、用户、角色、权限和日志等控制功能，那么在业务建模中应该不会涉及到这些“计算机视角”的东西，是否在需求中也没必要描述这些功能，只描述对用户有直接业务价值的用例。
PS：俺用你的理论做了一个项目的业务模型，忽略计算机视角的东西，只得出10个业务用例，心中惶恐不安。。。
业务模型的粒度 [回复]还有一个问题，也希望coffee兄一并解答，菜鸟无奈啊，见谅。。。
从俺的理解看来，在业务模型中似乎不应该出现include，extend这样的关系东西，因为用例的逻辑关系是在概念模型中分析出来的。
但是我的例子中有这样的问题：用户的需求明确含有查询、统计、汇总这样内容，但是我通过画活动图发现，这些功能的目的都是“检查数据”，所以似乎应该合成一个业务用例“检查数据”，但是这样又似乎忽略了客户的业务需求，如果分解开，感觉业务场景图画不好了，因为这是一个活动。。。
到底应该是查询、统计、汇总三个用例呢？还是“检查数据”一个用例，如果是后者，我的业务场景图不会画了。。。
用例图划分的问题 [回复]hi，coffee，
我想问一个用例图划分的问题，比如我要开发的是一个shareware，PIM类的，参与者只有用户和一个定时器，用户要处理几“组”不同的事务，比如 添删改查导入导出 通讯簿、便笺、隐私信息、邮件、提醒等等，这几“组”用例参与者都是“用户”，但每组的逻辑都不相关，那么是应该放在一个用例图中呢（比如用户操作系统用例），还是分开放在不同的用例图（比如通讯簿处理用例、便笺处理用例。。。）？
re: 系统分析，业务建模，UML，RUP相关 [回复]coffee兄：
能不能说一下系统用例模型中的角色是如何划分的，或者说划分角色的依据是什么？
我遇到一个这样的问题，我做的系统用例模型中有一个角色叫“业务人员”，大部分系统用例的执行者都是它，为了减轻它的负担，或者说让图形更好安排，我想再增加一个角色叫“信息化人员”，在实际工作中，这两种角色在客户那边没有特别严格的区分，我想问的是：在系统角色方面，是否有这样的随意性？
re: 系统分析，业务建模，UML，RUP相关 [回复]我觉得建模应该有一个规模边界，对于很庞大的系统，用模型来描述，反而会因为太多的模型元素，而会导致无序和混乱。比如银行系统，银行面向客户提供很多服务，比如存款、贷款、结算、汇划、外汇、债券等等，还有很多衍生服务，这些服务都是依托一个庞大的系统来运作的，而且还在不断的优化改进中……这样一个庞大的系统，如果作为一个模型来维护，里面将有成千上万的用例；如果切分成不同的业务模块，又很难用一个唯一的标准来进行切分；目前的思路，只能按照开发任务来进行建模，但这样，势必又导致很多元素在不同模型中都有表达，并且表达不唯一。我们在建模方面也是刚起步，所以，感觉思路有些混乱，不知道咖啡兄有无好的建议，谢谢：）
thx to coffeewoo ：） [回复]谢谢咖啡兄，似乎有些明白了，我还需要点时间再考虑清楚！但我还有一个问题，我们的系统是已经相对成形的，引进建模是眼前的课题，但对于已成形的系统，是采取追溯的方式进行基础建模吗？这样，似乎有一个非常庞大的工作量，所以，我们的考虑，是按照当前的任务建模，并对当前任务所涉及到的相关模块，进行基础建模，你觉得这个思路合适吗？还是先将整个基础模型先建立起来？
thx to coffeewoo ：） [回复]谢谢咖啡兄，似乎有些明白了，我还需要点时间再考虑清楚！但我还有一个问题，我们的系统是已经相对成形的，引进建模是眼前的课题，但对于已成形的系统，是采取追溯的方式进行基础建模吗？这样，似乎有一个非常庞大的工作量，所以，我们的考虑，是按照当前的任务建模，并对当前任务所涉及到的相关模块，进行基础建模，你觉得这个思路合适吗？还是先将整个基础模型先建立起来？
求教3种用例的获取时机 [回复]您好,细读了您的用例分析系列文章，有问题想请教一下：
1、在系列（2）用例粒度一文中谈到用例可按不同阶段分为业务用例，概念用例和系统用例；在本篇中又谈到了建模一般步骤，其中步骤4用例场景分析中引入了计算机角色，是否应该在此时分析并获取概念用例？如是则是否需要对步骤1，2进行重新迭代，缩小系统边界以获取更多业务参与者和概念用例？如否则想请教一下这几种用例都是在什么时候获取的？有无一个类似本篇步骤列表之类的可遵循的获取过程？
2、如果在初始的步骤1，2中是按照粗粒度（或者说按业务层次）的程度获取业务参与者和业务用例的话，则图书网络借阅示例中业务参与者（BA）仅有借阅人和图书管理员，其中借阅人有4个业务用例：办理借阅证，交纳借阅费，借阅图书（归还图书业务不可独立存在所以不算独立的业务），查看借阅记录；图书管理员仅有查看借阅记录一个用例。这样理解正确吗？如果是这样，则步骤3中所建议的“针对每项业务视图，应该绘制业务场景图”则很难绘制。个人认为此视图中的用例至少应该是概念用例这种粒度的。这样的话其实也可归纳到问题1中。
恳请您的指点，谢谢！
RUP的软件过程和软件工作量估计的联系 [回复]coffee老兄，请教您一个问题，我们知道RUP有四个阶段和九个核心工作流，能不能谈谈，如何把RUP的软件过程的项目目标和软件工作量估计之间的关系呢？如何在项目初始阶段估计软件项目的工作量呢？在RUP中，如何估计软件的整体工作量呢？多谢啊！
re: 系统分析，业务建模，UML，RUP相关 [回复]自从同事推荐coffeewoo老兄的blog，本人一直关注这个blog，并从中吸取营养，学习并进行实践，在此感谢coffeewoo老兄。
本人从事金融业的开发，前期开发一个中间业务前置时碰到一些疑惑。如何将uml应用于通讯前置系统的分析和设计呢。
举例如下，需要开发一个前置系统，转发银行渠道前置通过socket传送的业务请求给交警系统，进行交通违规信息查询，交通罚款代缴等交易；并每日通过socket交换信息，获取批量缴款文件更新交警数据库。为用户提供日志信息浏览以及手工更新缴款
初步建模如下
角色：银行渠道前置、交警系统、定时器、用户
case：定时更新缴款记录、手工更新、日志信息浏览、查询违规信息、缴款。
但是对查询违规信息和缴款是否设定为case比较犹豫，因为在前置系统上有很多的第3方代理业务，比如电话代缴、查询等，如果一个代理业务设置为一个case，就意味这很多的case。谢谢指教
re: 系统分析，业务建模，UML，RUP相关 [回复]coffeewoo老兄请教一个问题。比如现行开发一个贷款项目，该系统以socket的方式为其他系统提供贷款功能服务。如客户资料查询，循环额度贷款等。客户资料包括客户基本身份资料查询、账户资料查询以及客户授信额度查询3个子交易。循环额度又包括客户已贷款查询和贷款额度查询子交易。
类似此类为其他系统提供服务的业务系统是否适合用oo来建模分析。如果适合又如何进行业务建模和系统建模呢。感觉上用面向过程的是否会更适合些？
re: 系统分析，业务建模，UML，RUP相关 [回复]针对举例设定消费者柜面程序为业务角色，服务提供者贷款业务系统提供的客户资料查询以及循环额度贷款为业务用例，那系统用例呢？是否两个一致呢？
假定客户资料包括客户基本身份资料查询、账户资料查询以及客户授信额度查询3个子交易。是否3个子交易就可认为系统用例呢？
业务用例是否就是开发系统为客户端程序提供的服务接口呢，系统用例为所提供接口的内部步骤呢？如果假定业务用例为服务接口，系统用例为内部步骤，而当内部步骤十分简单时，是否直接将业务用例转化为系统用例呢？
另外如果设定资料查询为业务用例，描述业务场景的时候只有单泳道，这种情况是否正常呢？如果业务系统中的其他业务场景也大都为单泳道，这种情况是否正常需要进行改进呢？
开发此类系统（即为其他系统提供服务的计算机系统）时，业务建模和系统建模，以及业务用例和系统用例的区别又在哪里呢？
re: 系统分析，业务建模，UML，RUP相关 [回复]嗯，那针对查询的业务用例是否衍生出解码（将客户端传送的数据转换为内部数据）、查询（查询不同系统数据）、编码（将内部数据组织成标准格式）3个系统用例。
另外能否请coffeewoo兄推荐一些相关的书籍呢。
re: 系统分析，业务建模，UML，RUP相关 [回复]从你的文章可以看出，你真正理解了OOP ,UML etc.
你的书什么时候出来，我下学期要上UML 课，打算用你的书。
schuang8@sohu.com