1,268
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
青润 2001-10-23
- 打赏
- 举报
Actor本身是不应该相互嵌套的，如果发生了大量的交叉，我觉得你们应该考虑重新划分Actor。
下面是如何选择Actor的方法（来自RUP），如果您觉得我在此上或者此下有什么地方描述的有问题，请提出来，我们一起探讨：
首先考虑使用系统的个人。如何对他们进行分类？作为一种好习惯，通常应考虑 2 至 3 个人，并确保您所确定的主角能够满足他们的所有需要。如果在确定主角时能考虑到以下问题，那将非常有用：
谁负责提供、使用或删除信息？
谁将使用此功能？
谁对某个特定功能感兴趣？
在组织中的什么地方使用系统？
谁负责支持和维护系统？
系统有哪些外部资源？
其他还有哪些系统将需要与该系统进行交互？
系统环境中有多个不同的方面可用单独的主角来表示：
执行系统主要功能的用户。
下面是如何选择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权限问题如何表示？
