Modeling Myths by Michael Chonoles

Michael Chonoles, the author of “UML 2 for Dummies”, talks about “Modeling Myths” – damaging misconceptions people have that prevent them from adopting modeling in their projects.

Introduction to Modeling Myths

Modeling Myths are these damaging of misconceptions people have that prevent them  from adopting modeling or UML on the projects.

Do I Really Need to Model Everything?

Do I model the extra information? The redundant information? It seems very expensive, very time consuming and needs too much resources. And the problem is, that they are really right. People who think that modeling everything is expensive are quite correct. But luckily, you don’t have to model all of it. You just you have to model “the biggest risks”.


Every project, every team has different risks. You will hear some examples you might find similar on your project.


For example, you might find that not everyone understands the domain or the problem space. So, what you might use is conceptualization and domain-style modeling of your Class Diagrams or State Diagrams, so that it shows what the real world is like.


You might have problems where people on your project don’t know what the purpose of the project is. What are the things, what are the problems that you are solving. Well, use UseCases and Actors to show what you are trying to accomplish.


Sometimes you have a problem with the organization. People don’t quite understand what tasks they are assigned, and who’s doing what. Use Package diagrams, or sometimes Use Case diagrams to help you split them up into individual tasks and problems to work on.

-Implementation Approach

Sometimes you find that there are implementation issues. People don’t really get a feel for how this thing might be implemented. Use Sequence diagrams or Collaboration diagrams to help you understand how that might work together.



Don’t model things like Legacy Code if it’s well understood. Don’t model statemachines of simple on/off switches because they’’re trivial, they’’re on or off –and it’s a waste of time.

Don’t model parts of the system that are already known or similar to the other parts. If you model it the first time, and the second time around, you are modeling a different part of the system that works like the first, just reference the first one.

Don’t model anything that doesn’t really address a risk. Spend your time modeling where there’’s a big return on investment.

Let’s give an example that might help you understand.

Confusing Model

You can see here some modeling that is a little confusing. If everyone in the project is working on different parts, you are going to come up with something pretty confusing and hard to understand, and hard to see if there is any problems. So, what we are going to have to do is take some of this stuff out.

There’s some stuff that’s “already known“. We’ll, take that out. We don’’t need to model that.

But there’’s more. It’’s still confusing. Let’s take out stuff, and not model anything doesn’t address a need. Let’s get rid of that.

It’’s still confusing, still hard to see. What else could we avoid spending or wasting money, and time, and resources on? We could have not modeled the “Unwanted Information“.

So now, things are improving. What else could we take out? Things that are trivial like the statemachines, the easy stuff. Let’s get rid of the easy stuff. And we are getting better.

And get rid of “Useless Detail” . So what’s left is the biggest risk.

But now we can see there’s some problems. Things aren’t straight. That’s one of our problems. We didn’t do it really right, so we can straighten this.

And then we see one more problem left. The serious one. We spelled “risk” incorrectly. So now we fixed that. If we would have started with just the area of biggest risk, we would have addressed our problems and not spent our resources on things we didn’t need.

Thank you Michael for this great topic!


Posted in Agile, Kenji, UML | Leave a comment

Updated to Astah Professional / Community 6.9 yet?

It’s been a very exciting week since our big announcement with news below a week ago. We’ve been getting many positive feedback on the latest version and receiving orders for new “Astah Engineering Pack license” which is very exciting!
(1) Astah Professional & Community Version 6.9 Released
(2) Astah SysML Version 1.3 Released & Astah SysML price deduction
(3) New reasonable ‘bundled-pack’ option – Astah Engineering Pack available

Let me go through each topic quickly and share new update with you which you don’t want to miss.

(1) Astah Professional & Community Version 6.9 Release
This is a major update after 8 months. Many implementations are made which came from our users (Thank you!) and one of the biggest is a new option to make it extremely easier to edit existing Sequence diagrams.
Download_AstahCheck our new improvements made in version 6.9 at New Features page.

This slideshow requires JavaScript.

(See all in New Features page)

