现在的actor比较复杂。关联比较多。功能有些嵌套。这样的 actor如何分析?

drama 至德讯通(北京)科技有限公司 技术总监/研发总监  2001-10-22 06:59:13
...全文
47 点赞 收藏 6
写回复
6 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
青润 2001-10-23
Actor本身是不应该相互嵌套的,如果发生了大量的交叉,我觉得你们应该考虑重新划分Actor。
下面是如何选择Actor的方法(来自RUP),如果您觉得我在此上或者此下有什么地方描述的有问题,请提出来,我们一起探讨:
首先考虑使用系统的个人。如何对他们进行分类?作为一种好习惯,通常应考虑 2 至 3 个人,并确保您所确定的主角能够满足他们的所有需要。如果在确定主角时能考虑到以下问题,那将非常有用:

谁负责提供、使用或删除信息?
谁将使用此功能?
谁对某个特定功能感兴趣?
在组织中的什么地方使用系统?
谁负责支持和维护系统?
系统有哪些外部资源?
其他还有哪些系统将需要与该系统进行交互?

系统环境中有多个不同的方面可用单独的主角来表示:
执行系统主要功能的用户。
回复
drama 2001-10-23
actor总是要操作use case 吧。如果嵌套很多,也会很乱的吧。我现在就是想把actor简化。可能是我对actor的想法有些问题
回复
青润 2001-10-23
到底是Actor还是Ucs Case?我已经看晕了。
回复
drama 2001-10-23
就是因为他们使用的use case 现在如果简单划分的化,use case diagram 将会十分繁琐,所以我才想将其简化。
回复
青润 2001-10-23
你这里的actor是如何划分的?actor的功能对系统来说是外在的,完全可以不做更多的考虑,它们之间的交互式在于actor如何使用系统的功能(或者UseCase),而不是你的系统如何使用这个actor,老兄,您的想法似乎有点问题。
回复
drama 2001-10-23
actor权限问题如何表示?
回复
相关推荐
发帖
研发管理
创建于2007-08-27

1219

社区成员

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