projects / ceph.git / blame
| Commit | Line | Data |
|---|---|---|
| 7c673cae FG |
1 | <html><head> |
| 2 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | |
| 3 | <title>Preface</title><link rel="stylesheet" href="boostbook.css" type="text/css"><meta name="generator" content="DocBook XSL-NS Stylesheets V1.75.2"><link rel="home" href="index.html" title="Meta State Machine (MSM)"><link rel="up" href="index.html" title="Meta State Machine (MSM)"><link rel="prev" href="index.html" title="Meta State Machine (MSM)"><link rel="next" href="pt01.html" title="Part I. User' guide"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Preface</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="index.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="pt01.html">Next</a></td></tr></table><hr></div><div class="preface" title="Preface"><div class="titlepage"><div><div><h2 class="title"><a name="d0e22"></a>Preface</h2></div></div></div><p>MSM is a library allowing you to easily and quickly define state machines of very high | |
| 4 | performance. From this point, two main questions usually quickly arise, so please allow | |
| 5 | me to try answering them upfront.</p><p> | |
| 6 | </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>When do I need a state machine?</p><p>More often that you think. Very often, one defined a state machine | |
| 7 | informally without even noticing it. For example, one declares inside a | |
| 8 | class some boolean attribute, say to remember that a task has been | |
| 9 | completed. Later the boolean actually needs a third value, so it becomes an | |
| 10 | int. A few weeks, a second attribute is needed. Then a third. Soon, you find | |
| 11 | yourself writing:</p><p><code class="code">void incoming_data(data)</code></p><p><code class="code">{</code></p><p><code class="code"> if (data == packet_3 && flag1 == work_done && flag2 | |
| 12 | > step3)...</code></p><p><code class="code">}</code></p><p>This starts to look like event processing (contained inside data) if some | |
| 13 | stage of the object life has been achieved (but is ugly).</p><p>This could be a protocol definition and it is a common use case for state | |
| 14 | machines. Another common one is a user interface. The stage of the user's | |
| 15 | interaction defines if some button is active, a functionality is available, | |
| 16 | etc.</p><p>But there are many more use cases if you start looking. Actually, a whole | |
| 17 | model-driven development method, Executable UML | |
| 18 | (http://en.wikipedia.org/wiki/Executable_UML) specifies its complete dynamic | |
| 19 | behavior using state machines. Class diagram, state machine diagrams, and an | |
| 20 | action language are all you absolutely need in the Executable UML | |
| 21 | world.</p></li><li class="listitem"><p>Another state machine library? What for?</p><p>True, there are many state machine libraries. This should already be an | |
| 22 | indication that if you're not using any of them, you might be missing | |
| 23 | something. Why should you use this one? Unfortunately, when looking for a | |
| 24 | good state machine library, you usually pretty fast hit one or several of | |
| 25 | the following snags:</p><div class="itemizedlist"><ul class="itemizedlist" type="circle"><li class="listitem"><p>speed: "state machines are slow" is usually the first | |
| 26 | criticism you might hear. While it is often an excuse not to use | |
| 27 | any and instead resort to dirty, hand-written implementations (I | |
| 28 | mean, no, yours are not dirty of course, I'm talking about other | |
| 29 | developers). MSM removes this often feeble excuse because it is | |
| 30 | blazingly fast. Most hand-written implementations will be beaten | |
| 31 | by MSM.</p></li><li class="listitem"><p>ease of use: good argument. If you used another library, you | |
| 32 | are probably right. Many state machine definitions will look | |
| 33 | similar to:</p><p><code class="code">state s1 = new State; // a state</code></p><p><code class="code">state s2 = new State; // another state</code></p><p><code class="code">event e = new Event; // event</code></p><p><code class="code">s1->addTransition(e,s2); // transition s1 -> | |
| 34 | s2</code></p><p>The more transitions you have, the less readable it is. A long | |
| 35 | time ago, there was not so much Java yet, and many electronic | |
| 36 | systems were built with a state machine defined by a simple | |
| 37 | transition table. You could easily see the whole structure and | |
| 38 | immediately see if you forgot some transitions. Thanks to our | |
| 39 | new OO techniques, this ease of use was gone. MSM gives you back | |
| 40 | the transition table and reduces the noise to the | |
| 41 | minimum.</p></li><li class="listitem"><p>expressiveness: MSM offers several front-ends and constantly | |
| 42 | tries to improve state machine definition techniques. For | |
| 43 | example, you can define a transition with eUML (one of MSM's | |
| 44 | front-ends) as:</p><p><code class="code">state1 == state2 + event [condition] / | |
| 45 | action</code></p><p>This is not simply syntactic sugar. Such a formalized, | |
| 46 | readable structure allows easy communication with domain experts | |
| 47 | of a software to be constructed. Having domain experts | |
| 48 | understand your code will greatly reduce the number of | |
| 49 | bugs.</p></li><li class="listitem"><p>model-driven-development: a common difficulty of a | |
| 50 | model-driven development is the complexity of making a | |
| 51 | round-trip (generating code from model and then model from | |
| 52 | code). This is due to the fact that if a state machine structure | |
| 53 | is hard for you to read, chances are that your parsing tool will | |
| 54 | also have a hard time. MSM's syntax will hopefully help tool | |
| 55 | writers.</p></li><li class="listitem"><p>features: most developers use only 20% of the richly defined | |
| 56 | UML standard. Unfortunately, these are never the same 20% for | |
| 57 | all. And so, very likely, one will need something from the | |
| 58 | standard which is not implemented. MSM offers a very large part | |
| 59 | of the standard, with more on the way.</p></li></ul></div><p>Let us not wait any longer, I hope you will enjoy MSM and have fun with | |
| 60 | it!</p></li></ul></div><p> | |
| 61 | </p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="index.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="pt01.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Meta State Machine (MSM) </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Part I. User' guide</td></tr></table></div></body></html> |