Visual Studio 2005 Team System Modeling Strategy and FAQ

Article
02/03/2012

Microsoft Corporation

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)

Why Modeling?
How Are DSLs Used in Model-Driven Development?
What About UML?
What About MDA?
What Are Software Factories?
Other Frequently Asked Questions

Why Modeling?

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.

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.

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.

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.

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.

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.

What About UML?

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.

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.

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.
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).

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:
- Capture, analyze, and manage requirements; identifying trace relationships between requirements, architectural design and implementation constructs, enabling validation that requirements have been implemented, and supporting impact analysis when requirements change.
- Define software architecture in a way that supports security, performance and reliability analysis, and other forms of evaluation; and in a way that enables predictable assembly of systems from components, and efficient and reversible step-by-step transformations from requirements and deployment,
- Define how the executable components of a system are packaged, identifying the types of resources in the deployment environment required by each component, and binding the components to specific instances of those resource types,
- Define test cases, test data sets, test harnesses, and other artifacts, making it easier to evaluate the quality of software developed using models, and to manage and display the test results
- Identify traceability relationships between models and other artifacts, making it easier to support business impact analysis when systems go down, configure systems to satisfy requirements, and enforce constraints during system configuration,
- Define configurations of source artifacts used to build executables, making it easier to version those configurations, and to associate defect reports and feature change requests with specific versions.
How should model-driven techniques be integrated with code-focused development techniques? Models should be used to assist developers with implementation tasks, such as querying and navigating the code base, debugging, profiling, coverage analysis, pattern application and refactoring, and should be tightly integrated into file-oriented development environments.

Also, for reasons stated above, the emphasis on using the published UML metamodel is problematic for us. Lastly, while the emphasis on platform independence is a concern for some customers, we hear more about their need for productivity, predictability, security, governance, and effective ways to deploy and manage applications. We do, however, agree with the focus in MDA on the use of models to build applications, and on the importance of well-defined mappings between models, and we recognize the value that models can provide for building applications that span heterogeneous platforms with interoperating components.

Some organizations pursuing model-driven development accept a wider interpretation of the term MDA than the interpretation prescribed by the OMG; indeed, as we've described, they must do so in order to succeed. The use of any of the OMG's specifications to drive model-driven development is typically marketed as MDA, whether or not it involves PIMs and PSMs. Some organizations, for example, see the OMG's MOF specification as key to MDA. This view relies on new modeling languages defined using MOF, not the modeling languages that are predefined in UML, and is effectively similar to our approach. We will support interchange with popular UML and MOF tools on other platforms, either via XMI or native formats, to help customers who are using them succeed with model-driven development.

What Are Software Factories?

As we said above, our approach to model–driven development is part of an initiative at Microsoft called Software Factories. Instead of taking a generic, one-size-fits-all approach, Software Factories use custom collections of DSLs to provide sets of abstractions customized to meet the needs of specific families of systems like ecommerce, financial arbitrage, or home banking applications. With Software Factories, models are used not only for analysis and design, but to support many varied types of computation across the entire software life cycle—even at run time. This is a fundamental principle of Software Factories, and also of Microsoft's Dynamic Systems Initiative (DSI), which implements and complements the Software Factories Initiative.

You might think of Software Factories as encompassing and extending MDA, where MDA is defined in a broader sense than the official definition based on PIMs and PSMs. Software Factories go beyond generic platform independent and specific models to address the additional issues described in the preceding section.

A Software Factory defines a tailored methodology for a specific family of systems using a graph of viewpoints. Each viewpoint defines some aspect of the life cycle for members of the system family, such as requirements capture, database design, or service contract definition. The factory associates reusable assets with each viewpoint, and delivers them in the context of that viewpoint to the team's development members of the system family, eliminating the need to search for applicable assets, enabling validation, and supporting manual and automatic guidance enactment.

The graph of viewpoints, called a software factory schema, relates work done at one level of abstraction, in one part of the system, or in one phase of the life cycle, to work done at other levels, or in other parts and phases. It can be used to fully or partially generate artifacts, including models, source code, configuration files, and so on; from other artifacts, especially from models; to keep artifacts synchronized during development; to validate hand developed artifacts; to assess the impact of defects or changes in requirements; to organize and apply patterns and other best practices; to capture metadata during system development to support system operation and maintenance; and to provide other forms of guidance and governance.

