Model-Driven Architecture and Development

By Doug Holland (Intel) (208 posts) on October 7, 2008 at 5:23 pm

It is arguable that attempts to raise the level of abstraction within software engineering towards a model-driven approach have been less than successful; with only a handful of projects taking a fully model-driven approach to architecture and development.

As you read this I am curious what your thoughts are on the viability of model-driven architecture and model-driven development approaches and I would encourage you to share your thoughts in the comments below.

A few years before coming to Intel Corporation I had spent some time at Rational Software working on the Rational XDE project, providing UML modeling capabilities within Microsoft Visual Studio .NET 2002 and 2003. Personally I have found the UML to be an excellent communication enabler among project stakeholders, although unfortunately, since IBM's acquisition of Rational Software there has not been an effective modeling environment for the .net architect and developer. With Visual Studio 2010 however, that is about to change.

Microsoft introduced the Class Designer in Visual Studio 2005 and updated it within Visual Studio 2008 to also support the C++ programming language, the first release supported only the C# and VB languages. Although the graphical syntax that the Class Designer used shared some semantics with the UML it was not intended to be UML compliant and therefore did not comply with the UML specification version 2.0, published by the Object Management Group (OMG).

I would argue that through UML tools such as Rational XDE and also the Visual Studio Class Designer, a degree of model-driven architecture and development has been available for some years. That said however, a fully model-driven approach to architecture and development such as the OMG's Model Driven Architecture (MDA) initiative is yet to be truly realized although many tools claim to enable MDA. Microsoft's Software Factories approach is also intended to deliver on the promise of a model-driven architecture and I will be discussing that approach in later posts.

One major benefit of the Visual Studio Class Designer has been that unlike Rational XDE, which required the user to elect to synchronize the model and the code in a process known as round-trip engineering, the Class Designer uses a tripless model where the code and the model were always synchronized. Without a doubt this is a tremendously useful tool although it is arguably more of a code visualization tool and not a model-driven development tool. In fact the team that developed the Visual Studio Class Designer agree with that assertion. Given my background in the UML I have certainly used the Visual Studio Class Designer as a model-driven development tool although I believe I am in the minority in that regard.

UML class diagrams and the diagrams created by the Visual Studio Class Designer enable us to visualize the static structure of an object-oriented set of classes and interfaces. Without an ability to also model or visualize the dynamic nature of our code through UML sequence diagrams it is impossible to fully achieve a model-driven architecture or development approach to software engineering.

At Microsoft's Professional Developers Conference (PDC) in Los Angeles later this month attendees will walk away with an early build of Visual Studio Team System 2010, previously known by the codename "Rosario". Included within the "Rosario" release is support for several UML diagrams including the class and sequence diagrams and I'll be blogging next month about the support for UML modeling within Visual Studio Team System 2010. Another important UML diagram included within the release will be the use-case diagram which is invaluable in modeling the requirements of a system and the relationships and dependencies among requirements.

Although I personally would have liked to have seen Microsoft deliver support for the UML within earlier versions of Visual Studio it is great news that our friends in Redmond have recognized the importance of models to software engineering and are bringing support for model-driven architecture and development to Visual Studio. Microsoft's commitment to modeling is further demonstrated by their recent announcement that they have formally joined the OMG and will help other OMG members build upon the UML standard.

Approaches such as MDA and Software Factories are without a doubt taking us towards a model-driven future although Microsoft has asserted that they continue to see the focus being on the code and not the model. Others within the OMG and in academia envision model compilers that take graphical models and create executables directly from models without first generating code within a third or fourth generation programming language (see Executable UML for example).

As we continue to climb the abstraction ladder towards model-driven approaches to software development and architecture it is likely that the code will remain the focus at least for the next few years.

That said, however, it will become increasingly important to increase the level of abstraction with which we work as we continue to demand more and more from the systems we build. The problem of truly enabling parallelism within the systems we build is an example of a challenge that can benefit from a model-driven approach. Given that enabling parallelism is a design goal of the next version of the C# programming language, it is very likely that future Microsoft modeling tools will enable parallelism to be modeled graphically with C# code generated from the model.

Microsoft's Software Factories approach suggests that a universal modeling language such as the UML is not the right approach and instead the authors of the Software Factories approach tell us that we should instead build custom modeling languages known as Domain Specific Languages (DSL's). It is worth noting however that the UML itself is, in some ways, a DSL built upon the Meta-Object Facility (MOF) and other DSL's can be created using the UML profile mechanism. UML profiles were the enabling technology behind Rational XDE models being aware of concepts from within Microsoft .NET.

