The Death of the Actor
The technical term System is relative and depends on the viewpoint. From one viewpoint an entity is a system, from another one it is a subsystem or an external system. It is a role that is applied to an entity. You loose this flexibility of changing the viewpoint if you model a system context with SysML and the model elements Block (for the system) and Actor (for the users and external systems). By definition, the model element Actor represents an external entity and could not be a system in another viewpoint. That’s often a problem in system modeling. On the other hand, a system context is a key artifact that could not be skipped. I propose to keep the concept of system actors and to count out the model element Actor in system modeling. Use stereotypes like <<user>> or <<external system>> to manifest the concept and specialize them from the SysML element Block instead of extending the metaclass Actor.
The icon for the actor like a cuboid for external systems or a sticky man for users are defined at the stereotyped element. Therefore a system context diagram with actors based on the model element Block looks the same as with actors based on the model element Actor. In addition, you gain the opportunity to model ports and parts at the actors, e.g. to get a more detailed description of the actor/system-connection.
I had the same idea a while ago (actually I did this with classes in UML, because my tool didn’t support SysML then). But that left me with another problem: I wanted to use the actors in use case diagrams, like you did in your book: there’s the actor “Kunde”, who is part of the system context and also connected to the <> Kfz öffnen. But – at least as far as I know – you can’t connect use cases to blocks, only to actors.
So how do you solve this problem? You certainly want to use the same model element in all diagrams so that you can easily navigate between all the views with the actor, no matter which kind of diagram it is.
Typically a use case is associated with an actor model element. However it is not forbidden that a use case has associations to other elements, too. The UML specification says: “Use cases may have other associations and dependencies to other classifiers.” A block in SysML is a special kind of a classifier. So there are no formal problems.
Do you use a modeling tool that forbids the relationship?
thanks for the clarification. And thank you very much indeed for the quotation of the spec. I’ve been looking for an information like this in the spec, but I missed it somehow.
Yes, I use a tool that only allows actors to be associated to use cases. I could use a thing called “Generic Connector”. But this isn’t as powerful as a real association. I’m using Visual Paradigm’s Agilian 4 (which has a quite good support for SysML in the latest version).
I will send Visual Paradigm a reference to the page in the spec with the statement you quoted. They usually fix this kind of problems within a day or two.
Will the icons get published for general usage?
There are different versions of the icons. The original version is from my book. I could provide these icons if you like. Which format do you prefer?
The diagram in this blog entry is from the modeling tool MagicDraw. MagicDraw has a SYSMOD plugin. They’ve developed a variant of my orginial icons and added some more, e.g. the stakeholder icon.
Another version is included in the SYSMOD plugin for Enterprise Architect. Both plugins can be found in the download section: http://mbse4u.com/download
sound great – I’ll prefer the jpg format.
You find a ZIP archive with the SYSMOD actor icons on the download page: http://www.model-based-systems-engineering.com/download.
Hi Tim, I am sometimes struggling with the term actor (whether they represent humans or technical systems) : in some cases they are not actively acting towards the system to be modelled, but just passively informed by the system. Nevertheless it is important to model them as they use an interface of the system. In these cases I am inclined to call them “passors”…
Best regards Markus
the word “actor” has two meanings: to be active and playing a role. Most important is the meaning that an actor is a system or human that plays a role in interaction scenarios with the system under development. Although the “passor” doesn’t start the interaction he plays an active part. In practice actors are often seen as external entities that must trigger an interaction with the system. I’ve seen many (incomplete) system context diagrams without the passors.
You can mark actors and passors with directed associations: from the actor to the system, and from the system to the passor.
I think I agree with you (but I have to read first what I am writing before beeing sure ;-). My point is two-fold:
1. “passors” are important and one should modellers give methodological advice not to oversee them.
2. “passors” in contrast to “actors” often have no intention towards the system in context. Particularly in technical systems, “passors” are often passively controlled be the system (although this may involve bi-directional communication) whereas “actors” usually actively control the system. I think this is a very important distinction.
That’s exactly my point of view. The system is primarily designed for the actors (and the stakeholders). There could be a crucial dependency to the passors. The whole system doesn’t work without them or fails when a passor changes it’s behavior. Typically they are out of the control of the system project and could change or be removed at any time.
I like actors for use cases but blocks <> for the logical architecture (and IBDs for interfacing). Ideally, I would like them to be the same thing or at least related. In this regard I have noticed I can do a couple of things but not sure of the ramifications.
1. I can put an actor and link to use cases via associations – normal approach. But I can also drop on the <> block representing the actor and associate with the actor (stick figure). Could there be any ramifications of doing this? Or
2. I have noticed I can drag the actor (stick figure) onto a block and it puts it as a property. You can’t do the reverse. Again, could there be any ramifications of this?
By ramifications I mean does it mess me up later as I move into activity diagrams, allocations, or simulations?
Actors and blocks are both classifiers, and classifiers can type properties. Therefore, a block can own a property typed by an Actor. You could use this approach to define a system context: the block represents the system context and it contains properties typed by the actors and one special property typed by the system block itself. Then, you can define the connections and other details in an internal block diagram of the system context block.
The model element Actor can have structures. Therefore, nothing happens when you drag the block onto the actor. It seems that your modeling tools strictly follows the rules of SysML. Great!
I don’t understand your first point. Can you clarify it a bit more? After all, who is finally associated with whom?
I am very interested in what you say in your blog post: an entity can be a system or an external system, depending on the viewpoint. But how does that work in practice? Within the same SysML model, can a block have two different stereotypes depending on the viewpoint?
Greetings and many thanks!!
A block can have more than one stereotype. SysML does not have any mechanism to switch on/off stereotypes depending on a viewpoint.
A pragmatic solution would be to set the guidance that a system part property that is connected with another system part property always means an interaction between a system and an actor. In that case, you would not define an additional actor stereotype for the appropriate system blocks.