IntelliWizard© - UML StateWizard

An open source software under LGPL license.

Features

Users & Partners

Why State Machine Mechanism?

In an environment where software systems are more an more complex, concurrent, distributed and real time oriented, the choice of modeling languages and tools become the success keys of many projects.

Modeling concurrent behaviors using state machine mechanism

Concurrent systems typically consist of multiple self-contained components that communicate with each other by exchanging asynchronous or synchronous messages. The pure multi-threaded approach presents a suitable way to solve this concurrent problem. However, once the number of threads increases beyond a certain limit, performance will drop sharply as the accounting cost of a large number of threads will start to affect the overall performance. This causes an inverse effect: programmers must handle shared resource access synchronization issues caused by the multi-threading mechanism.

Many concurrent, distributed and real-time applications are natural candidates for being organized as state machines. An application that must sequence a series of actions, or handle inputs differently depending on what state it's in, is often best implemented as state machine. We can see that the event driven state machines programming mechanism provides a better solution for distributed, concurrent and real-time systems. We may utilize UML state machines to properly model concurrent behaviors.

1) Real Time Response

Real time systems have to respond to external interactions in a predetermined amount of time. Successful completion of an operation depends upon the correct and timely operation of the system. State machine based programming with multiple thread/task programming can support the requirement of real time response.

2) Communication

The system's components can use one of the following communication mechanisms to exchange information between each other:

(a) Synchronous communication / service calls. These synchronous service calls made by a customer, return immediately after the operation finishes. If the service request and the service provider are executed by different threads, the service request will block itself.

(b) Asynchronous communication / service calls. Aynchronous communication does not wait for a request-reply but will continue execution and return before the operation is completed.

(c) Pro-active event indication. These events are posted from a service component to a customer component without any request.

Thus most systems support state machine based design where multiple events can be received in a single state. The next state is determined by the contents of the received event. State machines provide a very flexible mechanism to handle asynchronous event interactions. Nevertheless, this flexibility comes with its own complexities.

3) Working with Distributed Architecture

Most real time systems involve processing on several different nodes. The system itself distributes the processing load among several processors. Software in different components may run in some concurrent threads. Usually different components exchange information by asynchronous events.

4) Recovering from Failures

Real time systems must function reliably in event of failures

5) Race Conditions and Timing

A race condition occurs when two (or more) components are accessing the same resource at the same time. Each component must obtain a lock on the shared resource while using it or modifying it, to maintain functionality. Embedded systems can use synchronization mechanisms (such as mutual exclusion methods) to ensure operation integrity.

Of course, several groups of state machines (applications) are allowed to run at each separate thread/task. We use a thread context to identify an independent thread. A thread context contains the following resources:

• A thread identifier;
• A group of applications;
• An internal event pool;
• Several function pointers to the external event receiving/deleting functions;
• Several event hook functions.
  

State machine is a suitable approach to implementing embedded systems. This approach was used to design dozens of systems, a softkey-based user interface, a silicon-wafer transport mechanism, an unmanned air vehicle's lost-uplink handler, and an orbital mechanics simulator, to name a few. Several communication protocols have also been implemented with the same approach.

Copyright 2007 IntelliWizard Inc. All Rights Reserved.
EMail : info@intelliwizard.com