Can a system be an actor in a use case?

View Full Version : Can a system be an actor in a use case?

---

 

beej199

07-18-2006, 01:43 PM

Ive read in a couple of posts that a use case can only have a human actor in it, is this true?

If you can not have a system, how would someone document an automated system using a use case?

---

achen

07-18-2006, 04:35 PM

Ive read in a couple of posts that a use case can only have a human actor in it, is this true?

If you can not have a system, how would someone document an automated system using a use case?

Some people like to have systems as actors. However I prefer not to as the point of a use case is to provide a simple format for business users to diagram out the tasks that they do to accomplish their job. For systems I prefer to use a process diagram. However use cases can work fine for systems.

---

LucyBA

07-19-2006, 02:00 PM

Ive read in a couple of posts that a use case can only have a human actor in it, is this true?

Definitely they can be actors. I think the system in the use case is actually an actor. I have read conflicting things on this, indicating there is a split opinion on whether the system you develop is an actor or not, so I am sure some will disagree with me.

I also think you can have a user interacting with multiple systems in a use case. You can even have a user interacting with a system that interacts with another system. Though to achen's point, that isn't always the best way to format the information.

---

joe

07-19-2006, 02:05 PM

I think you can make anything an actor and you can describe anything in a use case.

The real question is - is this the best way to present the information? I think by trying to shoehorn this description of interaction into a use case, you are missing out on what they should be used for.

In other words, I totally agree with achen's post and don't really have anything original to add. :)

joe

---

rcauvin

07-19-2006, 09:25 PM

Ive read in a couple of posts that a use case can only have a human actor in it, is this true?

If you can not have a system, how would someone document an automated system using a use case?

An actor is a role. Anything can play that role, whether a human, another kind of animal, or another system.

---

joe

07-20-2006, 05:10 PM

An actor is a role. Anything can play that role, whether a human, another kind of animal, or another system.

I agree with this but I think it is important to not use the use case method to describe the actions of all kinds of actors in all cases.

joe

---

kwiegers

07-22-2006, 09:02 AM

Ive read in a couple of posts that a use case can only have a human actor in it, is this true?

If you can not have a system, how would someone document an automated system using a use case?

An actor is some entity outside the boundary of a system that interacts with the system for the purpose of accomplishing some valuable goal. So the "system" we're talking about cannot itself be an actor, because the system isn't external to itself and won't be interacting with itself in this sense. However, actors can be humans, other software systems, or hardware devices.

I agree that use cases are not always the best way to try to represent requirements. For real-time systems involving hardware devices, for example, an event-response table is often a better way to describe the system's behavior than trying to force-fit everything into a use case. Different kinds of nails need different kinds of hammers.

---

REQ

07-23-2006, 03:38 PM

I think it's not wrong to describe external or even internal system but call this Agents and not Actors. After all, they are a part of your functional requirements.

That's your use case.

If something isn't part of an interaction with an external actor, no one will ever know whether it's implemented or not.  That's why

1. The system can't be its own actor. "A" system can be an actor, but not "the" system.
   
2. Postconditions are evil. Any postconditions must show up in some use case (possibly as preconditions), otherwise there's no way to know whether they've been met. Anything else is sneaking design into the requirements.
   

One of the questions you need to keep asking is "is this really the requirement, or is it a presumed realization?" Leave design to the developers.

 

---

发信人: bakkhos (笨瓶子·喜欢乌咪·代替月亮惩罚你～:), 信区: SoftEng       
标  题: 定时器在用例图里是不是一个角色？
发信站: BBS 水木清华站 (Sun Aug 12 00:37:37 2001)

摘自《非程序员》第一期

定时器在用例图里是不是一个角色？
Straybird：
假设一个用例是“查询设备状态”，角色是“设备”，每隔一定时间系统开始执行“查
询设备状态”这个用例。但是用例应由角色启动的，而“设备”这个角色只是被动的，
这个用例实际上是定时器启动的，定时器应当是角色。可是定时器是系统边界以内的对
象，不应是角色。是不是可以把时间看作角色，定时器作为对应角色的主动对象，这样
理解是不是就符合模型了？
刚开始学习用UML 做分析，许多地方不知理解的对不对，希望大家答疑解惑
worship：
我觉得定时器应是一个守卫条件，不应该看为一个角色。“查询设备状态”用例由其他
角色激活，然后启动计时器"守卫"对被动角色“设备”的访问。
Ms.OO：
角色应该是时间。角色有几类：用户，外系统，时间，所以，角色应该是时间。
“是否角色”与“是否在系统内表示”并无关联，例如，一个顾客上网站买东西，顾客
是角色，但系统内也会有“顾客”类。
角色是角色，它在系统外部工作，它可以映射系统内的某个类，也可以什么也不是
straybird：
多谢两位指点。从状态图上理解，把定时器作为守卫条件就很合理了，这样启动系统时
，用例激活，守卫条件满足时，执行用例，启动系统的操作员是激活用户的角色，是这
样吗？把时间作为角色也应该是合理的，只是这个角色有点抽象，呵呵。


--
有人认为：“解决问题的高手是天生的，而不是后天造就的。有些人拥有此技能，有些
人则没有。它是一项天生的创造性的技能…是教不会的。”
但事实上，成功解决问题很大程度上取决于系统的和受过训练的思考方式，这种技能能
被任何一个有天赋的人所掌握。结构化的方法会促进灵感和创造力-而不是阻碍它。


※ 来源:·BBS 水木清华站 smth.org·[FROM: 166.111.166.223]