By paul ~ November 6th, 2008. Filed under: Systems Engr..
I don’t know about you, but, as a systems engineer, when I see the phrases Model Driven Architecture (MDA) or Model Driven Design (MDD), I’m filled with anticipation and expectation. The terms seem to have a pretty obvious meaning. I immediately associate these terms with prototyping, bread-boarding, and other hands-on design exploration methodologies that have been used forever.
My uncle, who was an artist, created plasticine models of his subjects, tweaking them, experimenting with them, and frequently tearing them up and starting over before committing them to bronze or oil-on-canvas. Analog hardware designers often explore designs interactively by breadboarding their circuits before committing to schematics. Architects create conceptual drawings and mockups to use in interactions with their clients to explore different design options and refine requirements. These are the associations I have when I hear the term “Model Driven Design.” It’s highly interactive. It’s malleable. It’s fast. It’s cheap (at least relative to the act of producing the final product.) It’s a great way to refine requirements and get a better understanding of what will work and what won’t.
So, why is it that when we sit down to read about MDA & MDD as defined by OMG, we get a headache? Malleable? Fast? Cheap? Interactive? Ugh!
With the advent of high-level, graphical modeling languages and simulation, we should expect that system design (any system design) should be able to utilize Model Driven Design as described above. After all, what is more malleable than a diagram on a computer? And what’s more interactive than a computer simulation? For those of us who want “instant gratification” as we develop our designs, computer modeling and simulation should be the ultimate satisfaction. I maintain that it can be and that it’s here now, and you don’t have to get a PhD to use it!
The Foresight tool suite isn’t the only environment that enables the kind of “Model Driven Design” I’m going to talk about here, but it’s the one I use and it works well, today. The methodology described here has been used successfully for problems ranging from simple embedded system design to complex system-of-systems and business process modeling. If you want to do some real, interactive modeling and simulation that can lead to very complete, complex models of your system and can benefit you throughout your design activity, read on.
<rant>Did you know that the OMG has trademarked terms like Model Driven Design and Model Driven Architecture? This fact has been made perfectly clear in the Wikipedia article on the topic. As if they invented these concepts! It cracks me up. Frankly, the OMG scares me. Their committees are churning out standards to better our lives extremely rapidly and, unfortunately, not all of them look friendly to those of us in the trenches doing the real work day after day! Standards can be extremely valuable, but it feels a bit like we’re being buried under a pile of rapidly developed, ill-conceived efforts.</rant>
Real Model Driven Design
First off, I need to make it clear that my focus is on the design of complex systems with a mixture of hardware, software, mechanical, and possibly human components. If we are talking about pure software systems, then I will concede that there are some MDD software toolsets and flows built around UML that are pretty complete. I will also concede that the highly motivated, creative systems designer can bend these tools and flows to meet their needs. SysML is an effort to extend UML to our needs but, unfortunately, right now it looks like one of those ugly, ill-conceived standards I was referring to earlier. We live in hope that it will yet evolve into something we can use effectively.
A real model driven design methodology will have the following characteristics:
- The Modeling Language is used to express the designer’s intent. As such, it must be concise, expressive, easy to learn, able to express concepts at a level of abstraction above the hardware/software/mechanical decision, and formal (machine analyzable and executable.) Several of these imply that it should leverage diagrams and not only be textual. In order to make it easy to learn and expressive, it should leverage familiar modes of expression.
- A Model, fundamentally, behaves sufficiently like the real system to be useful, is analyzable, communicates intent, is inexpensive to produce and is malleable (easily changed to explore options.) To be analyzable by machines and humans, it must be fairly formal. To communicate intent in a useful fashion, it must be understandable to all stakeholders with a minimum of “re-education.” Ideally, it is possible to communicate intent to implementation via automation (i.e. implementation or more detailed design can be generated directly from the model.)
To apply these concepts, consider the fact that a UML flow as most-often used does not satisfy these requirements. While UML satisfies most of the requirements of a Modeling Language, it is seldom used to create real Models. This is partially because it is a poor modeling language (it is not expressive in the manner needed for it to be easily analyzable.) Very good tools have been developed to help with this, (e.g. Telelogic’s Rhapsody) but it’s still not pretty. In common UML flows, the UML artifacts produced are to a real Model as a set of architectural drawings are to a 3D, fly-through model of a building set in it’s environment. Imagine an architect only having architectural diagrams available to him as he discusses his design with a customer. What are the chances that the customer will be able to understand the technical diagrams sufficiently to know whether requirements are met? What are the chances that requirements will be missed (not exposed) because the customer was unable to visualize the end product? In reality, UML is a graphical, detailed software design language, not a modeling language.
On the other end of the spectrum are languages for building simulations and the resulting simulations (SystemC, HDLs, etc.) These satisfy some of the requirements of a Model Driven Design methodology, but fail to meet some of the most important ones. In particular, these languages tend to not satisfy the human communications requirements of modeling languages, nor do the simulations created by them satisfy the breadth of analysis implied by a real Model or the “communication” aspects of a real Model. These are very important requirements. Finally, these languages are not easily accessible to new adopters (hard to learn) and expensive in effort to use. The idea of using them early in the design cycle to explore requirements with customers (at the system level) is a bit strange at best! These kinds of methodologies often do have very good automated connections to the implementation process.
Real Solutions, Today
There are a number of methodologies available today that satisfy most of the requirements for a true Model Driven Design methodology. In addition to Foresight, the MathWorks and National Instruments tool suites are stellar examples within their target domains. (The MathWorks has an awesome magazine ad that has the words “320,000,000 miles, 380,000 simulations and zero test flights later. That’s model-based design.” in front of a picture of the martian surface from the Mars rover. Now THAT’s what I’m talkin’ about!) These tools are not newcomers, they’re widely used and proven for very large systems design, they have expressive, easy to understand modeling languages, and real engineers can use them to get the job done. For the most part, they have different target markets and complimentary capabilities. Choose the one that works best for what you’re building.
If you’ve got an opinion on this topic, I’d love to hear from you. We need an honest, open discussion of the issues in the industry.