By Peter Bell

DSM/SPL: What is a Model Statement?

I seem to have a worrying habit of making up my own terms. Whether it's the "Iterating Business Object" in the CFML world, "mixin injection" in LightWire or now "model statement" which seemed to confuse people who know a lot more about DSM and SPLs than I do (which suggests it's not a common term in the industry). So, I guess I need to explain my term as I'm yet to find a better word for it and it's a very important concept when you try to reuse models across a software product line . . .

What is a Model Statement
Lets say you have a model of a state machine with 7 states. Often in a SPL you want to be able to reuse specific states as my project only needs 5 of those states whereas yours needs all of them plus a couple of additional states. So, to avoid the problems we ran into with component based software development where we had to keep adding more and more properties to each component until they became unwieldy (because each additional project required a few additional configuration options for each component), we need to be able to reuse not just models but to have reuse at a more granular level.

For the lack of a better term I'm calling these elements "model statements". If you're using a declarative textual syntax, a model statement is probably one line of code. If you're using visual tools it's probably a box or a line. If you're using an XML concrete syntax it's a single element (but not any composed elements - those are separate statements).

So, if you're describing business applications, your object properties are each a model statement (FirstName and LastName properties of a User, for example). Reuse at this level of granularity is essential to have flexible reuse of models as being able to reuse a User model without being able to customize their Properties is extremely limiting and while you could solve the problem with model transformations (everyone gets the same User model and then applies different model transformations to add or remove properties as required), I find that the ability to reuse model elements independently provides for a lot more flexibility as long as you have intelligent packaging mechanisms (so when you select a IShippable interface for Products they automatically get Weight, ShippingSupplement and HazardousShipping properties). Of course, this raises its own set of issues in terms of constraints because in practice you can't have a Weight property for a Product entity if you don't *have* a Product entity, but those constraints can be handled at a separate level.

I just wanted to define the terms as we're going to need it in the next posting looking at concrete syntaxes for model reuse. Do you have a better or more widely used term for a "model statement"?

Comments
BlogCFC was created by Raymond Camden. This blog is running version 5.005.