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

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
这要看这些职员所完成的任务是否可以合并,如果相似点很少,合并后容易造成混乱或者资源浪费较大的话,那最好不要和并他们,而作为两个角色来处理。
回复
加载更多回复
相关推荐
发帖
研发管理
创建于2007-08-27

1221

社区成员

软件工程/管理 管理版
申请成为版主
帖子事件
创建了帖子
2001-10-20 12:33
社区公告
暂无公告