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

nie 2001-10-20 12:33:53

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

...全文

171 21 打赏收藏转发到动态举报

写回复

用AI写文章

21 条回复

切换为时间正序

请发表友善的回复…

发表回复

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