WhiteHorse, Software Factories, Oslo - is Model Driven Development Feasible?
-
Tuesday, April 05, 2011 7:32 PM
Various Microsoft attempts at MDD have failed or been put on the back burner: WhiteHorse, Software Factories, Oslo.
Does Microsoft have any strategy for Model Driven Development? Will any of the forementioned tools ever see the light of day?
All Replies
-
Thursday, April 07, 2011 11:42 AM
I've posted a reply to this on my blog: http://blogs.msdn.com/b/stuart_kent/archive/2011/04/07/is-model-driven-development-feasible.aspx- Proposed As Answer by Stuart Kent - Microsoft Thursday, April 07, 2011 3:19 PM
-
Thursday, April 07, 2011 3:54 PM
thank you for your timely response, and I agree with the reference frame describing the continuum of model development processes.
However, I think that the approaches that you have listed (DSL Tools, UML, LightSwitch and Dynamix) are a) not united or integrated; and b) far from delivering on the promise of model assisted/driven/centric approaches.
1) DSL Tools - Having recently worked through the VMSDK tutorials and built a DSL for a customer, I can say that these are hardly user friendly. There is no declarative API, and the VSIX development (e.g. EnvDTE , Introspection, etc.) is archaic and begs for abstraction. See my forum post http://social.msdn.microsoft.com/Forums/en-US/dslvsarchx/thread/5ae59afe-e046-4aac-b3f8-e3a6868d1fb0/
2) UML and the Feature Pack - While it is great that you can shape T4 transforms of UML XMI, there is no round-trip, and I have yet to see a software product that can be completely described using the OO centric UML approach (e.g. UI, SOA architecture) . see my forum post here detailing the limits of UML as a modeling tool: http://social.msdn.microsoft.com/Forums/en-US/modelingandtools/thread/0ca397f3-1c1a-4b54-8bf0-8eb8bfcfd27d/#6f51f8c6-504d-4551-8b71-3c9e33fe6df9 . While I like the Software Factory approach now found in Feature Builder Blueprints, I believe it is not widely adopted because of the effort involved - it is not a seamless or transparent part of ALM.
3) LightSwitch – You are tied to working through the Designer - There is no ability to define entities, screens, relationships and queries through code / markup / a DSL - the DSL is not exposed - you cannot shape the T4. There is no programmatic access to the API underlying the LightSwitch designer, in order to automate LightSwitch application generation (i.e. meta-programming). See the forum discussion I initiated here: http://social.msdn.microsoft.com/Forums/en-US/lightswitchgeneral/thread/321e75a7-7d0b-4b8b-a4ab-228817ddf349/
4) Dynamix - ERP / CRM only cover a fraction of Information System development, which ranges in scale and addresses a wide range of differing functionality- you don't expect most applications to be repackaged CRM systems?
I look forward to your perspective on these points and to hearing about Microsoft's top-secret next-generation Modeling and Meta-programming approach.
you can see my full response at http://geekswithblogs.net/JoshReuben/archive/2011/04/07/does-microsoft-have-a-model-driven-development-strategy.aspx
Until then, I'll keep on coding!
-
Friday, April 08, 2011 11:35 AM
Hi Josh, thanks for your reply and glad that we agree on the overall reference frame.
On (3) & (4) I didn't intend to claim that these are in any way provding a general-purpose platform for model-driven approaches. I was just citing them as exampels of products Micorosft ships which take model-driven/model-centric approaches. On (4) I realize that ERP / CRM only cover a fraction of Enterprise Apps. Sorry if I gave the wrong impression.
On (2), personally I don't find UML a very effective language for model-driven or model-centric development, but there are some large organizations, especially in the defense and telecoms sector who would disagree. I think it has it's place in model-assisted development, and many of our customers want UML tools in VS for just that. Some of the failings you cite in your post are failings of the tools, not the language itself, though the monolothic nature of it's definition does mean that UML modeling tools (ours included) tend to silo models away from code. Advocates of UML might dispute your claim that it can't be used to describe SOA, and point you at component diagrams.
On (1), my colleague Jean-Marc Prieur and I have responded to you post on each of your individual questions.
On your general points, I don't think I claimed that our tools are currently united or integrated, though I do think they deliver on some of the promised value of the model-XXXX approaches. As I indicated in my post, we are currently focusing on consolidation and integration, at least for the tools shipped as part of VS Ultimate, with the goal of doing a better job of (b). And one problem we are looking at hard, is how to get much tighter integration between models and code. Also we expect to deliver updates and new features in an evolutiionary rather than revolutionary way, not least to bring existing users of these tools with us.
Regards,
Stuart
- Proposed As Answer by Stuart Kent - Microsoft Friday, April 08, 2011 11:36 AM
- Marked As Answer by Esther FanMicrosoft Employee, Owner Friday, April 15, 2011 6:05 PM
-
Thursday, April 28, 2011 7:30 AM
In fact, there are several questions in your post, depending on whether your read only the title or the detailed description.
Is it feasible? The short answer is yes. We did not have any single project failure with our CodeFluent Entities product since we launched the SoftFluent company in 2005. So there is at least one way to make it work ;)
Do all model-driven approaches work? Probably not. Talking with customers, it looks like there are very complex tools on the market and not much field experience on model-driven. Many tools try to stick to UML which is overly complex and does not provide much help for implementation level.
Did Microsoft failed at delivering a model-driven approach that works? To date yes, as it has been commented by Visual Studio Magazine here http://visualstudiomagazine.com/blogs/desmond-file/2010/12/softfluents-model-driven-approach.aspx.
Will Microsoft succeed in the end with a model-driven approach? Frankly, I do not know, and I will let the Microsoft people comment, this is no longer my job :) (I used to be a Microsoft chief evangelist some years ago). One could think that Microsoft has all the elements to succeed in this area but there are at least 2 reasons that can make it fail :
* one technical reason is the trend to encompass too many things and in the end make it overly complex as it happened with Oslo.
* a second one could be the mere fact that model-driven makes you somewhat independent of technology level, which is not what Microsoft strategically wants to promote to its customers (it is easy to understand that Microsoft does not really have a vested interest in helping customers being able to easily move away from the underlying platform).
My 0,02 cents.
Daniel -
Wednesday, June 22, 2011 3:23 PM
JReuben1,
Sculpture Toolkit is exactly what you are looking for :)
Sculpture Toolkit is a modeling platform that contains a set of generative components and runtime infrastructures for developing .NET model-based solutions.
Sculpture Toolkit enables you to create your own models 'S-MODEL', textual languages 'S-PAD', graphical designers 'S-DESIGN', and code generators 'S-GENERATE'.The first component 'S-MODEL' which enables you to create your own models. With S-Model designer, you can describe your domain model elements such as Domain Types, Domain Classes, Domain Properties, Domain References, and Domain Enumerations. S-Model runtime empowers your models with many out-of-the box functionalities like Meta-Data definitions, Serialization, Validation, Copying, Comparing, and Transaction Management.
Based on your model you can use the second component 'S-DESIGN' to create your own custom graphical designer. Visually configure your designer Shapes, Connectors, and Toolbox, then generate rich, fully customizable, and extensible WPF designer that works natively inside your Visual Studio.
You can also use the third component 'S-PAD' to create your own custom textual language. Write your language tokens, styles, and syntaxes, then generate grammar, parser, and full customizable language editor with different facilities like intellisense, text colorization, and real-time syntax checking.
Finally you can use the fourth component 'S-GENERATE' to create your own custom code generator. This generator has the ability to understand your model instances and generate artifacts. Visually author your generation process scenario which may have more than one template, each with multiple options. S-Generate utilizes and extends Microsoft T4 templates to easily write your templates. S-Generate also provides an API to facilitate Visual Studio core automation like project and project item construction.
With these integrated and unique components you can create full .NET model-based solutions in a very easy and straight forward.

