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

11 Comments

  • Michael

    Reply
    3. April 2012at16:08

    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.

    Michael

    • 4. April 2012at07:42

      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?

      Tim

      • Michael

        Reply
        4. April 2012at09:45

        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,
        Michael

  • Martin Lokietsch

    Reply
    4. April 2012at13:06

    Will the icons get published for general usage?

    • 4. April 2012at13:21

      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://model-based-systems-engineering.com/download

      Tim

  • Markus Schacher

    Reply
    15. April 2012at06:01

    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

    • 15. April 2012at15:36

      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.

      Tim

  • Markus Schacher

    Reply
    16. April 2012at09:12

    Tim,
    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,
    Markus

    • 16. April 2012at10:59

      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.

      Tim

Post a Comment