The original version of the "Extended Hierarchy State Transition Matrix Design Method" was Invented in 1992. Almost 10 years have passed since that time.
It had modified in 1998, changes in "The Extended Hierarchy State Transition Matrix Design Method version 2.0" are as follows:
(1) States can be concurrent.
(2) State hierarchy is allowed.
(3) Functions and interrupts can be described as events.

The range of applications that can be designed using the state transition matrix has been extended, owing to these additions.
The trend is moving from structured analysis and design to object-oriented analysis and design.
The embedded system engineers would ask, "Can it be used for real-time controlled software in the embedded, one-chip microprocessor ?" as they did when structured analysis and design were introduced. The answers from methodologists are always, "Yes, it can," but embedded system engineers are skeptical about such an answer. Information processing engineers never ask whether they can use it.

Why are their reactions different ? Probably the focus of each party is a little different. The most important information concerning the structured analysis and design method is "data flow", while the "object" is the most important for object-oriented analysis and design. It is natural that these methodologies, which come from the information processing field, focus on "data flow" and "object", and that the information processing engineers have no doubt about it. The focuses of embedded system engineers, however, are on "actual time" and "control". To our regret, even state transition does not capture "actual time". Maybe "actual time" is a kind of information that can be captured only by activation (simulation) such as computer graphics. In order for software to realize "control", it is necessary to manage various states within the software, switch actions depending on the state or received event, then change the state further. "Event", "state", "action" and "transition" are important items of information. If a class is designed without considering the importance of such information, the class will not have "control", and we wonder what happens to the software built using the class.

The basic concept of the state transition matrix design method is to design software with consideration for "events", "states", "actions" and "transitions". Therefore, embedded system engineers do not become skeptical. However, the information about "object" should be added to it.
It is not that the "state transition" information is added to "object". "Object-oriented" in the embedded world means to consider "when", "where" and "what" the class executes before considering what the class exactly does (method and attribute). It is necessary to design objects that handle control, not the objects that handle data.

The state transition diagram is used to design state transitions. Mealy, Moore, Harel and others have rapidly improved the notational conventions. On the other hand, the state transition matrix has been treated as a supplement to the state transition diagram, so very little has been improved. I have no idea why the state transition diagram has been improved but the state transition matrix has not.

I have challenged this issue because I was curious about the reason. I have always preferred the matrix because it is more organized and easier to spot missing items. As for the diagram, even though deletions could be handled somehow, we did not like the troublesome insertion operations, which required moving other shapes and connecting the transition destinations.

Another reason I prefer the state transition matrix is that if it is used for designing, it is not necessary to create a separate checklist for testing. This document is a result of our efforts to realize what the most up-to-date state transition diagrams can represent by using the state transition matrix. I have been designing control systems using the state transition matrix for a long time. The software created thus far is still used actively.

The method of design, using the state transfer matrix, did not change even once from the age of assembly language well into the age of C. I believe the importance of the state transition matrix will further expand in the future.