Software Factories automate the packaging and delivery of the reusable assets, including models and model-driven tools, other types of tools, such as wizards, templates and utilities, development processes, implementation components, such as class libraries, frameworks and services, and content assets, such as patterns, style sheets, help files, configuration files, and documentation. Since the software factory schema is a model, factories can be manipulated using tools. Larger factories can be created by combining smaller ones and specialized factories by customizing generic ones.

Building a factory is a lot like building a framework. It involves harvesting and implementing patterns and other best practices to make them easy for developers to apply. Using a factory is more efficient than building systems by hand from scratch because instead of scanning through catalogs and repositories, hoping to find reusable components, developers using a factory have reusable components appropriate for each aspect of the system under development immediately available in the context of the system architecture and development process.

Of course, the Software Factories Initiative is not just about Microsoft and the products we provide. Instead, we see factories as the basis of a broad ecosystem in which our customers and partners participate, building custom factories on top of foundations we supply, and supplying factory components to other members of the ecosystem.

Customer and partner reaction to the Software Factories Initiative is very positive. We recommend Software Factories as the best direction for modern organizations wishing to improve their development approach inline with business expectations, and we are delivering Visual Studio Team Edition for Software Architects, the DSL Tools, and other new features in VSTS as initial products in the Software Factories Initiative.

For more information, see Software Factories Workbench.

Other Frequently Asked Questions

General

What support for model-driven development is provided in Visual Studio 2005?

Visual Studio 2005 contains a powerful new modeling framework which powers the Visual Studio 2005 Class Designer and the Distributed System Designers in Visual Studio 2005 Team System. Over time, we will expose the underlying modeling platform to end-users to enable others to create rich model-driven development tools. Microsoft's DSL Tools are a first step towards this goal.

The Visual Studio 2005 Class Designer is a developer productivity enhancement which lets you visualize the structure of classes and their relationships, create new classes using a visual design environment, and easily refactor classes. Class Designer treats .NET-specific constructs such as partial classes and generics as first-class citizens, enabling you to model .NET applications with high-fidelity. By remaining in continuous sync with the code, Class Designer provides the developer with a visual representation of his/her code at all times. For more information, see Visual Studio 2005 Class Designer.

Visual Studio 2005 Team Edition for Software Architects includes the Distributed System Designers which target the design of service-oriented applications, specifically those relying on ASMX-based Web services.

The Distributed System Designers consist of four designers:

Application Designer—allows developers and architects to define applications that will be configured into systems for deployment.
Logical Datacenter Designer—used to create diagrams of interconnected hosts that represent the logical structure of a datacenter for the purpose of communicating important information to the developer about the target deployment environment.
System Designer—used to compose applications into systems.
Deployment Designer—used to bind applications within a system to logical servers (application hosts) modeled in the Logical Datacenter Designer.

Application architects can visualize their service-oriented applications and developers can work with the generated code while keeping the code changes synchronized with the visual design. Infrastructure architects can create logical abstractions of their datacenter and validate it against the constraints of the application/datacenter designed by the application architect prior to actual deployment. Reports generated from this validation help to document the deployment mapping.

For customers requiring traditional Object-Oriented Analysis and Design (OOA&D) tools, we continue to provide support for Visio for Enterprise Architects as part of Visual Studio 2005 Team System. Visio for Enterprise Architects provides a complete drawing, diagramming, code-generation, and reverse-engineering solution for those customers desiring traditional UML modeling tools. A number of third-party providers will also deliver UML tools integrated into Visual Studio 2005.

What functionality is provided by Visio for Enterprise Architects?

Using Microsoft Visio for Enterprise Architects, users can create and communicate application architecture, business requirements, database design, and business processes. Architects using Microsoft Visual C++ .NET, Microsoft Visual Basic .NET, or Microsoft Visual C# .NET can use Unified Modeling Language (UML) 1.3 models to specify application architecture and functionality, reduce development time by directly generating classes, functions, and methods, and document existing application code by reverse-engineering projects. Visio for Enterprise Architects enables developers to create architectural designs and models that they can share with the rest of their team.

Visio for Enterprise Architects provides end-to-end support for database modeling, including conceptual, logical, and physical views. Business analysts can easily enter business rules using the Fact Editor, which in turn generates an underlying database model that can be refined by a database analyst. Roundtrip engineering guarantees that changes made at any of the views will be reflected throughout, improving communication across the development team.

What version of UML does Visual Studio Team System support?

Visio for Enterprise Architects supports the UML 1.3 language specification.

