How to model an extended system context with SysML

How to model an extended system context with SysML

Extended system context with SysML - FFDS example

The extended system context describes the system interfaces and the detailed connection to the system actors and to the internal parts of the actors. In the previous post How to model a simple system context with SysML I’ve written about system context in general and the simple edition of system context that is simply spoken just a list of external systems and human actors who interacts with the system under development.

The extended system context adds information about the interfaces at the system boundary and more details about the system actors. While the simple system context is an easy-to-read-for-everyone diagram, the extended system context diagram is more specific for the engineers. Note that you need blocks as actors to specifiy internals or interfaces of the actors. See Death of the Actor for details.

Extended system context with SysML - FFDS example

Extended system context with SysML - FFDS example

The diagram is an internal block diagram (ibd). To create such a diagram you need a special system context block. It is not part of SysML, but defined as a stereotype in the SYSMOD profile. The system context block owns the system and all its actors. The diagram above is an ibd of the system context block. The diagram below shows the definition of the block:

Extended system context definition with SysML - FFDS example

Extended system context definition with SysML - FFDS example

In practice I prefer to use both system contexts. The simple system context is easy to create, a good starting point and perfect for the communication with the stakeholders. The extended system context is necessary for the definition of the system interfaces and the integration of the system in its environment.

 

6 Responses

  1. Hans-Uwe Brackel says:

    GreetingsTim,
    the “Cookbook for MBSE with SysML” (SE2 Challenge Team) makes extensive use of the extended system context modelling. It also introduces context variants.

    What would you see as being the benefits of system context variants over a just slightly more complex but singular system context? Or to re-phrase the question: what situations could indicate that the introduction of context variants may lead to a cleaner more understandable system model. Variants themselves represent a certain level of complexity, so there might be a trade-off between adding complexity through the use of variants vs. making a singular system context more comprehensive.

    Kind regards,
    Hans-Uwe

  2. Hi Hans-Uwe, the kind of modeling depends on the degree of variation between the systems.

    If there is no variation, it is a single system.
    If there is little variation, I recommend to do no variant modeling, but to describe the variation in a pragramatic way in the model.
    If there is variation, I recommend to do variant modeling.
    If there is huge variation, I recommend to create separate models and extract the common parts in a model library.

    Indeed variant modeling increases the level of complexity. It costs much effort and is only useful if the benefit exceeds the effort. Every euro you spend in modeling must increase your profit by 2 euro. Typical benefits are trade-off analysis and the managing of product families.

    Cheers,
    Tim

  3. Charles White says:

    In your example, you are displaying all Elements without names, are you simply not showing the names? or have you intentionally decided to not give the elements names? If so, why?

  4. The property elements have no names. I have only one property of each type in the context model. So, the name does not help to distinguish between different properties like front:Wheel and rear:Wheel.

    An advantage of having no names is that you have more space on the diagram. A disadvantage is that – depending on the modeling tool – it can be hard to identify the elements if presented in drop-down lists.

    Which names would you propose for the property elements in my example? For example, for the Operator property.

  5. Charles White says:

    Thanks for your reply.

    While it is true, that per Definition the name of a Property is optional, I have found it rather incovenient not to define names since it is more natural to define a name for something that is crated/instantiated. Otherwise how would the Element creating the instances address its own creations if they do not have names? I assume you wouldn’t define a Value Property without a name, so why would you do that for Part Properties?

    I understand the reason for saving space, but most tools allow you to display the name only, so specifying a name does not necessarily mean, the diagram will be more difficult to read.

    Since Instances/Objects/Parts are the actual elements comprimising your context/system and not its definitions (blocks) , I have found it a good compromise to address the parts with the keywords “the”, “a”,”an”, when the selection of a name seems difficult due to already self explanatory name of the Block.

    For example:
    theFFDS:FFDS
    anOperator:Operator

  6. That makes sense. I like your naming convention. Less readable, but a tool can automatically set a (default) name: add a pre- or postfix “prop”, e.g., operatorProp:Operator.

    I think names like o:Operator, or operator:Operator, are useless or confusing.

    Another advantage of not using any names is that you save some time during creating the model elements 🙂 However, I agree that a clean model should have names.

    Thanks for your input!

Leave a Reply

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