RE: VSTS 2005, DSL, and Software Architecture
This is a response to a blog posting by Tad Anderson, and the pointer to it on the MSDN Architecture General forum.
First, I agree with your observation, Tad, about the lack of support for the Software Architect in VSTS 2005. We did indeed focus on the System Architect not the Software Architect. We had limited resources to allocate to architecture tools, and felt it was more important to support Microsoft’s drive toward connected systems for the 2005 release. As you suggest, however, we do intend to address the needs of the Software Architect in subsequent releases, and most of that support will come from our Software Factory strategy.
However, I disagree with your assertion that our Software Factory strategy, with its reliance on DSLs, will “make a huge mess”. From your comments, I gather that you haven’t read the Software Factories book, or been exposed to the many white papers, blog postings, conference proceedings, articles and podcasts that we’ve produced, since they address the issues you raise at length. I will summarize them here, but I'll also point you to the those other resources, where you learn a lot more about what we’re doing and why.
While it’s certainly true that unqualified practitioners might abuse our technology, there is nothing about our technology that makes it particularly susceptible to abuse. As we know, there is nothing to stop people from writing bad code in Java or from creating ineffective UML models.
However, we have admittedly not done a good enough job of making clear that we intend people to build DSLs primarily in the context of Software Factories. Yes, we do expect them to build standalone DSLs, but the primary goal of productizing the DSL technology was to support factory development. Why? Two reasons:
1) Factories provide a methodology for determining what to model for a given product family. The key to using DSLs effectively is to understand how solutions are developed for a given problem domain. Factories are organized around a model of the development process for a given problem domain. This model, called a factory schema, is a graph of viewpoints. A viewpoint defines the perspective of a specific stakeholder or a specific role in the project team. As recommended by IEE 1471, and the book Documenting Software Architectures by Clements, et. al., we use the graph of viewpoints to define the product family architecture. We also use it to define the development process, or what Product Line Engineering calls the production plan. Each viewpoint describes the set of workflows used by its stakeholders, the work products acted upon by those workflows, and a set of assets, such as tools, templates, class libraries and guidelines, that support the enactment of those workflows. How does this relate to modeling? The schema shows us what to model. Each viewpoint defines a domain, such as logical database design, user interface process or business rule definition. These domains are aspects or subsets of the larger problem domain defined by the product family. We may only know enough from experience about such a domain to supply documentation assets, such as patterns or practices, to its stakeholders. However, if we know enough about it to model its key concepts, then we can supply more powerful assets, such as a DSL and tools that perform generation, validation, trace, analysis and other forms of automation using models based on that DSL. Of course, implicit in this approach to modeling is the assumption that DSLs are more effective than general purpose modeling languages like UML for model driven development because they are highly focused on specific problem domains. That point is discussed at length in many of our publications, including our Modeling Strategy paper. In summary, a factory contains a model that provides a basis for determining which aspects of a problem can and/or should be supported by DSLs, and how DSL based models should relate to each other and to the work products of non-model driven activities.
2) Software development is about more than just models. While it’s nice to think that some day, we might develop every part of a system using models, just as we currently develop every part of an application using 3 GLs rather than assembly language, it’s just not feasible today. You can hear more on this topic in the recent ARCast on MSDN. Because we take this pragmatic view, we require factories to provide whatever assets are most appropriate to support the enactment of the workflows for a given viewpoint, and not just on modeling. A modeling tool is just one kind of asset that factory builders can provide to support factory users, but there are many others. This is one of the fundamental differences between Software Factories and MDA. You can read more about the differences between them in the article that I wrote for the newsletter of the International Association of Software Architects.
Regarding the effect of our strategy on industry standards, I think it was inevitable that people would demand more focused modeling technologies. Within the OMG, there is very strong momentum toward domain specific modeling. It just happens to be expressed using UML profiles, which are awkward at best. A large block of OMG members would prefer to see domain specific languages defined using the Meta Object Facility (MOF). In effect, that’s what we’re doing, too. However, we don’t use the standard MOF. Neither does IBM, Sun, or anyone else. Why? Because the MOF maps to the internal architecture of the modeling tool. Experiences like IBM AD/Cycle show that tool internals cannot be standardized effectively, since vendors must be free to design and implement tools in response to market changes, not standards committee proceedings. Based on these experiences, we prefer the standardization of interachange formats – not interchange formats like XMI, which depend on MOF alignment to achieve interoperability, but interchange formats like the ones defined by UN/CEFACT, RosettaNet and HL7 to name a few.
As for learning a new language with every gig, you have to do that anyway, whether you’re using UML profiles, or no modeling language, at all. While the UML defines a set of widely understood notational styles, the meaning of any given profile must be learned. This should come as no surprise. What you really have to learn with every gig is the problem domain, or rather the many subsets or aspects of the overall problem domain, and how they all relate to each other. The goal of software factories is to help solve that problem. The software factory schema provides a way to model all of the aspects and their interrelationships. While the DSLs that people build using our tools are unique, they are usually based on the notational styles supplied by the templates that we provide. They happen to look a lot like UML notational styles, of course, and that’s intentional. We have no interest in reinventing the wheel when it comes to notational styles that have proven effective. By the same token, we have not followed any of UML notational styles that have not proven effective, such as the deployment diagram.
It’s true that that we have not yet aligned Software Factories and MSF. That is currently work in progress. When the alignment is published, I think you will find that the result quite different from RUP and XP. For one thing, the development process in a factory is organized around viewpoints, as I’ve just described. For another, the workflow in a factory is driven not by sequential execution, by pre- and post- conditions associated with each activity. Activities come into scope when their pre- conditions are satisfied and go out of scope when their post- conditions are satisfied. Work can be done in any order subject to these constraints.
It’s also quite true that we need to provide a more complete set of tools and templates to support the Software Architect, as you suggest. That’s what we’re busy doing.
Finally, I should point out that a critical mass of industry experts supports our work.
For example, if you read the Acknowledgements in the Software Factories book, you’ll find that we leaned heavily on the work of Paul Clements and Linda Northrop, and met with them multiple times in person. You’ll also learn that Paul was a reviewer, and you’ll find his endorsement of our work inside the front cover.
If you look at our web site, you’ll discover that Linda Northrop invited me to give the keynote at the SEI sponsored Software Product Lines Conference 2004, giving an overview of Software Factories.
If you look at our blogs, you’ll find that Martin Fowler had some complimentary things to say about our strategy in his paper on Language Workbenches.
It may be worth mentioning, while we’re talking about industry expert response to our work, that we have had and continue to have critical interaction with some of the other people on your list, including Mr. Jacobson, Mr. Ambler and Mr. Evans.
Inside the front cover of the book, you will also find endorsements from Doug Schmidt, lead author of Pattern Oriented Software Architecture, Volume 2 (POSA2), David Frankel, author of Model Driven Architecture, Krzysztof Czarnecki, author of Generative Programming and leading voice in the industry on feature modeling, and John Crupi, lead author of Core J2EE Patterns and the writer of our foreword.
There are many other industry experts who continue to review our work, share their thinking with us, and generally advise us in our efforts to craft a pragmatic approach to software development that is firmly rooted in proven practices from software product lines, model driven development and service oriented architecture. You can read what many of them have written in the papers they submitted to the International Conference On Software Factories at OOPSLA 2005.
Comments
- Anonymous
January 08, 2006
I have posted 2 responses to this blog at http://realworldsa.dotnetdevelopersjournal.com/dsl.htm, and one to Steve Cooks Question about what UML I would like to see support http://realworldsa.dotnetdevelopersjournal.com/umltoolsfromms.htm
I would like to also get some idea of how MS envisions this movement supporting the smaller applications. Software factories will be great for the bigger companies who are investing in PLE or engineering firms, but what about the smaller apps that are just single application builds that usually fall under the pieces and parts of an Enterprise architecture. Where you find a bunch of apps that are being integrated at the enterprise level, and have they have they there own specs within the scope of just those apps. Uml worked great for those types of apps. Or the single application shops, that just are building apps once for client requirements. UML also worked great for that.
I’d be willing to send you and certain other individuals examples of what I am talking about after I get permission from certain individuals, but I cannot post them. Some of the companies are history, so some of it I could send if you are interested with out permission. But I won't post them.