NoSE 2013 – A Report from the Tour

Posted on 19. April 2013 by Weilkiti

From April 15th to April 17th I did the first Nordic Systems Engineering Tour. I’ve initiated the tour together with Erik Herzog from Saab in Sweden. NoSE is a 1-day conference event in Hamburg, Copenhagen, and Stockholm in 3 days. The purpose of the events is to promote Systems Engineering and also to strengthen the links between the German and the Swedish chapters of INCOSE and to support the Danish systems engineering community. It was great fun and very experiencing. The tour speakers including me came from Germany, Sweden, Lithuania, and Spain. In addition we had local speakers at each venue.

We’ve started with a smaller audience in Hamburg. oose was the host of the day and sponsored the room and catering. The talks were about

the SYSMOD-Zigzag pattern,
a reflection of 15 years of Systems Engineering
verification & validation of the mission system of the Frigate F125 (local talk)
Ontology-Based Systems Engineering, and
best practices for modeling.

After a very interesting day the tour speakers headed to the central station for the train to Copenhagen. During the trip we had time to relax and to discuss our systems engineering experiences. At midnight we arrived in Copenhagen.

Our host in Copenhagen was the hearing aid company GN ReSound. This time the audience was 5 times larger than in Hamburg. Personally I’ve learned a lot from all the discussions around our talks. The local speaker Henrik Balslev talked about RDS coding principles. I didn’t know RDS (and Henrik) before. I’ve discussed the relationship of RDS and SysML with Henrik. We’ve agreed to elaborate it further. Both of us don’t know any work that covers RDS and SysML.

After the conference the Danish systems engineering community met to discuss the opportunities to establish a Danish local chapter of INCOSE. The NoSE tour was a perfect platform for them and good marketing for the value of chapters.

Again the tour speaker headed to the central station for the train to Stockholm. A few minutes after Copenhagen the train crosses a great systems engineering example – the Øresund Bridge from Copenhagen to Malmö. The bridge is a case study in the INCOSE handbook. At midnight we arrived in Stockholm.

Our host in Stockholm was the KTH, the Royal Institute of Technology. In addition to the talks of the tour speakers we had a local talk from Erik Herzog about system views and system properties and a talk from Pär Hammarström about product lines in practice.

It were three intense days. We all agree that it is worth to do the tour again in 2014.

What is a model?

Posted on 15. March 2013 by Weilkiti

Could you easily answer this question? Is a document a model? Why not?

Most references define a model or properties of a model like this

A model is a representation of something. It captures not all attributes of the represented thing, but rather only those seeming relevant. The model is created for a certain purpose and stakeholders.

That definition includes text documents. They are also a representation of something and do not capture all attributes of the real thing. However I don’t feel comfortable to call a document a model. If a document is a kind of a model why everybody talks about the shift from document-based to model-based systems engineering.

We must specialize the common definition of a model for systems engineering. I define two additional rules for the MBSE model definition.

The first rule clarifies a typical misunderstanding. MBSE is not only about SysML. MBSE is also about methodologies. And looking on the model you can use many different models and model languages in a MBSE environment. Although SysML is the most important modeling language for MBSE.

The first specific rule for the MBSE model definition is:

[MODEL1] A model could consist of many model repositories.

I separate the terms model and model repository. For example a MBSE model could consist of a requirements model repository (e.g. IBM Rational Doors™) and a SysML model. From the users perspective it is one model. It doesn’t matter that the model data is located in different repositories. You need tool chains to link several model repositories, i.e. bridges, adapters, or a model bus.

The first rule still does not exclude documents from the model definition. A model is build with a model language. Typically the users focus is on the diagram and notation – the so called concrete syntax. Much more important is the world behind the concrete syntax. There is the abstract syntax and semantic of the model elements. Simply spoken the data structure and the meaning. The abstract syntax is the enabler to do computer-based analysis, simulation, traceability and so on. That’s the difference between a model and a drawing.

The second specific rule for the MBSE model definition is:

[MODEL2] A model is build with a model language with an abstract syntax that covers the basic concepts of MBSE like requirements, structural system elements and functions.

SysML is such a modeling language. It has elements like requirements, blocks, activities, and so on. The language “knows” MBSE concepts. A typical text document does not fit to this rule. Even if it has a abstract syntax, the syntax does not cover MBSE concepts. Of course it is possible to specify a textual language with an abstract syntax for MBSE concepts. In that case a text document written with “textual SysML” is a model.

The two rules [MODEL1] and [MODEL2] in addition to the common definition of a model are in summary the

Definition of a MBSE model

A model is a representation of something. It captures not all attributes of the represented thing, but rather only those seeming relevant. The model is created for a certain purpose and stakeholders.

[MODEL1] A model could consist of many model repositories.

[MODEL2] A model is build with a model language with an abstract syntax that covers the basic concepts of MBSE like requirements, structural system elements and functions.

I could think of more aspects like graphical representations, view concepts, simulation, and so on. However they are all optional and not mandatory.

Two Kinds of Patterns

Posted on 7. February 2013 by Weilkiti

Did you know that you use patterns every day? It’s a very powerful mechanism and much more powerful when they are explicit and known.

A pattern describes a proven solution for a problem. Every experienced engineer has a huge set of patterns. Think about your daily work. If you must solve a problem that you’ve solved successfully before, you will remind your solution and apply it again. If you describe your solution in a general and reusable way, you’ve made your experience explicit and persistent. Voila! You’ve found a pattern.

Christopher Alexander described patterns for building architectures (his pattern book), Erich Gamma & Co. described patterns for software engineering (their pattern book) and Robert Cloutier describes patterns for systems engineering (his work ).

I’d like to put a focus on another kind of a pattern. In system modeling the graphical representation of the model data is an important part. It definitely makes a difference how you present your data. The human brain looks for graphical patterns and not for all the little details. That makes life much easier. For example you can change the letters in a text while keeping the pattern structure and you could still read the text:

Mdoel Baesd Setmsys Ennneigierg mekas my procjets mroe ecffetive.

Cool, isn’t it. Similar things happen when you look at SysML diagrams. You’ll see graphical patterns. Unfortunately such patterns are not well known and described. Here’s a huge potential to be more effective.

For example it makes a difference if you layout a product tree in a block definition diagram top-down, bottom-up or in a non-tree layout style.

Product Tree Forest Fire Detection System Top-down Style

Product tree (top-down)

Product Tree Forest Fire Detection System Bottom-up Style

Product tree (bottom-up)

Product Tree Forest Fire Detection System Non-tree Style

Product tree (non-tree style)

I prefer the top-down layout. It emphasizes the break down of the product (Product Breaddown Structure (PBS)).

I know that there is lots of information about human pattern reception in general. But I know no paper or book that combines those results with system modeling. I appreciate any hint.

Finally some guidelines/facts:

Typical reading direction is from top to down, from left to right. It is different in some cultures.
A diagram should not contain more than 7 main elements.
A diagram should have a printable layout (A4 or letter format).

The Nordic Systems Engineering Tour

Posted on 29. January 2013 by Weilkiti

I proudly present the Nordic Systems Engineering Tour – a one-day conference event at three different locations in three days. From Hamburg via Copenhagen to Stockholm.

Together with Erik Herzog I had the idea to boost systems engineering in northern Germany, Denmark, and Sweden. Why these countries? The answer is easy: Erik lives in Sweden and I in the north of Germany. Denmark is located in between.

Of course that’s not the only reason. The purpose of the events is also to strengthen the links between the local chapters of INCOSE. The intention is to have four talks that are repeated at each venue complemented by a number of talks held locally at each venue.

