Wire in your design with VS Team System and WF

I've produced my fair share of class diagrams, sequence diagrams, collaboration diagrams and package and deployment diagrams; at times I've gone down the route of round-trip engineering, generating skeleton code from a full design and and round-tripping it back into the design tool to reflect changes made (at least for a while). I've done it with Java, and with C++ as the target language. The latter was a little messy since the tool annotated the code pretty heavily, but while I wasn't overly keen on that side effect it was worth the trade off, because the code reflected the design and vice versa. Which is kind of the whole point. Unfortunately, there are lots of things which can contribute to a design and codebase losing touch. Here's a few:

1. Discipline If you have your design and code in separate silos (as I described above) then you need to be pretty disciplined to constantly update the design over time (particularly if yours is a long running project). As does each member of your team. You can certainly do it, but it takes conscious effort, continuous diligence.
2. Tools  The tools may not support the development process very effectively. For example, many design tools use a binary file format which can't be merged by source control. Meaning that only one person can make a change at a time, even if the associated changes in the code are not ambiguous (e.g. I add a new class and you add a new method to a class in a different file). It doesn't make for a smooth development workflow. But these tools are supposed to help me as a developer, right?
3. Design? Pah! Also known as I know better and I'm not going to implement it as designed, or maybe as I think this is as it was designed, but ummm...There's frequently a disconnect between design and code right from the start, either intentionally (I know better with a little bit of #1 thrown in for good measure) or unintentionally (I think this is... with #2 chipping in as well).
4. Deterrent A small refactor can quickly turn into a big refactor as a cleaner picture begins to emerge - which is great, I've had some great in-the-zone refactoring blitzes where I've ended up smiling sheepishly as a result of things being so much simpler than I had originally envisaged. But having a model to update afterwards is a little bit like having to clean up the morning after the party. The hassle involved can put you off in the first place.  In this case actually having a design can result in your code being worse because your reward for improving the code is the booby prize of having to update the design - so it may not get done. A good symptom of this is having a kitchen-sink package or assembly (Utils.dll anyone?) which people just chuck stuff into time and time again and it keeps getting bigger and bigger. I've been guilty of that more than once.

There are more reasons, but you get the idea - I suppose I could sum it up in one word : entropy.

In any case, designs that are out of date are worse than useless. So - what to do? There are a few things that can help, but it's imperative that the tools work in support of the process. This is something that Team Suite has got right in my opinion - instead of having the code and design in separate silos, any changes to the design are automatically reflected in the code and vice versa, which is very enabling - just think of the interaction between say an architect and a developer.

But the real point of this post is that if you need to model e.g. a complex process and want to take things one step further then it's worth looking at what Workflow Foundation has to offer. WF is a very powerful workflow engine which can be hosted in all kinds of applications, allowing for example workflow-enabled WCF services. Below is a snapshot of a WPF application I wrote a while back to highlight what WF can bring to the table - it's somewhat contrived (read extremely contrived), but the scenario is that of an automated banking system allowing functionality such as check-your-balance etc. using a State Machine Workflow. On the right is a mock-up of a Windows Smartphone (implemented as a custom WPF control!) , while on the left is a crudely animated graphical illustration of the workflow that is embedded in the application (as designed in the WF designer in Visual Studio).

The idea is that as you interact with the application from the phone, the point you're at in the workflow is highlighted in green, with the workflow engine determining what causes a transition from one state to the next, and handling the transition from state to state:

Now there's a lot more to workflow than this (e.g. Sequential Workflows), but in the spirit of the title of this post there are two major benefits from a design point of view:

1. The WPF host app in this case doesn't care about any of the logic for state transitions / valid options at a given point in the workflow - that's all taken care of within the workflow (which I compiled into a separate assembly). The app just responds to events raised by the workflow, in this case highlighting the correct state with a green box (I did say it was contrived, right?) So it results in a cleaner app, because it naturally promotes a separation between the different components of the application.
2. What I really like about it is that it's almost like wiring a living design directly into your application, and of course any changes that you make to the workflow in the designer are automatically reflected in the workflow code. You can use workflow to model really complex processes with the visual designer and any changes you make are automatically reflected in the code.

Upshot? Reduced entropy! Nice :-)

Cross posted from ronan's blog