How to use full ports and proxy ports and what’s the difference? SysML changed the way how to model ports with version 1.3 in 2012. (see also What's new in SysML). Besides others the new version 1.3 introduced the concept of full and proxy ports. Full port A full port is an element of the system. It is part of the bill of material (BOM) and could - as any other part - specify behavior and an internal structure. The type of...

The previous posts Death of the Actor and Death of the Use Case reported about two serious killings in the modeling scene. Many eyewitnesses commented the report. Now it is time for a short review. First the good news: The concepts Actor and Use Case survived the massacre. I’ve seen them still alive and very active in many projects. Sadly the SysML/UML model element Actor is dead – rest in peace – and the modeling element UseCase is in intensive care. The concept Actor...

Please click here: http://list.ly/list/23A-popular-sysml-modeling-tools Unfortunately I have technical problems with the list.ly Wordpress plugin and can't show the list embedded in this blog post....

It is very well unknown and I know only a single modeling tool that explicitly supports it: the SysML activity tree. Although it is very useful and supports common systems engineering practice. What am I talking about? You may know use cases and activities to describe the use case flows. Simply spoken they describe the functions of the system from the user perspective. The following figure shows a use case and the activity of a forest fire detection system (FFDS), The...

Models do not only contain the "real" artifacts for your system, but also additional auxiliary information like notes, issues, images, and so on (metadata). It is very useful to store such information at the place where you need or create it. Switching from one tool to another is a hurdle that prevents people from looking up things or creating ones. As a result many little deficiencies occur that lead in summary to less quality, more effort and costs. My previous post...

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

The system context defines the system boundary and all system actors - humans and external systems - that interact with the system under development. It is one of the most important parts of the system model. Many artifacts of the system specification and architecture are relative defined to the definition of the system. Every system behavior and structural element is completely inside the system and not covered by any system actor. If you change the system boundary, you must also change the...

On the first view it seems to be simple to define the package structure of a SysML model. However you'll often get problems with a implicit built structure. A model has many - orthogonal - aspects and abstraction layers that could be mapped into the package structure, e.g. domain, modeling, or organizational aspects. You can easily mix up the aspects. The MBSE Challenge Team SE^2 for Telescope Modeling describes a best practice for the package structure in the MBSE Cookbook. The...

Many systems exist in different configurations. A product line, a custom product or different designs for trade-off studies. The current version 1.2 of SysML doesn't provide explicit built-in language constructs to model variants. The profile mechanis of SysML can be used to extend SysML with a concept for variant modeling. I've defined a simple variant profile that consists of three core stereotypes and some additional optional extensions. The core stereotypes of the SYSMOD variant profile are: A variation point marks a core element...

A message from the  INCOSE Telescope modeling challenge team: The INCOSE Telescope modeling challenge team releases version 1.1. of its MBSE plugin for MagicDraw with SysML: https://sourceforge.net/projects/mbse4md/ Support for more productive Model Based Systems Engineering, following the recommendations in the Cookbook of the INCOSE SE2 Challenge team. The Plugin for the MagicDraw modelling tool provides support for model based document generation which ties together system model and documents to keep them up to date and consistent, using a AWYSIWYG editor in MagicDraw. It provides basic...