|4.46 Elementary Method "State Modeling in the OO Field" (STMO)|
The method is used for the object-oriented system development. Objective of the state modeling in the object-oriented field is the modeling of the dynamic behavior of a system when applying object-oriented software development concepts. The most important usage is modeling the dynamic behavior of objects of significant event-driven classes. Generally, such classes specify "active" objects.
The behavior of objects of one class must be abstracted as life cycle and is modeled in a state model. The state model has to define all states an object can accept and that might possibly result in state transitions, the possible state transitions, the results that state transitions might have, the conditions that have to be met, apart from the events, for a state transition, and the actions that have to be executed as a result of state transitions.
Together with the states, data values accepting the attributes of a class object and possible connections with other objects are defined. The state transition occuring for a class object in a concrete situation is uniquely defined by the actual state of the object, by the occured event and by the specified conditions.
A path in a state model represents a sequence of events. It must be possible to map frequently used analysis scenarios to the paths of the specified state models.
Means of Representation
State diagrams and descriptions in text forms in additional specifications (also as tables or matrices) as well as data-dictionaries are used as means to represent state modeling in object-oriented fields. A state model of a certain class is represented by a state diagram. Thus, a state diagram represents the dynamic behavior of a class.
States are represented in state diagrams in form of a graphic symbol. State transitions are represented as arrows between state symbols. Events, conditions and actions are allocated to the symbols as text. A detailed description of the means of representation can be found in /Booch, 1997/. This means of representation originates in the works of Harel /Harel, 1987/.
State diagrams can be nested, thus making it possible that states and events can be entered into generalization hierarchies. A clearly defined description of the dynamic behavior of complex systems can thus be realized. Apart from a succession of sequential events, parallel events can also be represented.
State transitions can, but do not have to, be better specified by events, conditions and non-interruptable actions. Events must be named and can be identified with attributes specifying the transmission of data in a new state transition. The state transition can be "controlled" with conditions. This only takes place when the event occurs and the conditions are met at the same time. The actions are executed after the state transitions occur. States can be specified by simple incoming and outgoing actions and more complex and therefore interruptable activities.
Another form of state diagrams allowing state modeling in a flat structure is the one by Moore. It is used by Shlaer/Mellor in method "Object-Oriented Analysis" /Shlaer, Mellor, 1992/). However, in comparison with the representation form of Harel, it does not offer modeling possibilities that are just as detailed.
State modeling in object-oriented fields has to be realized for every class where objects have a significant, non-trivial dynamic behavior. It is applied iteratively, whereby more detailed, improved or new or respectively modified state diagrams are created during every run. The iterations are embedded into the method/procedure of the actually applied complex object-oriented development method.
Basically, it can be differentiated between the following steps:
|4.1||SD1.1 - Recording of Actual Status and Analysis||
With the help of this method the actual state of the dynamic behavior of the old system can be collected. The specification must be delimited since only the essential dynamic behavior has to be represented.
The method covers subproduct User Requirements.Actual Status and Current Analysis from the point of view of the dynamic behavior.
|4.2||SD1.2 - Description of Application System||
With the help of the method requirements to the dynamic behavior of the system can be defined within the scope of the preliminary system description.
The method covers the representation of the dynamic system behavior for subproduct User Requirements.Preliminary System Description.
|4.3||SD1.4 - Definition of Marginal Conditions||
With the help of this method the requirements to the dynamic system behavior resulting from technical, organizational and other marginal conditions can be specified.
The method covers subproduct User Requirements.Marginal Conditions from the point of view of the dynamic system behavior.
|4.4||SD1.5 - User-Level System Structure||
With the help of the method the dynamic behavior of the system can be defined or respectively improved down to segment level from a professional point of view.
The method covers subproduct User Requirements.Description of the Functionality from the point of view of the dynamic behavior.
|4.5||SD2.5 - Interface Description||
By means of defining system functions as states, requirements with regard to permitted successions of using system functions can be specified in state models with the help of this method.
The method covers subproduct Interface Description.Description of the interfaces from the point of view of permitted call successions.
|4.6||SD3.2 - Specification of Requirements for External Interfaces of SW/HW Unit||
By defining functions as states, requirements to the permitted call succession of software functions can be specified in state models with the help of this method.
The method covers subproduct Technical Requirements.Technical Requirements for the Interfaces from the point of view of permitted call successions.
|4.7||SD3.3 - Definition of Requirements for the Functionality||
With the help of the method, the dynamic behavior of the SW Unit can be defined or improved to specify requirements with regard to the technical functionality.
The method covers subproduct Technical Requirements.Overall Function of Element with regard to the SW Unit, from the point of view of the dynamic behavior.
|4.8||SD4.2 - Design of Internal and External SW Interfaces||
By defining functions as states, permitted call successions of SW functions in state models can be specified with the help of this method.
The method covers subproduct Interface Description.Description of the Interfaces from the point of view of the call successions.
|4.9||SD5.1 - Description of SW Component/Module/Database||
With the help of this method, the dynamic behavior of SW Components/SW Models can be modeled in detailed state models. The structures generated in previous activities have to be improved or upgraded.
The method covers subproduct SW Design (Module).Realization of the SW Component/ SW Module from the point of view of the dynamic behavior.
|No.||Interface||Observation||Information in Annex 1|
In addition to the static class structures defined in method COM the significant dynamic behavior of classes of active objects is modeled in method STMO. Modeling of states must be adjusted with modeling of class attributes, modeling of events and actions and modeling of class operations.
While the static structure of interfaces can be specified with method COM, permitted call successions of functions of the interface can be represented with method STMO.
|5.2||STMO-UCM||The use cases defined with UCM can be used as information basis for modeling state models in method STMO.|
|5.3||STMO-IAM||As starting point for the definition of state models in method STMO, defined scenarios can be used with the help of method IAM.|
|GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster|