Dear Hitoshi
> I'm sorry but I'm still having understanding the differences.
I think the central difference is as follows:
UML started with a collection of graphical notations (State Machines, Activity
Diagrams, Collaboration Diagrams) and has been working ever since (with varying
degrees of success) to try and define the semantics of these diagrams.
We, on the other hand, started with the notion of an abstract machine (Protocol
Machine) and defined its semantics first. The semantics are defined to allow
these machines to be composed, so that two composed Protocol Machines yields a
new Protocol Machine. Moreover, the semantics do not specify that the state of
the machine (which determines what events are allowed next) needs to be stored
by the machine, and so could be calculated (or derived) from other information
available to the machine.
The notation used to describe a Protocol Machine is secondary. State-transition
notation is the obvious choice, but there is no reason not to use Petri Nets,
regular expressions, rule tables or anything else, provided the semantics are
observed. In this sense, the concept of a Protocol Machine is notation neutral.
You can compose machines whose behaviours are defined using different
notations: e.g., a machine defined using a State Machine with a machine defined
using a Petri Net.
UML, with its notation centric approach, does not have any concept of behaviour
composition -- apart from the expressively weak "Concurrent Regions" in State
Charts. Moreover, because diagrams are the starting point, and behavioural
diagrams are usually a way of showing stored state, there is no concept of
derived state.
We think that composition is important because a behavioural entity (unless it
is very simple) will have multiple state-spaces. For instance a Person has
state-spaces {Working, Unemployed} and {Married, Single). We think that the
ability to derive state values is important because positioning within a
state-space may not be simply driven by events: for instance a Bank Account has
a state-space {In Credit, Overdrawn} and its position in this space is derived
(in the obvious way) from the balance of the Account.
> Can you provide me with an example of concrete business situation which can
> not be represented by an UML diagram?
I would suggest you look at the entry "Workflow Control Patterns" dated Nov
2006 on our "News and While Papers" webpage (
http://www.metamaxim.com/pages/news.htm ). I think the Synchronizing Merge
pattern discussed here is difficult to handle in UML.
> Also, would greatly appreciate if you can provide me with more information.
The following two papers may be of interest. Both are referenced from the "News
and White Papers" page:
1. The paper "State Machines as Mixins" (see "Metamaxim article in The Journal
of Object Technology" dated Jan 2004)
2. The paper "Protocol Modelling" (see "Formal Semantics" dated Nov 2004).
The first of these is a more general motivation of the ideas -- please read
this one first. The second is an attempt to put the ideas on a more formal
footing.
* * * *
I hope this helps.
Rgds
Ashley