Does Microsoft continue to believe in the value of UML modeling tools? If so, why isn't Microsoft supporting UML 2.0?

Yes, absolutely. We believe that UML continues to have its place in the early stages of the software development life cycle and we are continuing to support a number of partners who will deliver UML 2.0 tools for Visual Studio 2005. Our own domain-specific designers will also support UML notational conventions where they make sense.

From Microsoft, you will see a number of new designers that treat models as first-class citizens and that can be used to truly drive development, not just to create documentation. The Distributed System Designers in Visual Studio 2005 Team Edition for Software Architects are the first example of this type of tool.

Is Microsoft trying to ignore the UML standard and lock customers into their own modeling language?

No. The UML standard is a weak one, and for this reason, most UML tools are unable to seamlessly interoperate. While we recognize the value of UML for documentation and for understanding software design, domain specific languages will enable you to work at higher levels of abstraction, and to focus with precision on issues relevant to specific domains.

Over time, Microsoft will provide additional domain-specific modeling tools, and we will continue to work with our partners to bring UML tools to Visual Studio 2005 that are built on top of our modeling framework.

Can I import my existing UML diagrams into Visual Studio Team System?

Most of the popular UML-based class design tools use idiosyncratic variants of XMI to export and import information that reflect their implementations of the UML standards. We are not committing to producing a custom XMI import/export tool for every one of these tools. It is possible to logically "import" existing UML class diagrams by first generating code from the diagrams and viewing that code via Class Designer.

Does Visual Studio Team System support behavioral modeling and Use Case diagrams?

Yes, behavioral modeling and Use Case diagrams with code generation and reverse engineering are supported via Visio for Enterprise Architects, which is included with Visual Studio Team System. Visual Studio Team Edition for Software Architects, however, does not natively support these diagram types. Custom diagram types can also be created on top of the powerful Visual Studio 2005 modeling framework using the recently released Microsoft Tools for Domain Specific Languages.

Microsoft Tools for Domain Specific Languages

What are domain-specific languages?

A domain-specific language (DSL) is a language designed to be useful for a specific task in a fixed problem domain, in contrast to a general-purpose language. DSLs are gaining popularity in the field of software engineering to enhance productivity, maintainability, and reusability of software artifacts, and enable expression and validation of concepts at the level of abstraction of the problem domain.

Using domain-specific languages, one can build customized modeling tools and essentially define a new modeling language and implement it very simply. For example, a specialized language may be used to describe a user interface, a business process, a database, or the flow of information, and then used to generate code from those descriptions.

Visual Studio 2005 Team Edition for Software Architects includes several high-quality visual designers, based on domain-specific languages, for the design of distributed systems and the validation of those systems with a logical datacenter.

What are Microsoft's Tools for Domain Specific Languages?

Microsoft's Tools for Domain Specific Languages allow you to describe the concepts relevant to a specific problem domain and serve as the basis for creating custom visual designers in Visual Studio 2005. They allow you to build your own custom designers on top of the same infrastructure that powers the Visual Studio Team System Distributed System Designers (Visual Studio 2005 Team System: Designing Distributed Systems for Deployment) and Class Designer (Visual Studio 2005 Class Designer), and are central to eventually realizing the vision of Software Factories. These tools and a corresponding walkthroughs can be found in the DSL Tools workbench in the Visual Studio Team System workshop.

Which Visual Studio products will support Microsoft's DSL tools?

DSL authoring will be supported in Visual Studio Professional Edition and above. DSL consumption will be supported in Visual Studio Standard Edition and above.

What types of designers can be built using the recently released DSL tools?

The DSL tools can be used for constructing custom visual designers tailored to any problem domain. For example, one can create a business process modeling tool using the DSL tools to describe the concepts specific to the way your organization models business processes. If you are building a statechart tool, you can describe what a state is, the properties a state has, what kinds of states exist, how transitions between states are defined, etc. Of course, the notion of a statechart used to describe the status of contracts in an insurance company and the notion of a statechart used to describe user interaction amongst pages on a Website are similar in concept, but may have very different implementations. By creating a custom designer, you can specify exactly the definition of statechart concepts you need in your tool.

Does Microsoft have industry support behind domain specific languages and Software Factories?

In addition to broad support within the academic community, and with many customers and partners, Microsoft has the support of the following companies:

Borland, designers for UML 2.0.
Unisys, Software Factories for a variety of industries.
Siemens, Software Factories for medical imaging device software.
Kinzan, domain specific tools for Web development.
Nationwide, domain specific tools for the financial industry.