Microsoft has taken the right approach, I believe, with Visual Studio 2010 and although it will offer support for the UML it will continue to support the creation of DSL's where appropriate. It may be that a DSL for parallelism is the right approach while there is a very high probability that future versions of the UML will expand upon the languages semantics to describe parallelism concepts.

DSL's are certainly useful although one significant benefit of the UML profile approach to DSL creation is that once you understand the UML you will be able to understand any DSL created using custom profiles, unless of course you introduce custom graphical representations for stereotypes included within the profile.

If an insurance company, for example, creates a DSL using Microsoft's DSL tools they will be unable to hire architects and developers who are familiar with the syntax and semantics of that language. It is not a limitation of the technology, but instead represents a risk that exists where the DSL would require specific training before a stakeholder can understand models based upon that DSL. Another risk associated with the development of custom DSL's is that if syntax is used within a DSL that has different meaning within other languages false assumptions about what a model is attempting to describe can be made by those viewing the models. 

A few well designed DSL's that are shared among the technical communities or within certain segments of industry have proven to be very beneficial although we must recognize that simply because someone is able to learn and effectively use a graphical syntax such as the UML it doesn't make them effective language designers.

It will be interesting to see the support for the UML within Visual Studio 2010 and without a doubt it will provide a huge impact to development teams who, until now, may have very little exposure to model-driven architecture and model-driven development.

Beyond Visual Studio 2010, I would anticipate Microsoft will be provide support for additional UML diagram types that will not be included within the first release. Other enhancements to the UML support will hopefully include support for XMI model interchange and the Object-Constraint Language (OCL). Ideally these extensions, if they are not available within the RTM build of Visual Studio 2010, will be provided within service packs or plugins available through CodePlex.

Categories: Software Engineering

Comments (8)

October 7, 2008 11:58 PM PDT


UX-admin		 "That said, however, it will become increasingly important to increase the level of abstraction with which we work as we continue to demand more and more from the systems we build."

I could not disagree more, and very, very vehemently at that!

For the past 20 years, the industry has made gigantic attempts at abstraction, all in the name of "developer productivity".

What this has brought us instead were armies of people that never learned to program correctly, that never understood programming, that never will understand how to build simple, fast, high-performing and elegant programs. This in turn lead not to shorter, but to LONGER development times, especially in the areas of testing, debugging, and maintenance.
Perhaps those of you in the Silicon Valley / computer vendor environment don't feel it, bu the rest of us out there in the wild, hopelessly stuck with such "experts" feel it very painfully every single day.

What is needed aren't yet more abstractions, we need more people that are down low and close to the bare metal, that fully comprehend how a computer works, and therefore how to get the most out of one in the shortest, fastest, and cheapest ways possible.
October 8, 2008 7:39 AM PDT

Doug Holland (Intel)
Total Points:
10,355
Status Points:
10,355
Black Belt
 I agree there is a need for people who can write extremely low level code and I work with an excellent assembler programmer at Intel who can do some amazing things with the code he writes.

Just because we also need people to be "close to the bare metal" doesn't mean that there can't be a benefit from increasing the level of abstraction. Some people may not feel that a graphical programming language is a real programming language but the fact that we have been climbing the abstraction ladder cannot be ignored. We have moved from programming in assembler to languages such as C and then onto C++, the abstraction layer has then been climbed further with the addition of managed runtime environments such as Java and Microsoft's CLR.

Some would argue that many people are using graphical programming languages today in that when designing a user interface programmers are dragging model elements (buttons etc.) from a toolbar to a model surface (e.g. a Web form).
October 8, 2008 3:50 PM PDT


Box Tode		 "It will be interesting to see the support for the UML within Visual Studio 2010 and without a doubt it will provide a huge impact to development teams who, until now, may have very little exposure to model-driven architecture and model-driven development."

The inclusion of UML within Visual Studio doesn't imply it will come with MDA. At least not without a lot of work on Microsoft's part. It would be an interesting exercise to implement UML (especially the Executable UML profile) as a DSL in Visual Studio but the MDA is a different ball game.
October 8, 2008 6:11 PM PDT

Doug Holland (Intel)
Total Points:
10,355
Status Points:
10,355
Black Belt
 I completely agree and within the above blog post I sometimes meant model-driven architecture to mean simply that, architecture that is model-driven, and not necessarily the OMG's MDA initiative which as you say is a different ball game entirely.

After the initial release I'd like to see Microsoft deliver the complete set of UML diagrams within Visual Studio with advanced features such as support for XMI and OCL. Imagine a TFS checkin policy that was able to evaluate OCL constraints on the model before allowing the checkin of code to proceed.
October 9, 2008 5:29 AM PDT


