Model-driven development – Embedded v/s Enterprise software

I recently attended a session on MDD organized by IBM. Following are my take-ways (besides a sumptuous meal, leather wallet & keychain :-))  from the session. I also try to arrive at a set of foundational MDD principles that are key to successful implementation in Enterprise product development, mostly from a Tooling support perspective.

As it turned out, it was directed at the “Embedded Systems” community and the Lead presenter was from Telelogic(now an IBM company) . He was well-supported especially on the demo-front by an experienced IBMer.

 The main showcase was the capabilities of Telelogic’s Rhapsodyas an MDD tool for Embedded software development and some other tools that support a complete process.

 I was pleasantly surprised to see the level of sophistication as well as adoption of MDD in the Embedded field. Dig deeper though and it makes sense when we (the customer) place such strict quality demands on embedded software. As basic hardware systems become more and more  “intelligent” via embedded software it was probably imperative that people like Telegic had to adapt for example – auto-industry product development practices in bringing a new car model into the market, to the software used.

 The key message 1 – There is need to diligently and efficiently  perform a lot of modeling, prototyping & testing for a huge number of conditions (and platforms) before eventual product rollout.

 Again, in the auto-industry, when we look at Costs involved in setting right either an electro/mechanical or embedded software glitch on a production vehicle, it can be  quite huge, varying significantly with the duration for which the particular make is already into production because that many more units could be in circulation with a possible global footprint. Respectable auto manufacturers actually issue a free recall of the defective instances. (E.g. Mercedes Benz, Honda, VW).

 The key message 2  – There is a need to apply the same strict quality requirements irrespective of hardware or software components of the product implying a drastic raise in quality of software component. The earlier the defects are detected in product lifecycle the more significant the Cost savings.       

 So we do understand some of the imperatives of the Embedded software industry and it starts making sense to a good extent to bind our Enterprise software products to these same imperatives.

 But, with the way things are today, Enterprise software may not face the ire and scale of say a car-maker having to recall a batch of failed units or a phone-maker having to recall millions of faulty batteries. The vendor usually issues a patch schedule all covered by a support contract and this money spinning method may not go-away so soon. For e.g. for the equivalent of say – GM India offering 3-yr warranty with NO maintenancecosts on its vehicles,  to happen in the Enterprise product world, seems like a reaaally distant dream.

 The support-based operating model actually negatively impacts the business case for MDD in Enterprise products. So we might ignore key message 2 or restrict its scope to product development lifecycle as opposed to entire product lifecycle. That leaves us with key message 1which I believe is imperative enough to adopt MDD.   

 So here’s a list of “MDD tenets or principles” that the embedded software community has evolved and refined to a great extent, that can readily be used for Enterprise software products.   

1.  MDD needs a highly Structured approach to Requirements Gathering that can then be easily traced (in an automated fashion) to every single Model & Code artifact. Ignoring this, and only working out of the Model can lead to the same problems we face with traditional software development, ultimately affecting quality of the product.     

 

2.  MDD needs to enforce exhaustive use of a design process & design language  E.g.  Use case models should be linked  to structured requirement ids, that are linked to Object models, sequence/flow, and state models, which are in turn linked to respective code and configuration artifacts.  

 

3. The primary MDD tool must use a single unified repository representing all requirement, model & code artifacts, ensuring a very tight synchronization between them. This core artifact-base could be represented in a common format and each of the Models and Code are simply  different views of the common format artifact-base. This is actually the crux to solving the Round-trip Engineering problem. For E.g. As soon as you drop say a class object  onto a model area, the tool near-instantaneously creates the code behind. Also any code written, immediately updates the Model Views. One can see the likeness with GoF Observer design pattern.

 

4. The MDD tool must support a Comprehensive Testing strategy. This includes automated developer level Unit & Integration style Test case generation from Model & Code artifacts, execute & report on code coverage as well as link the coverage & test pass/fail metrics to Requirements coverage.     

 

5.  The MDD tool must provide Dynamic modeling capabilities such as Sequence diagram generation derived from runtime code, profiling etc. 

 

6. The MDD tool must support clear separation/abstraction of environment or platform specific feature usage from the Core product. It may do so by providing customizable APIs or macros.    

 

 Enterprise software poses few unique challenges of its own that needs further innovation & techniques to deal with. The single biggest challenge I believe is  the following which impacts and magnifies complexity in every other principle mentioned above.  

•  We usually build enterprise on the base of popular open source frameworks such as Swing, Struts, Spring, EJB, Hibernate, iBATIS, etc and even advanced frameworks such as JBPM, Drools & Mule ESB. We also use at times, home-grown equivalents of these frameworks. The Enterprise MDD tool must support – Model, Code & Test Casegeneration according to “terms” dictated by these frameworks. In other words the MDD tool needs to understand the artifacts required by these frameworks just as it would normally understand a Java class.  

 

 Concluding Notes

I believe there exists a significant gap even in basic MDD capabilities between the Embedded world and Enterprise world. Solutions to Enterprise MDD challenges may still be evolving.  There may be cases were Enterprise users have cracked these problems, though it is very likely that in such cases, they had only their own home-grown frameworks  to content with.  Still, their learnings could  be very useful to adapt the techniques to mainstream open-source framework based Enterprise software deveopment. Would the Enterprise MDD gurus please care to share?