We’ve made a short video to introduce some of the new features in 6.9.

(2) Astah SysML Version 1.3 Released & its price deduction
Astah SysML version 1.3 has been released with several improvements based on users’ feedback and bug-fixes.
Download_SysMLAlso we reduced Astah SysML’s pricing to make it consistent with other edition’s annual licenses. Now you can purchase Astah SysML for $119/90Euro (Was $258/340Euro).

(3) New ‘bundled-pack’ option – Astah Engineering Pack license available

Astah Engineering Pack - use Astah Professional/SysML/GSN with one single license!

Astah Engineering Pack – use Astah Professional/SysML/GSN with one single license!

This is very exciting that finally we have a bundled license pack that enables you to use full features of Astah’s 3 editions (Astah Professional, Astah SysML and Astah GSN) with one single license!
Normal price is $199/150 Euro ($357/270 Euro if you buy them individually) but we are throwing a 30% off campaign starting next week. So you get an access to all the 3 editions with only $139/105 Euro! More information will be up on Astah Engineering Pack page on Oct 20(Mon). Stay tuned and don’t miss out this opportunity!


Posted in Event, News, SysML, UML | Leave a comment

Interview with Sandy Friedenthal, Father of SysML – Why do MBSE ?

A Practical Guide to SysML

A Practical Guide to SysML

I had this great opportunity to do a short interview with Sandy Friedenthal, who is an independent consultant in MBSE(Model-based Systems Engineering), and I would call him Father of SysML :)

He previously worked at Lockheed Martin, a large aerospace corporation, where he was responsible for advancing the practice of model-based systems engineering across the company. He was a leader of the effort to develop the OMG Systems Modeling Language (SysML), and is co-author of ‘A Practical Guide to SysML’. He also is cochair of the INCOSE Model-based Systems Engineering initiative.

Question: How does model-based systems engineering relate to systems engineering?

Systems engineering (SE) is a multi-disciplinary approach to ensure the pieces of the system work together to achieve the objectives of the whole. Each engineering discipline, such as software, mechanical, and electrical engineering, focus on their discipline specific aspects of the system, whereas SE address aspects of the system that span across the other disciplines and subsystems to ensure a balanced system solution that addresses the customer needs.

Model-based systems engineering (MBSE) is systems engineering with models. The system models are a primary artifact that are managed and controlled throughout the development process. Although there are many different kinds of models, emphasis is placed on the system architecture model to help integrate the various aspects of the system together.

Question: Why do MBSE?

MBSE is often contrasted with more traditional document based approaches to systems engineering. In a document based approach, the systems engineering data is often contained in traditional documentation such as text specifications, spreadsheets, and powerpoint slides. The information about the system requirements and high level design is spread across many different documents, and is difficult to maintain and ensure consistency. In MBSE, this same information is captured more formally in a system model, which enables the information to be more consistent, traceable, and more precise.

Question: How does SysML relate to MBSE?

SysML is a graphical modeling language, and is a key enabler of MBSE. It is sometimes called a descriptive modeling language that is used to describe multiple views of the system architecture. This contrasts with analytical models such as Simulink, or geometric models used in CAD. However, the architecture model is intended to be integrated with other analytical and geometric models, typically through third part plugins in a system modeling tool

Question: What are some of the essential aspects of an MBSE approach?

A practitioner of MBSE must learn the modeling language, the modeling tool, and the MBSE method used to perform systems engineering. This of course must augment the domain specific knowledge required for the system you are designing.

An organization that wishes to adopt MBSE must develop the infrastructure that includes the tools, methods, and training, and provide skilled people, tools, and processes to the projects for them to implement MBSE.

Question: How does an organization get started in MBSE?

There are few essentials to get started. First, an organization needs a sponsor and a technical advocate who can lead this initiative. It is often advantageous to integrate this effort with other existing improvement initiatives where this makes sense. As a starting point, it is important to understand the current practice and systemic issues that MBSE may be able to address. It is important to clearly determine and document the motivation for why you are doing MBSE in your organization. The key stakeholders should then develop a strategy and plan for their MBSE approach to address these issues. This plan includes the activities to incrementally develop the infrastructure and deploy this capability to projects. The results should be evaluated as a basis for continuous improvement.