UX-admin		 "Some people may not feel that a graphical programming language is a real programming language but the fact that we have been climbing the abstraction ladder cannot be ignored."

It's not ignored, it can't be ignored when you are subjected to immense pain from it every single day.

That written, remember that for every abstraction you build into any system, the amount of code and the complexity of the underlying system increases exponentially, and so does the resource consumption. Typical examples are higher memory demands and high CPU overheads.

So, when you are capable of solving the problem of abstraction consuming enormous resources and at the same time being simple, fast, efficient and elegant, then one can say that we're getting somewhere.
October 11, 2008 10:17 AM PDT

Doug Holland (Intel)
Total Points:
10,355
Status Points:
10,355
Black Belt
 In some cases you are right that an increase in abstraction does increase the amount of code although I would disagree that the complexity also increases in all cases. Low level languages are generally more complex than higher level languages.

On the Windows platform, as an example, higher memory utilization is not necessarily a result of increases in the level of abstraction level used to write applications. It is rather caused by the fact that many developers do not understand the implications of many design choices. As an example, when you create a thread within Windows you are allocating 1Mb of user-mode stack and 12Kb of kernel-mode stack. If you open task manager on any Windows based PC it is evident that many developers believe there is no overhead to creating threads. I currently have only a handful of applications running, obviously with background Windows service processes also, and I have 1050 threads within 90 processes.

Abstractions, however, do not necessarily cause us to consume additional resources and here are three examples:

1. Uml tools such as Rational Rose enable you to design at a higher level of abstraction and then generate code at a lower level of abstraction. I would argue that the resultant C++ code in this system would be more aligned with the requirements if those requirements are modeled accurately than if the programmer(s) went immediately to code. Also, raising the abstraction level and looking above the code gives an architect or developer more opportunity to effectively use design patterns to simplify the implementation. When you're in the code of a particular class or interface the opportunity to apply a given design pattern may not be as evident.

2. Microsoft's Common Language Runtime (CLR) and Sun's Java Virtual Machine (JVM) both enhance developer productivity due to the reduced amount of code developers must write in languages such as C# and Java to accomplish tasks when compared to the amount of native C++ code required to achieve the same task. Also, through the use of a virtualization of the actual hardware the opportunities for increasing the security of the system increase due to the fact that the Just In Time (JIT) compiler enforces various secruity policies.

3. In native C++ programming there are also examples of abstractions and one such example is the way in which kernel mode objects on the Windows operating systems are accessed through a handles and not through a direct pointer to the kernel mode object itself.

I personally use modeling languages such as the Uml, lower level languages such as C++, and higher level languages such as C# and Java. It is simply a matter of the right tool for the right job. Writing device drivers obviously requires the code to be written in C++ or assembler, although the performance characteristics of many user interfaces written in higher level languages, such as C# or Java, are acceptable.

It should also be noted that managed code can outperform native code because native C++ is compiled for a specific set of processor characteristics and for this reason many of the shrink wrapped software products available today are compiled for a 386 or 486 processor family. JIT compilers for either Microsoft's Intermediary Language or Java Byte Code are able to establish the characteristics of the actual hardware upon which they are executing and then JIT compile the IL or Byte Code to use the latest in processor capabilities. Today the performance delta between managed and native code is minimal and some algorithms are best written in native code and others in managed code. As processors are built with many more cores than today, the performance delta will become more apparent. Opportunities for JIT compilers to increase the performance of the resultant machine instructions they produce will increase exponentially.
January 9, 2009 1:43 AM PST


Mark Dalgarno		 Hi Doug,

While Model-Driven Software Development is still a niche approach I would argue that there are more than a handful of successful applications out there. The program for our Code Generation 2008 conference had 10 successful industry applications for example and we expect a similar number at Code Generation 2009 :-)

My impression is that the people who are implementing domain-specific languages (as opposed to using them) have a deep understanding of modelling approaches, compiler technology and the 'bare metal'. This is necessary in order to be able to create efficient modelling languages and generators.

You might want to take a listen to a panel session we recorded at CG2007 on UML vs. Domain-Specific Languages. This is of more than historic interest given that participants included Steve Cook (Microsoft) and Andrew Watson (OMG): http://www.codegeneration.net/cg2009/previoushighlights.php
January 20, 2009 12:12 PM PST

Doug Holland (Intel)
Total Points:
10,355
Status Points:
10,355
Black Belt
 Hey Mark,

I couldn't agree more, thanks for adding to the conversation...

- Doug

Trackbacks (0)


Leave a comment  

To obtain technical support, please go to Software Support.
Name (required)*

Email (required; will not be displayed on this page)*

Your URL (optional)


Comment*