VSTS阵营最近发布了VSTS建模策略和FAQ,下面是我的小小读后感，只是草草一读，姑妄言之，姑妄听之
（为方便起见，还是把原文拷贝过来了，中间有少许点评，最后有小结 ；））
Visual Studio 2005 Team System Modeling Strategy and FAQ
May 2005
Applies to:
Microsoft Visual Studio 2005 Team System
Summary: Customers and partners are keen to understand Microsoft's strategy for model-driven development and its support in Visual Studio Team System. When we explain our strategy to them, they frequently express interest in some of the same topics, and raise some of the same concerns. In this document we set out our strategy for model-driven development as a series of questions and responses that address these topics and concerns. The first five questions deal with the main pillars of our strategy, which we have described with detailed answers and explanations. Other frequently asked questions are gathered in a conventional FAQ in the last section. (15 printed pages)
Contents
Why Modeling?
How Are DSLs Used in Model-Driven Development?
What About UML?
What About MDA?
What Are Software Factories?
Other Frequently Asked Questions
Customers have told us that many of the CASE tools they bought in the '80s and early '90s did not add sufficient value to the development process. Benefits by which they were sold failed to materialize, and even good products were swamped by the over-hyping of the promise of the technology.
If the models they supported did not reflect the code and other implementation artifacts, they quickly became irrelevant. If the models they supported were used to generate code, they typically got out of sync once the developers added other code around the generated code. Even products that did a good job of "round tripping" the generated code, eventually overwhelmed developers with the complexity of solving this problem. Often these problems were exacerbated because CASE tools tried to operate at too high a level of abstraction relative to the implementation platform beneath. This forced them to generate large amounts of code, making it even harder to solve the problems caused by mixing hand-written and generated code.
点评：对传统CASE工具结合较高层次模型和实现代码的方式提出了质疑。
Despite these issues, there is a belief among those involved in software development that somehow, modeling can be applied to make their lives easier. Our vision is to change the way developers perceive the value of modeling. To shift their perception that modeling is a marginally useful activity that precedes real development, to recognition that modeling is an important mainstream development task and not an activity primarily focused on documentation. When models are regarded as first-class development artifacts, developers write less conventional code since more powerful application abstractions can be employed. Model-driven development is thus inherently more productive and agile. Moreover, others involved in development, from business analysts, architects, designers to network staff, and system management specialists, will perceive modeling as adding value to the tasks for which they are responsible. When models span development and run-time activities in this way, communication between people can be optimized, and traceability enabled across the life cycle in any direction. We hold that making modeling mainstream in this way can ultimately change the economics of software development and ensure software systems meet the needs of a business. This approach to model-driven development is part of an initiative at Microsoft called Software Factories.
点评：反对先建模、后编码，而是应该建模和编码同时开展。
点评：模型是开发中的first-class开发工件，贯穿整个开发生命周期，联系不同stakeholder……这些都和MDA并无而异，但微软把它叫做软件工厂。
Note Software Factories are described in depth in the book "Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools" by Jack Greenfield and Keith Short, with Steve Cook and Stuart Kent.
How Are DSLs Used in Model-Driven Development?
Microsoft has learned from past industry experiences, and plans to avoid the pitfalls of CASE by adopting an approach to model-driven development based on the following ideas:
· A model should be a first-class artifact in a project—not just a piece of documentation waiting to become outdated. Models have a precise syntax, are often best edited and viewed using a graphical tool, and embody semantics that determine how domain-specific concepts in models map to other implementation artifacts, such as code, project structures, and configuration files. In this way, a model is a lot like a source code file, and the mechanisms that synchronize it with other implementation artifacts are a lot like compilers.
· A model represents a set of abstractions that support a developer in a well-defined aspect of development. For example, consider the task of producing a service-oriented application that connects components using Web services. Given all the other tasks a developer must focus on to build such an application, there should be a time where he can just focus on defining overall application connectivity in terms of service contracts and the messages they interchange. The Visual Studio Team Edition for Software Architects' Application Designer supports exactly that aspect of development, and manages the relationships between an application connectivity model and all of the other artifacts (WSDL files, project file, code file, configuration files, etc.) that must be developed to implement the interconnections defined by the model. Models designed to be used as source artifacts in this way have the added benefit of providing a holistic view of otherwise scattered details, and can streamline communication between different groups involved in designing, building, and deploying complex modern applications.
· Since models can abstract and aggregate information from a number of artifacts, they can more readily support consistency checks and other forms of analysis. For example, an application connectivity model might support contract protocol validation, security analysis, or performance analysis.
· Models can be implemented by a process similar to compilation, where the code, configuration files, and other implementation artifacts generated by the compiler are never edited by hand. More often, however, they are implemented by a combination of generated and hand-edited artifacts. In such cases, it is critically important to carefully manage the way the generated and hand-edited artifacts fit together. As mentioned above, the failure to do this effectively was one of the primary shortcomings of CASE products. We have been using several techniques to ensure that generated and hand-edited artifacts are kept separate, and that code added by a developer is never disturbed when boilerplate code required by a tool is generated. These techniques include the use of class delegation and inheritance, and particularly the use of "partial classes," a new feature of the .NET languages in Visual Studio 2005, which has been specifically defined with this task in mind.
点评：对模型的操作直接操作在模型上，而不是对模型生成的代码等进行操作，这样避免了模型和代码不同步的问题。微软用了几种技术来分离模型生成的代码和手工书写的代码。这些技术包括class delegation and inheritance，以及"partial classes"的使用，后者是Visual Studio 2005中.NET语言的一种新功能。
We call modeling languages defined in these ways Domain Specific Languages or DSLs. Think of a DSL as a small, highly focused language for solving some clearly identifiable problem that an analyst, architect, developer, tester, or system administrator must wrestle with. Developers are already familiar with examples of DSLs; SQL for data manipulation, XSD for XML document structure definition, and so on. Another example from Visual Studio Team Edition for Software Architects is a DSL for modeling the logical structure of datacenter hardware and host software configurations. This DSL and its related graphical designer can be used to validate during design time that applications are configured to match their intended deployment targets, alerting the developer to problems when they can be fixed more cheaply.
点评：看不出DSL和MDA中的M2层元模型有什么区别，除了不遵守MOF规范。Btw，目前MOF规范也没有表现出多大的让其他语言遵守的说服力和吸引力，其优越性很大程度停留在理论上，而缺乏更清晰的有示范性说服力的工具支持，这也许是OMG作为一个标准化组织，在面对微软这样一个直接面对市场的竞争对手时，所表现出来的先天弱势？
Good ways to find candidate DSLs are to identify the patterns used by developers, and then to encapsulate them into a modeling language, or to surface the concepts in a software framework as abstractions in a modeling language that can then generate small amounts of code that extend the framework. These techniques allow us to control the amount and complexity of generated code, offering real value to the developers, without the hassles that characterized CASE products.
点评：恩，DSL也罢，pattern也罢，都是重用的手段。
Microsoft recently announced the DSL Tools, which will enable customers and partners to build DSLs using the same technology in Visual Studio 2005 that we used to build the modeling tools that will ship with Visual Studio Team Edition for Software Architects. This technology, which can be thought of as "tools to build tools," simplifies the task of defining DSLs and reduces the effort and skills required to build graphical editors and compilers for them.
点评：微软的DSL工具真正好用吗？没用过，真该用用看如何 。
Many people who read our views on model-driven development assume that our emphasis on DSLs somehow has put us into an anti-UML position. We want to make it clear that this is not true. Before UML, there was an unproductive diversity of modeling approaches, and their convergence into UML 1.0 was a significant step forward in using models in software development.
But for whatever reasons, the existence of UML and UML-based tools has not significantly changed the way developers build applications. Nor has it significantly contributed to developer productivity. Since Microsoft ships one of the most-used UML tools—a Visio based tool that first shipped with Visual Studio Enterprise Architect - we anonymously survey developers (not just our customers) on tool usage. We have discovered that it's a very small population who claim to use UML tools in support of their tasks, and most usage clusters around class diagrams. When we drill into those who claim to use class diagrams, it's a tiny fraction that actually uses them to generate code.
This was one of the driving forces behind the model-driven development tools in Visual Studio Team Edition for Software Architects. We really wanted to take tasks that developers and architects find difficult, and figure out ways that modeling tools could add value and help them. We are enthusiastic supporters of UML notation and diagrams. A walk around the developers' offices in any corridor at Microsoft reveals whiteboards covered with UML class diagrams and sequence diagrams. We use UML notation in specification documents and in many other diagrams prepared for presentations and sketched on napkins in the cafeteria. To support the need for our customers to produce documentation and conceptual sketches we'll continue to ship the UML toolset with Visual Studio 2005. In fact, at Microsoft generally, we use UML for many purposes such as documentation or sharing of conceptual ideas, but almost never for any purpose where those documents are actual software development artifacts.
Those same whiteboards in offices and corridors are also covered with scrawled code. But again, these are sketches. They are rarely point-perfect compilable program source. That's a key difference for developers. Any artifact that contributes to actual software development must be capable of manipulation digitally. Source code has a well-defined syntax, a comprehensible semantics - often defined behaviorally by the compiler's transformation of it to lower level code or IL - and can be manipulated consistently by compilers, debuggers, and refactoring programs, to name but a few. To be useful to developers, a model must have the same status as source code. It too must have a precise syntax, a comprehensible semantics, and well-defined mappings to source code or other well-defined models. It must be more than just documentation.
点评：这不是Martin所说的UMLasSketch吗？本来MDA的目的也是要让UML（准确地说，不仅是UML，而是元模型）不仅成为开发中的文档。同样也是要增强UML的语义表达能力阿。
Take the Visual Studio Team Edition for Software Architects' Application Designer, for example. It's not just documentation, although it can serve that purpose. Rather it allows a developer (or architect) to focus on one aspect of her system; the connectivity between services in a service-based architecture. She can design this aspect of the system before building projects, WSDL files, code and schemas, or ask the tool to document connectivity between services if those artifacts already exist. Since connectivity information is scattered throughout many development artifacts, the holistic view such a diagram gives is fundamentally useful even though all the information it conveys could be deduced by careful scrutiny of the implementation artifacts. Application Designer has a well-defined syntax (its DSL metamodel), and predictable, always-synchronized mappings to the various implementation artifacts. The underlying designer framework plays the role of a compiler for Application Designer diagrams, much like the role played by a traditional compiler with respect to source code files.
But why couldn't we have just built this new "language" of service connectivity as an extension to UML—especially with the improvements made to UML 2.0?
Well, when we looked at the direction the UML 2.0 specification had taken, we realized that there were several reasons it still could not be the basis for anything more than documentation. The UML 2.0 specification has added complexity to the standard with yet more intertwined sublanguages, but it still does not address critical issues for modern application development, such as database design, testing, deployment, service orientation, component-based development, and user interface construction, in a natural way. Since no natural sublanguage of UML fits the requirements for service connectivity, we would have had to resort to describing our Application Design DSL using stereotypes and tags on an existing UML sub-language. This would have led to an overly complicated model within what has been described by many in the industry as an already bloated and complex specification. Using standard UML notation, in which an existing shape corresponding to whatever sublanguage we had extended is reused, would have compromised the readability and clarity of the diagrams. Lastly, we would have been dogged by the lack of precision in the specification in key areas, and the mismatch of type-systems inherent in UML compared to the .Net and XML languages.
点评：UML的这些缺点确实是有，这不奇怪阿。不过“软件工厂”能规避这些吗？
For these reasons, we elected to define the Application Design DSL using a purpose-built metamodel, itself defined as a member of a family of related metamodels. This gives us a natural and precise foundation for service connectivity, and a high-fidelity mapping to the underlying implementation artifacts which includes, of course, some amount of code. This is the same conclusion we have reached on other focused development tasks, and led to similar DSLs for the Class Designer and the Logical Data Center Designer described in other whitepapers. Support for extensible DSLs, built as a family, with well-defined mappings between them and other development artifacts has thus become the basis of Microsoft's model-driven development strategy.
To summarize, we would recommend using UML and UML-based tools for:
· Sketching.
· White boarding.
· Napkins.
· Documentation.
· Conceptual drawings that do not directly relate to code.
We would recommend precisely defined DSLs and DSL-based tools for:
· Precise abstractions from which code is generated.
· Precise abstractions that map to variation points in frameworks and components.
· Precise mappings between DSLs.
· Conceptual drawings that have precisely specifiable mappings to other DSLs or to code artifacts.
We would recommend neither of the above for visual programming of detailed program logic (or at least not for many years yet).
点评：UML当然可以作上面那些用途，但UML2.0和MDA面向的也包括下面这些用途。微软可以参与到OMG中去推动它，也可以另起炉灶。作为一个以盈利为第一目的的公司，微软选择后者是毫不奇怪的事情，我佩服的是，好家伙，绉出这么多唬人的“道道”出来，呵呵。
What About MDA?
MDA is a brand licensed to the OMG that is based on using UML for model-driven development. It places a strong emphasis on platform independent models and generative techniques. According to the OMG FAQ,
"MDA is a new way of writing specifications and developing applications, based on a platform-independent model (PIM). A complete MDA specification consists of a definitive platform independent base UML model, plus one or more platform-specific models (PSM) and interface definition sets, each describing how the base model is implemented on a different middleware platform. A complete MDA application consists of a definitive PIM, plus one or more PSMs and complete implementations, one for each platform that the application developer decides to support."
MDA, as defined by the OMG, addresses only a small subset of what we believe are the real issues that must be addressed to enable effective model-driven development. An effective model-driven development methodology must address pragmatic questions, such as:
· What types of systems can be developed? Since there are very real differences between different systems, a model-driven development methodology must recognize these differences. To be effective, it should start by describing the problem to be solved, and then identify specific technologies that can be used to solve it, showing where each technology fits in the solution, and how the various technologies work together to provide the solution.
· What is the architecture of a given type of system? The answer to this question deals not only with the technologies that can be used, but also with identifying the characteristics of those technologies that are important to the design of each part of the system, and with configuring each use of each technology. This is the subject of software architecture, which is widely recognized as one of the most important disciplines in the software life cycle. A software architecture defines the high-level design decisions that give a system its structure and that determine its quality attributes. Since models are primarily used to describe the architecturally significant parts of a system, they should be closely integrated with the development of the software architecture.
· What should be modeled for a given type of system? Since different systems can have very different architectures, no single set of models can describe all possible systems effectively. The answer to this question will therefore vary for different types of systems. In our opinion, a single PIM and a single PSM per target platform, all developed using a general purpose modeling language, as prescribed by MDA, are insufficient to support the significantly greater levels of automation promised by model-driven development. Rich automation of the software life cycle requires many additional types of models, such as models that:
点评：MDA中提供PIM建模的M2层元模型并不是a general purpose modeling language，它甚至是可以为一个项目所定义的，和DSL