About SmartState
The Architecture
Additional information

About SmartState

Design Patterns always helped designers to solve recurring problems. But design patterns are conceptual and too generic. The framework on the other hand is more specific to a particular domain and can be realized through the code. The state pattern is a very useful and powerful pattern which enables an object to change its behavior at run time, depends on which state it is in. A kind of changing the class of an object at run time!!. You may find more information about this design pattern here.

If you are aware this pattern you might have realized that it needs to have many classes, each represents a state the object may have in its life time. The real object, often called as Context, doesn't hold any internal flag or variables to keep track of the current state, instead it delegates the work to the state object which is currently active. The state object contacts the Context back, to do the appropriate work if needed and may change the state itself. It is better to keep all the implementation code in the Context and state objects will only take care of which method to invoke in the Context and when to change the state.

An object, which is an encapsulation of a real world entity, might have many states in its life span, and its is absolutely difficult to write classes for each state and the transition logic. State diagrams are used to depict the behavior of the object at various state and its transition logic. Its up to the programmer to realize the design. And of-course each programmer has their own way of implementing it. Which leads to consistent code, difficult to review, difficult to test and difficult to maintain.

This fact, motivated the designers of SmartState to develop a framework which is generic and can be used in almost all application domains. This framework solves few of the problems described above and still the major part of writing the classes is left. So we realized a need for automatic code generation from the design. To accomplish that, state diagrams should not be drawn, it should be modeled. SmartState Designer GUI provides the user with a simple and effective user interface to model the state transitions. Special care is taken to avoid putting all the restrictions in the design time because it may be iterative. The design is free to model and the constraints and restrictions are applied only in the code generation stage which makes the GUI more user friendly.

The code generator analyses the model, checks for necessary constraints and does the most time consuming part of writing the classes. The generated classes are ready to compile and need not be modified. This is a very important feature of SmartState because the design and the implementation is one-to-one always which is usually a day dream in software industry.

To change the behavior of the object, just edit and recompile the model. Rebuild your project and you are done. You may not need a programmer to do this. Which makes it more maintainable. Also the code generated is of the same structure, the review and testing need not be done once you are satisfied with it. All these features lead to improved productivity in your organization which is the motivation of SmartState.

[ top ]

The Architecture

The generated classes are concrete classes which specializes the smart framework library classes. The framework uses the concept of messaging for transitions. When the state handler object is initialized it initializes all the initial states. Based upon receiving the messages from the context, usually, it applies this message to each active state and concurrent states. Depends on the message and its parameters (wParam & lParam are used), it carries out the necessary actions as specified by the user in the effect block. Then it delegate the work of state transition to the framework if needed.Additional data for the guard conditions can be passed through the wParam and lParam arguments. They can hold the address of an object or a primitive data type.

The state classes are lightweight, se it doesn't hold any specific data related to the context. Also all the states possible for the context as defined in the model are created initially and kept. This improves the performance at run time. Se the objects are lightweight it will not be a problem in resource consumption.

It is possible to send internal messages within the state classes which enables a state change depends on some conditions which context need not be aware of.

The generated classes are of-course not thread safe, because it doesn't make much sense to do that. But in multi threaded environment where the messages are pumped from various threads, it is possible to make use of a Queue manager class which is supplied along with the library to keep the messages in the thread safe queue and apply one after the other to the state handler. User may write their own logic for solving this situation if the supplied Queue manager is not sufficient.

[ top ]

Additional information

You may find additional information in the following links:

About State pattern (Context, State, Transition)
Frequently asked questions