又有新的问题了，请用各位前辈继续进来解答我几个问题！

nie 2001-10-20 12:33:53

1.我在用use case图描述系统是遇到一对多的关系，举个例子：
比如：一个领导负责分配任务，几个职员负责执行任务，当领导接到任务时将它们分给职员执行，这时怎么描述呢，是把每个职员作为一个角色，还是所有的职员作为不同的角色。

...全文

141 点赞收藏 21

写回复

21 条回复

切换为时间正序

当前发帖距今超过3年，不再开放新的回复

发表回复

nie 2001-10-23

回复赞

Jack_Loo 2001-10-22

这是一个很典型的角色的内聚与耦合的问题。
我通常的做法是看职员一与职员二如果作为一个角色是否关联较多，如时间关联、条件关联等。若关联少，则最好用2个角色，这样耦合小，但如果角色的事件少，也可以只用一个角色。如果关联强，则最好只用1个角色，这样内聚大，最好不要用2个角色。
to QingRun，能否介绍一下备选流，从没听说过。

回复赞

nie 2001-10-22

to qingrun
rupc中的描述的整个开发过程，是不是符合cmm要求，如果按照rupc中的过程做了，是不是也就符合cmm？

回复赞

青润 2001-10-22

子流和备选流是在你进行需求文档的用例阐述中需要描述的内容，如果你没有做这方面的工作，最好你做一下补充。关于用例阐述的问题，建议你最好阅读一下rup中关于用例阐述的描述，这也是提高你进行需求收集整理的一个好的过程。
你的分析模型和设计模型都应该基于你的用例阐述（也就是需求）开展，否则你就属于无目的的作分析和设计了，你也很难设计出符合用户要求的模型。

回复赞

nie 2001-10-22

to qingruan
对，我只得就是后一种，应为这个条件状态会转向不同的过程呀！
那么请问什么是子流或备选流，怎么处理呢？

回复赞

青润 2001-10-22

我个人认为：条件状态分为两种，一种是比较小的，比如说只需要很简单的一个方法或者“取消”等这类方法，就不必要非要写出来，只要在状态图中描述清楚就足够了；另外一种是比较大的分支，经过条件判断后会产生出一条新的分支，这个时候，建议最好作为子流或者备选流来处理。
我觉得：在时序图中主要是表述主流过程的一个时序表现，如果你非要把每一个细节都表现出来，也有点过于苛刻了。

回复赞

nie 2001-10-22

可是当实际系统中存在条件状态，而不描述，那顺序图岂不是描述不完整了吗？
那我该怎么处理这种情况呢？

回复赞

青润 2001-10-22

顺序图中的确无法描述条件状态，这些条件状态应该在类的状态/活动图中进行描述。

回复赞

nie 2001-10-22

各位，再支持一下吧

回复赞

nie 2001-10-22

小规模开发是不是使用TSPi（小组软件开发过程）更适合呢？

回复赞

nie 2001-10-22

裁减准则?
在什么地方？
我没看到！
你目前从事的开发工作是按照rup中提供的模式进行的吗？

回复赞

青润 2001-10-22

我希望是先建立一种适应目前小规模的开发模式，随着队伍的扩大再一步一步地细化。——这个看法我赞同。
rup中实际上是综合了瀑布式开发和螺旋式开发（当然还有其他开发模式中的一些方法），可以认为是将两者进行了中和后得到的开发模式，在我个人的感觉上，我认为：应该是有效的。
在rup中提供了一套裁减准则，按照rational公司的认识是：通过这套准则，rup就可以适合各种项目了，我觉得里面仍有值得商讨的地方。

回复赞

nie 2001-10-22

to qingrun
如果要做好一个工程，不是不需要将rup中所有的东西都看一遍，而且还要去理解，好像穷一个人的能力要花不少时间呀！
就你的实际经验而言，rup中阐述的这一套实不实用，有没有精简的可能。
比如有没有一套适用于小规模团队开发的模式？
因为我们这目前人手有限，一边要做事，一边我有希望能建立科学的开发模式。
我希望是先建立一种适应目前小规模的开发模式，随着队伍的扩大再一步一步地细化。
不知你有什么意见？

回复赞

青润 2001-10-22

你可以在rup中找到关于用例的指南，那里面就是阐述这个问题的。

回复赞

nie 2001-10-22

to qingrun
你说的是不是这个？
补充用例说明
获取理解系统的必要内部行为所需的其他信息，而这些信息可能是在为系统客户编写的用例说明中遗漏的。

回复赞

青润 2001-10-22

按照Rational公司的提议：RUP的过程是按照cmm2~3级之间的标准制定的，因为cmm3级要求的是建立组织级的规范和过程，所以这时比较现实的，而到了4级以上，就不可能仅仅局限于这样的规范过程了。
按照我的理解：关于备选流的描述，实际上和基本流相差不大，但是备选流应该是和基本流基本等价，比如用户提出的特殊分支需求，但属于正常或者单独设计的异常分支（也就是说：不是系统提供的异常，比如一般的输入错误就属于系统提供的异常）。这些流的描述应该归为备选流中进行，因为他们比较大，不能使用单独的一句话就描述清楚。

回复赞

nie 2001-10-21

我看到有的教程里的顺序图也描述了条件状态，但在rose的顺序图中好像描述不出来！

回复赞

nie 2001-10-21

to qingrun
2.如果我遇到这样的情况：
任务为情况一则领导交职员一处理，任务为情况二则领导交职员二处理
而职员一与职员二的处理程序并不相同，把他们作为两个角色之后，顺序图怎么描述是情况一还是情况二这个条件判断呢？
这时是不是非要用状态图？

回复赞

nie 2001-10-20

2.如果我遇到这样的情况：
任务为情况一则领导交职员一处理，任务为情况二则领导交职员二处理
我用rose中的use case图该怎么描述呢？
最好能结合上一个问题！

回复赞

青润 2001-10-20

这要看这些职员所完成的任务是否可以合并，如果相似点很少，合并后容易造成混乱或者资源浪费较大的话，那最好不要和并他们，而作为两个角色来处理。