Prototyping is used in all lines of engineering. Prototyping is the process were you whip something together quickly as a mock up in order to show it or test it in order to learn something that otherwise would be hard to know.

Prototyping for software has a unique position. The prototype is made up by the same stuff as the finished product ; logical rules. This is not true for any other practice of engineering. We have a unique position that we can harvest. To make the real deal – the finished product – just as easy as if we were building a prototype.

Many experienced developers will frown on this. They know how very prudent you must be to actually build something that is robust and solid. And they know how very quick and dirty they are when whipping together a prototype. Why does this big gap exists? My answer: Normal coding leaves to many degrees of freedom for the task at hand. Normal coding actually use only one tool – code – for handling data, presenting it, navigating it. Of course you will mix things up when you are in a hurry.

If we can separate things like the information we handle, from the transformation of that information into views and from the navigation between these views – then we have something that will almost fly on its own – and the building of the thing will be like prototyping the thing. Think of it as an autopilot – it will protect you against doing stupid mistakes – it will make you fly straight – it will give you time to talk on the radio and stuff – you only need to tell it where you want to fly.

So with MDriven we use the Model to tell the autopilot what information to handle – what the perspectives of the information should be – how we navigate between the views of information. Having instructed the autopilot we can take off – and see if we have the right model or not. If not churn away and fix it.

Many developers will also frown on the idea of an autopilot – since it will emasculate them and stop them from flexing their muscles – so I need to point out that what is great with MDrivenFramework is that you can turn off the autopilot for any portion of the flight so to speak. You can still do the coolest looping in front of a gaping audience whenever you feel like it. Then turn on the autopilot to do the mundane flight back home. This will give you freedom and speed and a lot less accidents.

This is how you do it with MDriven

1. Model what you know so far – in this example I am prototyping for a Car Rental Service

2. Think about what user stories or requirements you have:

As a Customer I want to see what cars you can rent

As a Customer I want to know what they cost per day and what my total cost will be

As a Rental worker I want to be able to hand customers rental contracts to sign

As a Rental worker I want to be able to find free cars

3. Then do some ViewModels that can cover these user stories – when prototyping I will make use of the scaffolding user interface hints that place out UI controls on a screen surface that match the types of the viewmodels properties. I ended up with 4 viewmodels:

Search for a Car:

Search for customer

View or edit a customer

View or edit a Rental contract

4. What actions do we need to expose to the user for navigation between these views. For this I will start by clicking Create/Init standard actions in the ActionsDefinition dialog.

This gives me the ordinary actions like save,quit, undo and redo. It also picks up on the ViewModels I have and add some actions for them.

I will remove the actions created for ViewAndEditCustomer and ViewAndEditRentalContract since these are rooted views that require a root object (a customer or a Rental contract) to have anything to show. Instead I add a ViewModelActions in SearchForCustomer ViewModel that creates a new Customer and one that creates new rental contracts:

I also add class actions that can show and existing customer and rental contract

6. I could think a bit harder – but the whole point with prototyping is that it should be easy to test if we are done or not. So I hit the start prototype symbol:

I am presented with a choice on how to store data for this prototype – we will choose xml for starters:

I start the prototype and find the main menu items

I pick “Search for customers” – I search – the system finds none – I click the action new customer – I get the ViewAndEditCustomer view – I enter a name and save and hit back – now the search result sees a customer:

Note to self – must have a Search for rental contracts

I create a new rental contract – I notice that the button “Assign customer” does not do anything

Note to self – must bring up “search for customer on assign customer – then let user pick 1 customer and return back with it and set it on the rental contract”

Note to self – same for assign car – must bring up search for cars

Note to self – I do not have any data for cars or brands and no UI to enter it – Note to self – do this in the debugger window for now

This is how a typical prototyping session goes and how it reveals obvious things we need to do. Lets do them now. Starting with using the debugger for adding cars and brands:

I add brand as well – the save the data to the prototyping XML file by switching to dirty objects:

I click open the Autoform of a Car-object – then I drag a Brand object to the Brand field:

So that takes care of test data for Cars and Brands. I still have these to items:

Note to self – must bring up “search for customer on assign customer – then let user pick 1 customer and return back with it and set it on the rental contract”

Note to self – same for assign car – must bring up search for cars

I do this by adding a ViewModelAction for the ViewOrEditRentalContract:

The Action should bring up the search for Customer, it should be a modal action, it should be fine to press ok once a Customer is selected. And when Ok is executed we assign the picked customer to our rental contract.

The same more or less for picking a car:

I then choose to hook these actions up to the buttons I put in the ViewModel:

I also has this one left: Note to self – must have a Search for rental contracts

Yet another viewmodel. Once I have it done I use the shortcut action to create global action to show it:

Then I press Play again:

This time I can assign a Customer and assign a Car. The search for Car comes up in with an Ok/Cancel button because it was brought up by a modal action:

I search and pick a car and press ok:

I still have a few user stories left and I will need to change the model some, amend the viewmodels a bit, maybe create some actions. But all in all this is a very straight forward way to work. And you get instant gratification to see your model and logic come life. This is also something that triggers your ideas for further things your users will need and want. Churn on like this for an hour or two and you have done more than what you can do in a day with traditional specification work or coding.

The look

The prototyper window uses Windows Presentation Foundation (WPF) and you are free to change the used style sheet just as you see fit:

Or

or maybe you need to stress the that we are “just prototyping” by using something really bubbly:

Available Actions

The actions that are shown to the left are calculated by the framework. You can have class-actions – actions associated with a class in your model. These will show up whenever an object of that class is shown in you view.

You can also have viewmodel actions and these only show up in the view they are defined for.

We have the ability to instruct the logic to do exceptions to the calculated display of actions. We can opt out the presentation of actions per view.

Actions may be used for navigation – but they may also perform something – like calling a method on an object.

In our example we already have some actions – both viewmodel actions, class actions and global actions (the ones that build up the main menu).

Look closer at the ShowRentalContract action. This is a class action – available everywhere a RentalContract is shown. But there are situations where we do not want it to show – like when we already are in the view that is brought up by the action:

In order to remove it we want to opt it out.

There are two tools in MDrivenDesigner that are good to use for this. The first one is the ViewModelEditor:

Pressing the “>” button will move it to the opt out column:

You can press the “<” to opt it in again.

The other place where you can opt out actions from is the Action Cross reference window:

In this window we see the actions that will bring this view up – currently there are 2 actions, the NewRentalContract and the ShowRentalContract.

We also see the actions that will show and an line to which section or nesting of the ViewModel it refers. You may click the lines and shift them from green (opt in default) to opt out. Since we already opted out our ShowRentalContract from this view – that line is already red.

There are also tools for looking at this from a specific actions perspective. In the ActionsEditor we see this for the ShowRentalContract Action:

It says “Action shows in 2 places. 1 Opted out” followed by a dialog button. Click that and you will see this:

And here we see that it is opt out in the ViewAndEditRentalContract view – but it shows 2 times in the SearchForRentalContracts view. I switch back to prototyping to verify this:

And find that this is true. The reason for this is the fact that this viewmodel defines two areas that has the type RentalContract. One for the root and one for the Grid-nesting that shows the results from the variable vSeekerResult.

The root instance will always be null since this ViewModel does not require a root object to function. ViewModels designed for seeking seldom do. If it always will be null then there is little point to have an action that will be enabled only if it is assigned an object. So we should opt that root action out – click the line to toggle opt out state:

And then the ActionEditor was updated as well:

It now says shows in 1 place – 2 opted out.

I actually have had my prototyping session running all along – but it still use the model we had prior to our changes. I can now restart the prototyping by clicking play again – bringing up a new prototype window. Or I can just reread the model to the one I have:

and then I see that the ShowRentalContract action is shown only once.

If you are left alone for a day and if you have lots of ideas I promise that you can model them in MDriven designer and verify them in MDriven prototyper. When you are able to try and verify ideas rapidly you will find many “think bugs” early. Bugs that are like “oh – no – that is not a good way of doing it”. Since the MDriven environment works as your auto pilot and it has 10:th’s of thousands flight ours under its belt – you will be more free for the creative part of your work.