Thank you very much, Sandy!

This video is shot on Sept.17, during the period of OMG technical meetings in Austin. I was there to attend robotics and safety assurance meetings, and Sandy was there for leading SEDIG(Systems Engineering Domain Interest Group).

At, we provide services and tools for SysML. As a tool vender, we’d like to contribute to the community via astah(our SysML tool), a simple, easy-to-use, multi-platform tool support for MBSE and SysML from Japan(Yes, we based in Tokyo, Japan). To evaluate our SysML tool, please download a free trial from



Posted in Interview, Kenji, SysML, UML | Tagged , | Leave a comment

(2) How to extract implicit knowledge that can be accepted by others using UML and GSN

This is a guest post by Mr. Nobu Kobayashi from Denso Create, Inc from Japan.

In this post, he tries to demonstrate an effective usage of GSN and UML in systems engineering activities(modeling, documentation, design, and especially their reviews) using a parallel analogy of an easy example .i.e. Origami.

Last week we introduced Nobu’s idea of how to extract implicit knowledge in Origami via GSN. There are many Origami how-to books, but even though everybody follows the exact same instruction, the results will come differently. Some turn out sharp (like right one in the image below) and some turn messy (like the left one)… So what makes the difference? It clearly shows that the complete instruction is just not enough and there are some secret know-hows to make the difference. Then how could we extract those know-hows? (Click the image below to read the last post.)


How can we teach someone to create beautiful Origami Kabuto (Japanese warrior helmet)?

Kabuto (Japanese Warrior Helmet)

Kabuto (Japanese Warrior Helmet)

So below is the diagram he drew that shows the process of how to fold beautiful Kabuto which is a Japanese warrior helmet (see the right image) with Origami papers and secret know-hows (implicit knowledge) extracted by using “Context” node in GSN (Goal Structuring Notation).


Figure1. Steps to fold a Kabuto (Japanese Warrior Helmet) with Origami papers. Read more at

Now we have a question.

“Is this map sufficient for everybody else to fold beautiful Origami with?”

When this diagram was created, these secret know-hows (noted in pink) were picked up from ‘what we tried to be careful at some steps’ with an aim for creating a beautiful Origami Kabuto. But what is ‘a beautiful Origami Kabuto?’ – each person may have different answers to this question. Without sharing the definition or one’s idea of ‘what Beautiful Origrami Kabuto is’, this diagram could be just another instruction of folding Kabuto with someone’s tips and might not be acceptable for the others who have different sense for ‘Beautiful Origami Kabuto’. Then in order to make this map acceptable and work for anybody to fold a beautiful Origami with, what could we do?

Trying a different way to extract the implicit knowledge

The answer is to visualize the way how those implicit knowledge were extracted and make it explicit. Once people understand the fundamental assumptions that those implicit knowledge is on, they will understand and accept them more easily.
The first step I did was to model the structure of Origami Kabuto (Figure.2) using UML.


Figure.2. – Structure of Origami

Origami Kabuto inherits three characteristics, vertex, side and face, and it consists of 4 parts called ‘Hachi’ (the main part of its hat), ‘Kuwagata’ (a hoe-shaped helmet crest), ‘Kuwagata-dai’ (A crest stand), and ‘Mabisasi’ (a visor). In the Figure.2, dotted arrow represents the relation of two parts that how one is folded will affect the size of the other part. (e.g. If Mabisasi becomes bigger, the size of Kuwagata-dai will get smaller and may look unbalanced together). I believe the model in Figure.2 is easy to understand because it shows the nature of the structure of Origami.

Then I did extract implicit knowledge. This time I defined the “Beautiful Kabuto” as one consists of 4 parts which are all in suitable size to make a good balance as a whole and is symmetric. So I chose ‘Suitable size’ and ‘Symmetry’ as essential conditions to derive ‘Criteria of Beautiful Kabuto’ and extracted the implicit knowledge by checking these conditions against the structure of Origami Kabuto (Figure.2).

