The Death of the Actor

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.

SYSMOD Profile - Actors

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.

SysML system context example


17 Responses

  1. Michael says:

    Hi Tim,

    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.


    • Hi Michael,

      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?


      • Michael says:

        Hi Tim,

        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.

        Thanks again,

  2. Martin Lokietsch says:

    Will the icons get published for general usage?

  3. Markus Schacher says:

    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

    • Hi 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.


  4. Markus Schacher says:

    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.

    Best regards,

    • Hi Markus,

      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.


  5. Derek Rogers says:

    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?

    • Tim Weilkiens says:

      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?

  6. Luis says:

    Hi Tim!
    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!!

    • Tim says:

      Hi Luis,

      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.


  7. Moritz says:

    Hi Tim,

    I’d like to tie in with the “passors” topic (even the discussion took place a decade ago). In your blog entry itself you don’t talk about “passors”. When trying to differentiate the actor and passor in the shown context I would assign the mentioned parts from the external system “Car” to the category of passors. The remaining non-human systems (reservation and billing system) would be Actors in this case. Am I correct with this assignment?


    • Tim Weilkiens says:

      The context in the post does not distinguish between actors and passors. Actually, SysML does not know the term “passors”. In SysML, all external entities that interact with the system are actors. If you introduce the term “passors”, you must also adapt the definition of the term “actor”. So, let’s define the terms:

      Actors and Passors are external entities of a system that interact with the system. An Actor is an external entity that has an interest in the interaction or starts the interaction with the system. A Passor is an external entity that has no interest in the interaction or the system starts the interaction. Some external entities are actors and passors at the same time according to this definition.

      If you would like to explicitly model the distinction between actors and passors, you could, for example, add a property isPassor:Boolean to the stereotypes for external entities.

      Coming back to your question: I would assign the Car, but also the Reservation and the Billing system to the Passor category.

Leave a Reply

Your email address will not be published. Required fields are marked *