Class Designer and Visio

What is Visual Studio Class Designer?

Which versions of Visual Studio will contain the new Class Designer?

Visual Studio 2005 Standard Edition and above will contain Class Designer.

What languages does Class Designer support?

Class Designer supports C#, VB.NET, and J#. Class Designer in Visual Studio 2005 does not support C++, but is a top priority for the next release of Visual Studio.

How does Class Designer differ from Visio?

Visual Studio Class Designer lets you visualize the structure of classes and their relationships, create new classes using a visual design environment, and easily refactor classes. Changes made to the class diagram are immediately reflected in code, and changes made to the code immediately affect the appearance of the designer. This synchronous relationship between designer and code makes it easy to create and configure complex CLR types visually. Class Designer is useful for understanding existing code, class design, refactoring code, and creating documentation. Class Designer is integrated seamlessly with Visual Studio 2005 (Visual Studio Standard Edition and above) and is tailored to accommodate the .NET Framework and the CLR.

Can I import existing Visio, Rational Rose, or Rational XDE diagrams into the new Class Designer?

Yes, you can logically "import" existing UML class diagrams by first generating code from the diagrams and viewing that code via Class Designer.

Does Class Designer support XMI import/export?

No, Class Designer does not support XMI import/export. Users can generate code from their existing models and then use Class Designer to visualize this code. Since the popular UML-based class design tools use idiosyncratic variants of XMI to support their implementations, we are not committing to producing a custom XMI to Class Designer import/export tool for every third-party product.

Does Visio support XMI import/export?

Visio currently supports XMI export via a standalone, separate download. For more information, see Visio 2003 UML To XMI Export.

What is the future direction of Visio? How does Visio and Class Designer fit into the bigger picture of Software Factories?

Visio for Enterprise Architects is provided as part of Visual Studio 2005 to provide backwards compatibility with customers' existing Visio investments, and Visio functionality will continue to be supported. The new Class Designer, however, enjoys seamless integration with Visual Studio 2005 and has been specially designed to accommodate the .NET Framework and the CLR. Visual Studio Class Designer lets you visualize the structure of classes and their relationships, create new classes using a visual design environment, and easily refactor classes. Changes made to the class diagram are immediately reflected in code, and changes made to the code immediately affect the appearance of the designer. This synchronous relationship between designer and code makes it easy to create and configure complex CLR types visually. Class Designer is useful for understanding existing code, class design, refactoring code, and creating documentation. The new domain-specific language tools as part of the Visual Studio 2005 SDK allow customers and partners to build custom designers tailored to their problem domain. For example, Borland has announced plans to build a full suite of UML 2.0 designers on top of this framework. This is the same framework upon which Class Designer and the Distributed System Designers are built.

Software Factories

What are Software Factories?

Software Factories consist of specialized tools, processes, and other assets, such as patterns, architectures, frameworks, templates, requirements, test cases, and deployment topologies; that encapsulate the business and technical knowledge of specific problem domains. For example, a Software Factory for the health care industry might consist of tailored modeling tools for designing health care solutions, process guidance that explains and guides developers through the unique aspects of the health care industry, and architectural frameworks that provide common base classes for health care solutions. Such a Software Factory will automate the rote and menial tasks a developer must perform in order to build health care solutions, freeing them to apply their creativity and experience to finish the project.

Will Software Factories industrialize software development and eliminate the need for skilled programmers?

Contrary to 19th-century connotations of the term "factory," Software Factories are not in any way, shape, or form intended to turn developers into menial laborers. Software Factories will instead make developers more productive, by automating rote and menial tasks, and by helping them work at higher levels of abstraction. We had more recent connotations of the term "factory" in mind when we coined the term, especially the use of robots that automate manual labor. Programmable tools supplied by factories will enable developers to spend more time thinking about how to solve problems, and less time doing all the housekeeping work required to create, build, and deploy their solutions.

What was announced at OOPSLA 2004?

At OOPSLA 2004, we announced:

An extensibility model for building custom visual design tools for Visual Studio 2005 Team System for specific problem domains.
Immediate availability of a Community Technology Preview of a tool for building custom visual design tools in Visual Studio 2005 Team System.
Broad partner and industry support for extending the visual design tools in Visual Studio 2005 Team System through domain specific modeling environments, as described above.

Where can I get more information about Software Factories?