Figure.2 - Tips for how to make a beautiful Origami Kabuto

Figure.3 – Tips for how to make a beautiful Origami Kabuto

Let me explain this new diagram – Figure.3

  1. The top goal is “Criteria of beauty for Kabuto is accepted’, claimed using yellow  Goal node (G1) on the top.
  2. ‘Suitable size’ and ‘Symmetry’ are adopted as key points shown in pink  Context (C1) to derive the criteria of ‘Beautiful Kabuto’. This is placed on the top as this is the core guideline to achieve the top goal and applies to the whole nodes in this diagram.
  3. Top Goal is divided into two groups “Individual part of Kabuto” and “Relation of parts which affect to each other’s size” based on its concept (C2) and those are broken down further to Sub Goals (G4-9) according to blue  Strategy nodes.
  4. All the implicit knowledge is written in Pink notes at the bottom which were extracted by checking the two key rules stated in C1 for each Solution node (Sn1-6).

Share the context using GSN before start disussing

I believe this new diagram helps more people to fold it better than with the other diagram I drew in the last post because it now shares ‘what a Beautiful Origami is’ with all the extracted implicit knowledge. Once you know the foundation where all the tips come from, those will be more convincing, understandable and easy to accept.

Let’s see this in the software development scene. If everyone involved in a same project could share and understand the same context, we could avoid easy mistakes that are caused by the recognition gap. (I have happened to design software using wrong kind of documents..etc.)

“Visualize your idea and build a common understanding with the others.”

This is easy to say but difficult to achieve – but I believe GSN can be its effective solution.

Astah GSN LogoAt last, I’d like to say thank you for Change Vision-san for developing Astah GSN which provides the features very attentive that help us draw GSN. For example, ‘comment feature’ is a good solution when I want to write detailed information into a Solution node to explain leaf goal’s validity. I hope Astah to continue growing and keep its attentiveness for all the users.

Thank you.

Nobu Kobayashi

Posted in Event, GSN, Interview, Kenji, News, Support, TIPS, UML | Tagged , , , , , , | Leave a comment

Generate source code from UML state machine and activity diagrams

“SinelaboreRT” is a source code generator designed for embedded software developers that generates readable and maintainable code from UML statemachine diagrams and Activity diagrams. It can of course generate code from Astah.






Peter Mueller, the author of this tool and I have been in contact for a long time and he quickly catches any changes on Astah on each release and updates his tool accordingly and immediately. Very trusted, keen and promising person and so is the tool I see.

Download and learn more about SinelaboreRT from here.

If you are already using this tool with Astah, here’re the latest updates on version 3.6.
Region Support in Statemachine diagrams
Generate code from UML Activity diagram support


Posted in News, Support, TIPS, UML | Tagged , , , , , , , | Leave a comment

Embed Astah diagram images to Sphinx!

Wonderful news for Astah users who create documents using Sphinx.

Mr. Takeshi Komiya has created a way to embed Astah UML diagram images into Sphinx. Click here or image below to read how to use this fabulous feature!


He’s made this possible by using “” which is used to export diagram images from Astah by command line.
[TIPS] Exporting diagram to images using the command line

Give it a try and let us know or the developer (@tk0miya) feedback!
Hats off to him from us. :)


Posted in ER Diagram, Kenji, News, Plug-in, TIPS, UML | Leave a comment

[TIPS] How to move objects 1 pixel at a time

Astah has several alignment features to align UML model elements nicely with easy step.

Example) Feature to align model elements vertically

Example) Feature to align model elements vertically

But still sometimes you may want to move model elements individually just to place them in a right place. In that case, hold [Command] key down when you move them, so that they will move 1 pixel at a time.

Also you can show Grid on the diagram from [Tool] – [System Properties] setting. See detail (TIPS: Show Grid in diagram)



Posted in ER Diagram, GSN, News, Support, SysML, TIPS, UML | Tagged , , , , , , | Leave a comment