用例可以没有演员吗? [英] Can a use case be without an actor?
问题描述
我正在制作全自动系统的用例图.外部系统只会触发该系统的一个用例.大多数其他用例是计划任务并由计时器调用.我有一个由计时器调用的用例,它包括并扩展了另外两个用例.
I am working on a use case diagram of a fully automated system. An external system will trigger just one use case of this system. Most of the other use cases are scheduled tasks and invoked by the timer. I have a use case that is invoked by the timer and it includes and extends two other use cases.
当我编写用例描述时,谁将成为 UC-2 和 UC-3 的参与者.没有参与者的用例可以存在吗?我见过很多用例图,其中包含或扩展了用例,而没有直接连接到参与者.请澄清这一点.提前致谢.
When I write the use case discriptions, who will be the actor for UC-2 and UC-3. Can a use case exists without an actor? I have seen lot of use case diagrams which has included or extended use cases without directly conneced to an actor. Please clarify this. Thanks in advance.
我的系统与 DBMS 连接.我的系统会不时分析数据库工作负载并检查是否可以进行任何调整.这就是我的系统.UC-1 是分析 DBMS,UC-2 是检查性能统计,UC-3 是调优数据库.所以计时器是调用用例的计时器.DBMS 从中受益.检查性能 (UC-2) 中的步骤在另一个用例中重复.这就是为什么我把它作为一个单独的用例.另一方面,只有在分析数据库后需要调优时才会执行调优数据库(UC-3).
My system is connected with a DBMS. My system will analyse the database workload time to time and check whether any tuning can be done. That's all about my system. UC-1 is Analyse DBMS, UC-2 is Check Performance statistics and UC-3 is Tune the database. So timer is the one which invoke the use case. DBMS gets the benefit.Steps in Check Performance (UC-2) are repeated in another use case. That's why I put it as a separate use case. On the other hand Tune database(UC-3) will be performed only if there is a need for tuning after analyzing the database.
推荐答案
官方来说这是正确的.包含用例是包含用例的强制性部分,扩展用例将可选地扩展一些用例.正如@Ister 在评论中指出的那样,包含/扩展用例的参与者将是主要用例的参与者.
Officially this is correct. An included use case is a mandatory part of the including use case and an extending use case will optionally extend some use case. As @Ister notes in the comment, the actor for the included/extending use cases will be that of the main use case.
但是,根据我的经验,您最好避免使用那些包含/扩展关系.在大多数情况下,人们倾向于将它们用于功能分解,这是完全错误的.用例应为其参与者显示附加值,而不是如何在某处使用某项功能.在大多数情况下,不存在附加值的结构,您可以很好地将每个气泡显示为独立用例或将其集成到主要用例中.我建议阅读 Bittner/Spence 以了解问题.
But, and this from my experience, you best avoid the use of those include/extend relations. In most cases, people tend to use them for functional decomposition which is plain wrong. A use case shall show an added value for its actor, not how a piece of functionality is used somewhere. In most cases a structuring of added value is not present and you can well show each bubble as a stand-alone use case or integrate it into the main use case. I recommend reading Bittner/Spence to get into matters.
Edit1:我才意识到这句话
仅触发此系统的一个用例
trigger just one use case of this system
这听起来像是将用例与活动混合在一起.这不是一个功能.用例是附加值.有一个具有触发器的用例的场景(集).但是说一个用例被触发"听起来是错误的.您触发用例的活动(它开始变得技术化).大多数技术人员都难以对用例进行剪裁和抽象.阅读 Bittner/Spence 的另一个理由.
This rather sounds like you mix use cases with activities. It's not a piece of functionality. A use case is added value. There is a scenario (set) for a use case which has a trigger. But saying "a use case is triggered" sounds just wrong. You trigger the activities of a use case (where it starts getting technical). Most techies have difficulties making the cut and abstract to use cases. One more reason to read Bittner/Spence.
Edit2:在您的评论中,您谈论的是技术用例.我承认我过去曾就此进行过深入的讨论.但是您需要区分技术和业务.您的业务用例是Analyse DBMS
、Check Performance
和Tune database
.因此,它们不是 Timer
的 UC,而是一些关心性能的机构.Timer
唯一的 UC 是 Trigger task
(或类似的东西).有一个切口.Timer
不关心业务.它会以同样的方式愉快地触发系统关闭.它并不仅仅因为它在技术上用于启动一些与业务相关的流程这一事实而成为业务参与者.
Edit2: In your comment you are talking about technical use cases. I admit that I had intensive discussions about this in the past. But you need to differentiate between technic and business. Your business use cases are Analyse DBMS
, Check Performance
, and Tune database
. As such they are no UCs for a Timer
but for some institution that cares about performance. The only UC for Timer
is Trigger task
(or something like that). There is a cut. The Timer
does not care about business. It will happily trigger the shutdown of the system in the same way. It does not become a business actor only for that fact that it is technically used to start some business relevant process.
不要忘记:阅读 Bittner/Spence.对我来说,这本书让我大开眼界,因为我也不知道用例的意图.
And not to forget: read Bittner/Spence. For me this book was an eye opener since I also had no idea about the intention of use cases.
这篇关于用例可以没有演员吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!