Home arrow Info arrow General Info arrow ECharts versus UML Statecharts
ECharts versus UML Statecharts Print
Excerpt from ECharts: From Lab to Production (2005):

We initially considered adopting UML Statecharts, a standardized state machine design language, as our service description language. The benefits of UML Statecharts are that the language is visual, expressive, and that it is supported by commercial tools that perform design capture, (Java) code generation and code execution.

With regards to expressiveness, we were attracted by the language’s support for hierarchical state machines, concurrent (orthogonal) state machines, machine synchronization, and fork/join transitions. However, when we attempted to design a few non-trivial services with the language we encountered short-comings:

  • The language only supports a single transition priority rule for constraining transition execution order. As a result, many non-deterministic situations can exist in a model.
  • The language only provides rudimentary support for re-using models, and no support at all for parameterizing models.
  • Broadcast communication is utilized for intra-Statechart communication, which in general can result in broadcast events being lost in situations when no Statechart is ready to accept an event.
  • While it is possible for a fixed number of concurrent state machines to exist statically within a state, it is not possible to create state machines dynamically. The former is akin to allocating a fixed number of worker threads, whereas the latter is akin to dynamically creating worker threads on an as-needed basis. When the number of active Statechart instances required is unknown prior to runtime, the latter approach conserves runtime resources.
  • Finally, we found the machine termination semantics to be overly complex, because the developer is required to explicitly specify a state as terminal which we considered to be redundant.

In defense of UML Statecharts, we recognize that most shortcomings exist because the language is intended to serve first as a design language, and second as an implementation language. However, our need was for a language that served first as an implementation language and second as a design language, so we concluded that UML Statecharts did not suit our needs.

To address these shortcomings while maintaining the desirable properties of UML Statecharts, we developed a Statecharts dialect called ECharts. Wherever possible, the ECharts language adheres to the UML Statecharts standard. Specifically, we consider that the introduction of a port abstraction, additional transition priority rules, enhanced support for Statechart reuse, support for dynamic creation of concurrent state machines, and a refined termination semantics can be viewed as refinements or extensions to the UML Statecharts semantics. On the other hand, instead of using the intra-Statechart broadcast communication mechanism used by UML Statecharts, ECharts utilizes a more restricted form of communication. The only semantic element at odds with UML Statecharts is that ECharts utilizes an explicit event consumption model instead of an implicit event consumption model. The explicit event consumption model ensures that events aren’t ignored unless the programmer explicitly declares them to be ignored.

Discuss this article on the forums. (0 posts)
Last Updated ( Wednesday, 17 October 2007 )
 
< Prev   Next >
Copyright © 2006-2009 echarts.org