社区
研发管理
帖子详情
现在的actor比较复杂。关联比较多。功能有些嵌套。这样的 actor如何分析?
drama
2001-10-22 06:59:13
...全文
90
6
打赏
收藏
现在的actor比较复杂。关联比较多。功能有些嵌套。这样的 actor如何分析?
复制链接
扫一扫
分享
转发到动态
举报
AI
作业
写回复
配置赞助广告
用AI写文章
6 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
青润
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权限问题如何表示?
数据库设计(包括select语句、子查询、语句
嵌套
)
关于电影公司的数据库设计建模 包括 select语句 子查询,语句
嵌套
等
sakila数据库脚本复杂查询
使用mysql官方的sakila数据库脚本进行的复杂查询的案例
google-sonalsen-
actor
google-sonalsen-
actor
mysql示例数据库-sakila
mysql示例数据库——sakila
软件工程施工复习题.doc
软件工程施工复习题.doc
研发管理
1,268
社区成员
28,284
社区内容
发帖
与我相关
我的任务
研发管理
软件工程/管理 管理版
复制链接
扫一扫
分享
社区描述
软件工程/管理 管理版
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章