Stuart Kent - Software Modeling and Visualization

December, 2005

  • stuart kent's blog

    Seven stages of models


    There aren't really seven, but it makes for a good title (look up "seven stages shakespeare" if you're feeling puzzled at this point.)

    Anyway, I've been watching a debate between Harry, Gareth and now Steven, on the process of building models, including how alike or unalike that is to programming. There also seem to be a number of different terms being suggested for the different states of models - terms like complete/incomplete or precise/imprecise. Now I start to worry when I see terms like that without concrete examples to back them up. So I thought I'd weigh in with some comments, and give a concrete example to illustrate what I mean.

    The general point I'd like to make is that I think models and programs do go through different states, like complete or incomplete, but I wouldn't try to use generic terms to describe these states. I think those states are language, dare I say domain, specific, and depend largely on the tools we have for checking and processing expressions in those languages, be they programs or models. So a program goes through states such as 'compiles without error' and 'executes' and 'passes all tests' and 'has zero reported bugs against it' and 'has passed customer acceptance testing'. At least the first three of those states are very specific to programming - we know what it means to compile a program, to execute it, to test it. We'll have to find different terms for different kinds of model.

    And if I was going to use a generic term for the sliding scale against which we can judge the state of a model or program, I would use the term 'fidelity', as it has connotations of trustworthiness, confidence and dependibility, which terms like 'precision' and 'completeness' don't really have.

    So now for an example of stages a model might go through, taken from my very recent experience as we are developing Dsl Tools (I apologize for the mild case of navel-gazing here).

    In the last few days I've been developing a new domain model for the new Dsl definition language that will replace the designer definition (.dsldd) file we currently use in Dsl Tools. There are various stages which that model goes through. I don't bother with sketching it on paper, as the graphical design surface is good enough for me to do that directly in the designer. I miss out lots of information initially, and the model is generally not well-formed most of the time. However, I then get to a point where I'm basically happy with the design (or as happy as I can be without actually testing it out) and I'm ready to get it to the next level of fidelity. Let's call this 'Initial Design Complete'.

    For the next step, I start by running a code generation template against the model, which generates an XSD. This usually fails initially, so I then spend time adding missing information to the model and correcting information that is already there. Finally the XSD generation works - I have more faith in my model than I had before. This is the 'XSD generation succesful' state.

    Now I've got the XSD, I develop example xml files which represent instances of the domain model I'm building (in this case, particular dsl definitions) and check they validate against the XSD. I find out, in this stage, whether the model I'm building captures the concepts required to define Dsl's. Can I construct a definition for a particular Dsl? As these examples are built, I refine the domain model, and regenerate the XSD, until I have a set of examples that I'm happy with. The fidelity of the model is increased and I'm much more confident that it's correct. We might call this the 'All candidate Dsl Definitions can be expressed' state.

    The next stage, which will now mostly be done by developers I work with, is to write the code generators of this new format that generate working designers. We'll write automated tests against those generated designers and exercise them to check that they have the behavior we expected to get from the Dsl definitions provided as input to the code generators. This process is bound to find issues with the original model, which will get updated accordingly. This might be the 'Semantics of language implemented' state, where here the semantics is encoded as a set of designer code generators.

    So how is this process similar to programming? Well, with programming I'd probably do my initial sketches of the design on a whiteboard or paper. I might use a tool like the new class designer in Visual Studio, which essentially visualizes code, and just ignore compile errors during this stage.

    When I think the design is about right I'll then do the work to get the code to compile. I guess that's a bit like doing the work in the modeling example above to generate the XSD.

    Once I've got the code to compile, I'll try and execute it. I'll build tests and check that the results are what I and the customer expect. This, perhaps, is analagous to me writing out specific examples of dsl definitions in Xml and checking them against the generated XSD.

    We could probably debate for ages how alike generating an XSD from a domain model is to compiling a program, or how alike checking that the domain model is right by building example instances in XML is to executing and testing a program. I don't think it really matters - the general point is that there are various stages of running artefacts through tools, which check and test and generally increase our confidence in the artefact we're developing - they increase the fidelity of the artefact. Exactly what those stages are depends on the domain - what the artefact is, what language is used to express it, and what tools are used to process it.

    Now it would be interesting to look at what some of these states should be for languages in different domains. For example, what are they for languages describing business models...

    [10th February 2006: Fixed some typos and grammatical errors.]

  • stuart kent's blog

    The ideal tool...


    Just noticed this little nugget over on Steven's blog at MetaCase (just gloss over the blatant marketing):

    "Obviously the ideal tool would be as fast and powerful to use as MetaEdit+, and have its maturity, but also have the extensibility of Microsoft's DSL Tools, without crashing into the customization cliff. It should however run on all platforms like MetaEdit+, but be tightly integrated to Visual Studio, Eclipse, and vi. And be free, with complimentary commercial support. But I digress..."

    And whilst we're using it, we can stare dreamily out of the window and not be surprised as we watch a pig float gently by in the warm summer breeze...

  • stuart kent's blog

    DSL tools samples download now available


    Like buses, you wait a while then two come at once. That's right, just a week after we released the latest version of DSL Tools, we've also released an update to the samples. This download includes:

    1. A complete end-to-end sample of a project in which most of the code is generated from a DSL, and the use of the new validation and deployment features is illustrated. A detailed guide describes the features and their use.
    2. Examples of using custom code to enhance languages developed with the DSL Tools, together with a detailed guide. Features demonstrated include: computed properties, constraints on connections, line routing, shadow & color gradient control, shape constraints, and template-generated code.

    (1) is brand new. (2) is an update of the samples we released a few weeks ago.

    And next? We should get some more documentation up soon, and we're working on integrating the release into the VS SDK. After that, you'll have to wait a while as we do some root and branch work on some of the APIs and replace the .dsldmd and .dsldd with a single .dsl format, with it's own editor (yes, editing .dsldd files will become a thing of the past). We'll also be supporting two more pieces of new notation - port shapes and swimlanes, and providing richer and more flexible support for persisting models in XML files. Our goal is a release candidate at the end of March. 

  • stuart kent's blog

    The creator of WiX blogs about the deployment feature in the new release of DSL Tools


    In the latest release of DSL Tools we make use of the WiX toolset to create MSIs. Rob Mensching, the creator of this toolset, has blogged about what we have done. Without WiX, our job would have been much harder in implementing this feature... so thanks, Rob.

    Rob also mentions Grayson Myers in his blog. Grayson is a dev on the DSL Tools team who implemented (and, to be frank, designed) this feature. Rob is right to compliment him on his efforts.

  • stuart kent's blog

    New release of DSL Tools available


    Our next release of DSL Tools is now available.

    This release works with the final released version of VS2005. Goto the DSL Tools website at to download it.

    This is the release I talked about in my blog entry at

  • stuart kent's blog

    Automating tedious tasks (2)


    In my last entry I talked about how to go about automating tedious tasks for developers. Of course, developers are not the only people involved in software development. What about automating stuff for everyone else?

    Part of my job involves project management, and recently I've experienced the joy of having tasks automated for me. In particular, as described in an earlier blog entry, I have been able to set up a spreadsheet to connect to the work item tracking system in Visual Studio Team System and have burn down charts created for me (nearly) automatically - takes me 5 mins per day to update them. (I have talked with the team system guys, and it looks like I can do even better, using some of their built in reporting facilities - I just don't know how yet.) This has freed up loads of time, which I can now put to good use in the creative aspect of program management - working out what the product needs to do now and in the future, working through scenarios, writing specs, working closely with developers. I get the added benefit of having real-time tracking data at my finger tips which helps me identify risks and problems earlier.

    One aspect of Team System that I like a lot, is its configurability. They realized that a closed world solution was not going to acceptable in managing software development projects. So they've made sure that you can get at the data through APIs, that you can design your own work item types (every organization needs to record slightly different information to the next), that the data can easily be exported to the Microsoft Office applications Excel and Project, that there's linkage to sharepoint for document storage. This makes it much more likely that you're able to customize the product to automate tasks that suit you or your organization's way of working. And so I've found for the work that I have to do.

  • stuart kent's blog

    Automating tedious tasks


    I've just added a new byline to my blog: automating tedious tasks.

    A complaint often levelled at Software Factories is that it will turn developers into automatons, just pushing buttons to drive the factory to do all the clever stuff. I think the exact opposite is the case. The point of technologies, such as DSLs, which we're building to support the Software Factory vision, is that they are focused on removing those tedious and boring tasks, thereby releasing the developer to focus on the creative and interesting parts.

    For example, you can write some code by hand which uses the same label in a number of places, as part of a property name, part of a class name, to identify a database, in the title of a web page, and so on, and then every time that term changes (which it will) you have to go and make the change by hand in all those places. Wouldn't it be better if we had tools which allowed you to identify that the particular label was used in a number of places, and then propagated the change to the label in all the places it's used whenever you need to change it? Then, instead of looking at an hour or more spent laboriously working through the code changing all uses of the label, you can do that in a couple of seconds and spend those hours trying to work out that tricky algorithm you've been stuck on. 

    DSL Tools supports something like this. We're lowering the bar to defining small domain specific languages from which code can be generated. So the label referred to above will be captured in one place, in an expression of the DSL, and change to that label will be propagated to all the places it's used by the code generators. Now, in DSL Tools at present, code generation is fairly crude (but still useful). You can generate complete text files - as many as you like. This does mean that if you need to write custom, hand-code to finish off the generated code, you need to put it in separate files. With the partial class facility of C#, this is not so restricting as it might seem (assuming you're coding in C#, that is). I fully expect developers writing and adapating the code generators, as much as I expect them to be writing the custom code in the carefully worked out plug points. Our challenge, as vendors of a tooling platform, is to enable this way of working at a finer level of granularity and with an even lower bar to entry.

Page 1 of 1 (7 items)