Host of the tour is the German and the Swedish chapter of INCOSE. Mark your calendars for April 15th (Hamburg), April 16th (Copenhagen, and April 17th (Stockholm).

More details, registration, and call for presenters: http://www.nordic-systems-engineering-tour.com

Criminal Scene Investigation: Death of the Actor and the Use Case

Posted on 14. January 2013 by Weilkiti

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 is defined relative to a system. Since every system is part of a larger system an actor of one system could be a part of another system. You should separate the model element that represents the physical entity from the model element that represents the role of the entity like actor or part. The SysML/UML model element Actor combines both. I propose to use a block (or class in UML) to represent the entity and stereotypes to represent the role. The figure below shows a context diagram without the Actor element. The actors are modeled with the Block element and stereotypes with symbols for the actor categories.

System context without actor model elements

System context of a Forest Fire Detection System without actor model elements

The model element UseCase was also victim of a attempted murder. The Activity was the murderer. However 30 comments about the killing report saved the life of the UseCase.
My conclusion of the discussion is that I’m still convinced that you don’t need the SysML/UML model element UseCase if your modeling process directs to model the details of a UseCase with an Activity. Remember that the concept UseCase is still alive. In practice the separation of concept and model element is not well known and it’ll lead to misunderstandings if you try to do use case modeling without use cases. I fear that the problems exceed the benefit. So be careful if you kill the UseCase element. The problems will catch you… The figure below shows a use case diagram without Actor and without UseCase model elements. The use case Detect and report fire is the model element Activity. You see it could work in practice.

Use case diagram without actor and use case model elements

Use case diagram of a Forest Fire Detection System without actor and use case model elements

Most popular UML modeling tools

Posted on 7. January 2013 by Weilkiti

Although UML is a modeling language for software, it is sometimes also used in systems engineering projects. Since SysML is a kind of a profile you can define your own SysML stereotypes to use a UML modeling tool for SysML modeling.

If you can’t see the list of popular UML modeling tools please click here: http://list.ly/list/2io-popular-uml-modeling-tools

Popular UML Modeling Tools

Listly by Tim Weilkiens

Popular UML Modeling Tools

Vote for your favorite UML modeling tool. There is no "best UML modeling tool". The best tool for project A is another than the best tool for project B. It depends on the different requirements of the projects. This list shows not the best, but the most popular tools if you vote for them. I've added all UML modeling tools I know and a short description taken from the tool vendor web sites. Please let me know if you want to add another one. See http://www.oose.de/uml-tools for a more detailed list.

crowd rank
curated
alpha
newest
queue

Enterprise Architect

Enterprise Architect is a comprehensive UML analysis and design tool, covering software development from requirements gathering through to the analysis stages, design models, testing and maintenance. EA outfits your entire team, including analysts, testers, project managers, quality control staff and deployment team, for a fraction of the cost of some competing products.
Web: www.sparxsystems.eu
12 4
Modelio

The Modelio environment provides integrated support for all the latest major modeling or methodology standards. With their easy and practical extension mechanisms, open source codebase, and support for teamwork, Modeliosoft Solutions are the toolkit of choice for enterprise modeling.
Web: http://www.modeliosoft.com/
5 1
MagicDraw

MagicDraw is the award-winning business process, architecture, software and system modeling tool with teamwork support.
Web: http://www.nomagic.com/products/magicdraw.html
7 4
Innovator Modeling Platform - MID GmbH

Added by Bertram Geck on Jan 10, 2013

Integrated solution, from requirements and business processes right through to application development
Supports open industry standards (BPMN, UML, SysML, SoaML)
Flexible customization using DSLs and profiles
Central model server supports distributed teams
Open architecture and Java/.NET APIs
http://www.mid.de/en/products/innovator-modeling-platform.html
5 3
Astah

Astah is an exciting new way to navigate your business. Whether you are a large corporation or small start up everyday your business is changing, simple meetings and memos don’t cut it anymore. Collaboration is a constant, and with a growing list of technologies that allow you to instantly communicate ideas to your team, you need a way to let your team instantly understand your ideas.
Web: http://astah.net/
1 0
Poseidon for UML

Now Poseidon for UML is based on our Poseidon for DSLs platform. It is a great UML tool with a complete set of diagrams (class, package, use case, state, component, activity and sequence diagrams) and excellent user interface. We provide magnificent improvements in stability, scalability, performance, reliability and customization. We believe this tool has the best user interface in the industry. At the same time, it is an example of what is possible with our DSL platform. UML now is just one of the conceivable DSLs possible with the Poseidon for DSLs platform. A considerable part of the tool is generated from a handfull of models (MDSD). You, as the author of a DSL can simply change these models and by that create your own DSL modeling tool that shares the same user interface and performance characteristics as Poseidon for UML 8.0. Read on for our guiding principles.
Web: http://www.gentleware.com/new-poseidon-for-uml-8-0.htm
1 0
Visual Paradigm for UML

Visual Paradigm for UML (VP-UML) is a UML design tool and UML CASE tool designed to aid software development. VP-UML supports key industry standards such as Unified Modeling Language (UML), SysML, BPMN, XMI, etc. It offers complete toolset software development teams need for requirements capturing, software planning, test planning, class modeling, data modeling, and etc.
Web: http://www.visual-paradigm.com/product/vpuml/
1 0
StarUML - The Open Source UML/MDA Platform

Added by Les DeLashmutt on May 06, 2013

StarUML is an open source project to develop a fast, flexible, extensible, full-featured, and freely-available UML 2.0/MDA platform running on the Win32 platform. The goal of the StarUML project is building a software modeling tool and platform that's a compelling replacement for commercial UML tools, such as Rational Rose, Together, and so on.

MDA (Model Driven Architecture) is a new technology introduced by the Object Management Group (OMG). To get the advantages of MDA, a software modeling tool should support many customization variables. StarUML supports MDA, and provides numerous customization variables.
1 0
UML Lab

UML Lab offers software developers a complete and reliable adjustment of source code and diagrams. For the first time, software architects and developers can make use of the benefits of both worlds: fully flexible modeling and programming.
Web: http://www.uml-lab.com/
2 1
UMLet

UMLet is a free, open-source UML tool with a simple user interface: draw UML diagrams fast, produce sequence and activity diagrams from plain text, export diagrams to eps, pdf, jpg, svg, and clipboard, share diagrams using Eclipse, and create new, custom UML elements. UMLet runs stand-alone or as Eclipse plug-in on Windows, OS X and Linux.
Web: http://www.umlet.com
2 1

View more lists from Tim Weilkiens

The Death of the Use Case

Posted on 13. November 2012 by Weilkiti

After killing the Actor in The Death of the Actor my next victim is the use case. Don’t use Use cases in SysML (or UML) models anymore!

My statement seems to be revolutionary or stupid (or both). Just to be not misunderstood, I’m not against the concept of use cases and actors. I believe that the SysML model elements Actor and UseCase are not necessary and useful. I’ve already explained it for the Actor in my previous post The Death of the Actor.

The definition of the use case in the OMG specification document is free of any method and only explains the language element UseCase. It depends on your modeling method how to use the use case. I use the modeling process SYSMOD which is not very specific, but more a collection of common best practices. In SYSMOD a use case has some additional information like trigger and result or pre- and postcondition. The functional details of an use case are described with activities. A typical use case diagram looks like this (again I use the forest fire detection system):

Use case "Detect and report fire"

And the model structure with the activity behind the use case looks like this:

Model structure use case and activity

The use case contains the activity and both have the same name “Detect and report fire”. So why do we need the use case element? You could add additional information like the trigger and result to the activity element. And you could still create “use case diagrams” with real actors or blocks as actors (see The Death of the Actor):

Use case diagram without use cases

If you are a big fan of the ellipse symbol, create a new stereotype “use case activity” and define the ellipse symbol for it. Then you can’t see any change in the diagram, but you have no actors and use case elements in the model.

Without use case elements

automation scripts on the model are easier to implement (e.g. model checker, document generation, simulation).
you have fewer elements for the configuration management.
you have fewer elements for reviews.
it is easier to navigate through the model tree.

The Actor and UseCase elements are dead! Long life the Use case analysis!

Most popular SysML modeling tools

Posted on 2. November 2012 by Weilkiti

If you can’t see the list of popular modeling tools please click here: http://list.ly/list/23A-popular-sysml-modeling-tools

Popular SysML Modeling Tools

Listly by Tim Weilkiens

Popular SysML Modeling Tools

Vote for your favorite SysML modeling tool.

There is no "best sysml modeling tool". The best tool for project A is another than the best tool for project B. It depends on the different requirements of the projects. This list shows not the best, but the most popular tools if you vote for them.

I've added all SysML modeling tools I know and a short description taken from the tool vendor web sites. Please let me know if you want to add another one.

crowd rank
curated
alpha
newest
queue

Cameo System Modeler (formerly known as: MagicDraw with SysML plugin)

MagicDraw is the award-winning business process, architecture, software and system modeling tool with teamwork support. The SysML plugin retains all capabilities of award-winning MagicDraw architecture modelling environment with System Engineer perspective.

Web: http://www.nomagic.com/products/cameo-systems-modeler.html
9 0
Modelio

Added by Tony Marchand on Nov 04, 2012

The System Architect Solution is dedicated to
system architects working on SysML modeling, UML/BPMN
modeling and requirement analysis.
http://www.modeliosoft.com/en/products/solutions/system-architect-solution-overview.html
7 1
ARTiSAN Studio

Artisan Studio, provides complete support for OMG UML and SysML in a single, integrated toolset. You can create consistent, high quality models for systems and software engineers to communicate requirements, design decisions and alternatives across the entire team, regardless of their location. This enables your team to Work-as-One™, modeling systems and software throughout the entire project lifecycle.

Web: http://www.atego.com/products/artisan-studio/
4 1
Enterprise Architect with SysML plugin

With advanced modeling capabilities, low cost and a wealth of innovative features, Enterprise Architect combined with MDG Technology for SysML is the premier team-based modeling environment for the System Engineer.

Web: http://www.sparxsystems.com/products/mdg_sysml.html
5 4
IBM Rhapsody

IBM® Rational® Rhapsody® Architect for Systems Engineers is an integrated, model-driven systems engineering environment for complex projects. It uses Systems Modeling Language (SysML) and Unified Modeling Language (UML) to enable rapid requirements analysis and visual, model-driven design.

Web: http://www.ibm.com/software/rational/products/rhapsody/sysarchitect/
4 3
Agilian

Easy-to-use software engineering diagramming tool that supports all contemporary modeling notations. Agilian provides flexible modeling environment for agile software development practitioners to communicate effectively with UML, BPMN, ERD, DFD and mind map. With SysML support: Visualize your system hierarchy. Gain insight to interconnections between system components.

Web: http://www.visual-paradigm.com/product/ag/provides/sysml.jsp
1 0
TOPCASED

Topcased is a software environment primarily dedicated to the realization of critical embedded systems including hardware and/or software.

Web: http://www.topcased.org
1 2
Papyrus 4 SysML

Papyrus is aiming at providing an integrated and user-consumable environment for editing any kind of EMF model and particularly supporting UML and related modeling languages such as SysML and MARTE.

Web: http://www.eclipse.org/modeling/mdt/papyrus/
1 4
Astah

Following the guidelines for SysML laid out by OMG, Astah SysML represents a broad use platform perfect a wide variety of modeling tasks such as; specifying, analyzing, designing, verifying any number of complex systems. These models are applicable in an even wider variety of systems driven fields including; hardware, procedures, facilities, personal information, software, and, of course, many more.
Web: http://astah.net/editions/sysml
0 0
Innovator Modeling Platform - MID GmbH

Added by Bertram Geck on Apr 05, 2013

Integrated solution, from requirements and business processes right through to application development
Supports open industry standards (BPMN, UML, SysML, SoaML)
Flexible customization using DSLs and profiles
Central model server supports distributed teams
Open architecture and Java/.NET APIs
0 0

View more lists from Tim Weilkiens

Why MBSE matters?

Posted on 10. October 2012 by Weilkiti

Many companies deal with the challenge to introduce MBSE. As a consultant for MBSE I often ask my customer about their objectives to apply MBSE techniques. The answers are more or less the same: the systems are getting more complex and at the same time we must decrease costs and time-to-market and increase the quality.

These are good arguments to change development processes and to apply MBSE. However these arguments are not new. I would had heard the same arguments 20 years ago. Today something is different. There is an enormous pressure on the companies that require major changes.

We are at the beginning of a new era characterized by global cooperations, networking, and global markets with customers, users, and competitors from different cultures with completely different mindsets. We develop complex systems with complex development organizations for complex markets.

The methods & tools to develop these systems must follow the systems challenge curve. The curve for the methods & tools is below the system curve. The gap is filled by the intelligence of the engineers (“project heroes”). Of course we are always better than our methods & tools allow. But the gap is getting wider and wider. Many organisations already feel the pain from the gap.

Systems Challenge Curve

I think there are two fundamental techniques to shorten the gap. Agile methods and Modeling. Agile methods focus on the – often home made – complexity of the organisation to develop a system. Modeling focus on the inherent complexity of the system itself. That’s why I believe that it is important for many companies to introduce MBSE.

Hidden feature of SysML – Activity Trees

Posted on 10. September 2012 by Weilkiti

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 FFDS is the example I often use in this MBSE blog.

Use case "Detect and report fire" (click to enlarge)

Use case activity "Detect and report fire" (click to enlarge)

The activity is a behavioral view of the usage of system functions in a specific context. It is possible that one of the functions is also used in another context, e.g. the function “Warn operator” is also part of the use case “Simulate FFDS operation”.

What’s missiing is a structural view of the system function definitions like the block definition diagram for system parts. And the SysML activity tree is exactly the missing piece. The following figure shows the activity tree of our use case activity.

SysML activity tree (click to enlarge)

The boxes are the activities and the relationship between the boxes describes that an activity is called in the context of the upper activity. Attention: The tree shows a call hierarchy and not a ownership hierarchy. The tree does not show the control flow information you can see in the activity diagram.

Activities vs. Actions

Activities and actions are different model elements in SysML. The activity tree shows the activities (that’s why it is called so). The steps in an activity diagram are actions. A CallBehaviorAction is an action that calls an activity. You find detailed information about the language SysML in my book “Systems Engineering with SysML”.

To get trees of all steps modeled in activities you must create an activity for each action. All actions are CallBehaviorActions. Most modeling tools provide a good workflow to create these elements.

You could extend the SysML activity tree by adding information about the input and output data of the activities. The type of the data is associated with activity in the tree. You can’t differentiate input and output and can’t see the object flow.

SysML activity tree with object nodes (click to enlarge)

The SysML activity tree gives you a very good structural overview about the system functions. Functions are the core of each system. So it is of value to know them well. The FAS method (functional architectures for systems) also uses the SysML activity trees. You find more about FAS on the website www.fas-method.org.

Comments and Questions are welcome.

Model Based Systems Engineering

MBSE in a Blog

NoSE 2013 – A Report from the Tour

What is a model?

Two Kinds of Patterns

The Nordic Systems Engineering Tour

Criminal Scene Investigation: Death of the Actor and the Use Case

Most popular UML modeling tools

Popular UML Modeling Tools

Enterprise Architect

Modelio

MagicDraw

Innovator Modeling Platform - MID GmbH

Astah

Poseidon for UML

Visual Paradigm for UML

StarUML - The Open Source UML/MDA Platform

UML Lab

UMLet

The Death of the Use Case

Most popular SysML modeling tools

Popular SysML Modeling Tools

Cameo System Modeler (formerly known as: MagicDraw with SysML plugin)

Modelio

ARTiSAN Studio

Enterprise Architect with SysML plugin

IBM Rhapsody

Agilian

TOPCASED

Papyrus 4 SysML

Astah

Innovator Modeling Platform - MID GmbH

Why MBSE matters?

Hidden feature of SysML – Activity Trees

Activities vs. Actions