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

[drama]

[drama]

actor权限问题如何表示？

[青润]

你这里的actor是如何划分的？actor的功能对系统来说是外在的，完全可以不做更多的考虑，它们之间的交互式在于actor如何使用系统的功能（或者UseCase），而不是你的系统如何使用这个actor，老兄，您的想法似乎有点问题。

[drama]

就是因为他们使用的use case 现在如果简单划分的化，use case diagram 将会十分繁琐，所以我才想将其简化。

[青润]

到底是Actor还是Ucs Case？我已经看晕了。

[drama]

actor总是要操作use case 吧。如果嵌套很多，也会很乱的吧。我现在就是想把actor简化。可能是我对actor的想法有些问题

[青润]

Actor本身是不应该相互嵌套的，如果发生了大量的交叉，我觉得你们应该考虑重新划分Actor。
下面是如何选择Actor的方法（来自RUP），如果您觉得我在此上或者此下有什么地方描述的有问题，请提出来，我们一起探讨：
首先考虑使用系统的个人。如何对他们进行分类？作为一种好习惯，通常应考虑 2 至 3 个人，并确保您所确定的主角能够满足他们的所有需要。如果在确定主角时能考虑到以下问题，那将非常有用：

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

系统环境中有多个不同的方面可用单独的主角来表示：
执行系统主要功能的用户。