If you read my previous post, you would know it’s time for me to get a little technical and start describing how to use the actual bits. The premise of my previous post was that modeling Finite State Machines (FSM’s) could be one of the core building blocks of real-world implementations of Oslo.
I’m working with the May 2009 CTP that you can download and follow along.
So the idea is we want to build a couple different grammars for parsing our state machines, one that is plain text English and one that is more terse. Here are some examples of the inputs we want to parse.
Plain Text English Version:
The states of our Invoice are New, Reviewed, Submitted, Paid, Overdue, Cancelled.
Terse Version:
Invoice States: New, Reviewed, Submitted, Paid, Overdue, Cancelled;
And input for our transitions:
Plain Text English Version:
An Invoice can transition from New to Reviewed and Cancelled.
An Invoice can also transition from Reviewed to Submitted and Cancelled.
An Invoice can also transition from Submitted to Paid, Overdue and Cancelled.
An Invoice can also transition from Overdue to Paid and Cancelled.
Terse Version:
Invoice transition: New to Reviewed, Cancelled;
Invoice transition: Reviewed to Submitted Cancelled;
Invoice transition: Submitted to Paid, Overdue, Cancelled;
Invoice transition: Overdue to Paid, Cancelled;
After you have installed Oslo you should see a new program you can start called Intellipad this application is an extensible Swiss Army Knife for working with Oslo. We will use Intellipad to construct and test the specification for our DSL.
First thing we need to do to is change the mode to “DSL Grammar Mode”.
One you do that we need to setup our view to create or Grammar. The view we want is “Split New Input and Output Views”.
This will give us four panes:
Let’s start out by authoring our Domain Specific Language or DSL. We want to build a DSL Grammar that will be used to parse the following text.
The states of our Invoice are New, Reviewed, Submitted, Paid, Overdue, Cancelled.
An Invoice can transition from New to Reviewed and Cancelled.
An Invoice can also transition from Reviewed to Submitted and Cancelled.
An Invoice can also transition from Submitted to Paid, Overdue and Cancelled.
An Invoice can also transition from Overdue to Paid and Cancelled.
To build our Grammar we need to start out by adding some basic building blocks, these will allow us to start defining the “stuff” that makes up our Grammar.
Now that we have Word and Word and NameWithSpace defined, we can go ahead and describe the syntax of the data we want to extract, in our case we would like to get the name of the entity we which we are modeling the state machine, a name of the states as well as the from state and to states for our transitions.
Next let’s go ahead and define some of the tokens we will be using to parse out our state machine:
Some things to note about this
1) Notice on the keyword transition we say “transition” “s”? this will allow us to use either the word transition or transitions note the plural.
2) If we use the the @{Classification[“Keyword”]} we will get syntax highlighting as shown here:
Next to make our life a little easier we define what I guess would be similar to a C# Generic, basically a template that can be applied to certain syntax within our Grammar.
This allows us to create a list like:
Note the separator of both “,” and “and” as defined by (“,” | “and”) in our ItemList(n) definition.
This will recursively be built by going through the list and come up with something like:
Now that we have our building blocks in place, we need to start describing our grammar, let’s start by looking at the grammar to parse the states in our state machine. We will want to parse either of the following syntax:
Invoice States: New, Reviewed, Submitted, Paid, Overdue, Cancelled;
The states of our Invoice are New, Reviewed, Submitted, Paid, Overdue and Cancelled.
Our grammar to parse this is:
Which will produce the following the following MGraph from either text that would be parsed:
Looking at this a bit closer we will see we identified some additional tokens
There are used in our first definition to identify the syntax.
So the following bit of grammar:
Could be used to parse any of the statements:
The states of our Invoice are New, Reviewed, Submitted, Paid, Overdue and Cancelled.
States of our Invoice are New, Reviewed, Submitted, Paid, Overdue and Cancelled.
The States of an Invoice are New, Reviewed, Submitted, Paid, Overdue and Cancelled.
The States of a Review are New, Reviewed, Approved.
Now that we have the ability to parse with our grammar we need to describe how we want to project or shape the data into MGraph. The following syntax will do that:
and generates the following MGraph:
If you remember our goal was to allow two different types of grammar, one that is fairly close to a sentence structure and the other was rather terse. Adding the following straight forward definition will allow us to parse the terse grammar, the shaping of the data is the same as the original rule.
Next we need to add in our transitions, our transitions can be described as either of the following syntax:
An Invoice can transition from New to Reviewed and Cancelled.
Invoice transition: Reviewed to Submitted Cancelled;
At this point there really aren’t any surprises in our syntax:
Which will generate the following MGraph
The final thing we need to do is to bring all this together at our main statement which will build our top level MGraph, this is fairly straight foward:
You can see here that we want exactly one set of state lists and a set of descriptions for the transitions when in each state.
So as everything comes together your final MGraph looks like
To run this sample on your computer
1) Install OSLO
2) Start Intellipad
3) Switch to DSL Grammar Mode
5) Download and copy the MGrammar for the State Machine into the “DSL Grammar Mode Pane”
6) Download the sample text to be parsed to the windows labeled “StateMachine” mode.
What’s Next?
In the next post in this series we will take the MGrammar and do something useful with it using a C# application.
-ec
No comments:
Post a Comment