-
Key: UML25-596
-
Legacy Issue Number: 7675
-
Status: closed
-
Source: X-Change Technologies ( Joaquin Miller)
-
Summary:
It appears UML 2 does not permit use of a state machine as a specification technique for a class. The support for use of a state machine to specify a method does not help: that state machine won't be a method. The support for use of a state machine to specify a classifier behavior does not help: since that state machine is not a specification of code that gets invoked when an object is created. Example: An architect specifies a state machine for a class. This is not the specification of a method, nor of an independent computation belonging to an object of that class, but of the overall behavior of an object of that class. That state machine responds to four events. As a refinement of that model, a tool or a designer generates four event taker method specifications, which together implement the specified state machine. Those methods are then hand coded according to that specification, or perhaps another tool generates the code for those methods. An object of this class "does nothing until it [one of its event taker methods] is invoked by some other object, then it does its thing, and then it returns and again does nothing." The behavior of that object is fully specified by this state machine. This state machine is not the specification of a method, nor is it the specification of a classifier behavior ("When an instance of a behaviored classifier is created, its classifier behavior is invoked."). But the opinion of experts, expressed in FTF discussions, is that these are the only two uses of a state machine permitted by the FAS. This state machine is not intended to "to describe or illustrate the behavior of an object." It is intended to fully specify that behavior. It is not a protocol state machine. Proposal: Specifically authorize this use of a state machine.
-
Reported: UML 2.0 — Sat, 4 Sep 2004 04:00 GMT
-
Disposition: Resolved — UML 2.5
-
Disposition Summary:
Discussion
A BehavioredClassifier in UML 2 can own any number of Behaviors via its BehavioredClassifier::Behavior link.
These Behaviors can be of any type and can have any interpretation desired by the modeler (with the exception of
the one designated as the “classifier Behavior”). Hence, there is nothing to prevent defining a state machine with the
interpretation suggested by the submitter.
Disposition: Closed - No Change -
Updated: Fri, 6 Mar 2015 20:59 GMT
UML25 — UML 2 does not permit use of a state machine
- Key: UML25-596
- OMG Task Force: Unified Modeling Language 2.5 (UML) FTF