Infrastructure architects and the Logical Datacenter Designers in VSTS

The infrastructure architect's primary task is to model the network and datacenter onto which the application will be deployed.

Although not directly related to the software development effort, these models are critical to the success of an application because the application must be validated against these constraints to prove that it can be deployed to that environment. This concept is known as Design for Deployment.

Using Logical Datacenter Designers the architect will define the following:

• Type of servers (application Hosts: Web server, database server, and generic)
• Communication pathways between Hosts (server endpoints: HTTP, TDS, and generic)
• Type of communication boudaries (Zones: Intranet, VPN, DMZ, and Firwalls)
• Communication connection points (zone endpoints)
• Type of services enabled
• Configuration of application services
• Adding or removing setting resources to logical servers and endpoints

Adopted from Richard Hundhausen's book Working With Microsoft Visual Studio 2005 Team System.

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.

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.

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.

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.

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

Adpoted from Visual Studio 2005 Team System Modeling Strategy and FAQ.

DSL vs. UML

Microsoft would recommend using UML and UML-based tools for:

• Sketching.
• White boarding.
• Documentation.
• Conceptual drawings that do not directly relate to code.

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

Adpoted from Visual Studio 2005 Team System Modeling Strategy and FAQ.

Modeling Strategy in VSTS

VSTS's 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. This shifting has the following benefits:

• Developers write less conventional code since more powerful application abstractions can be employed. Model-driven development is thus inherently more productive and agile.
• 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.
• Communication between people can be optimized, and traceability enabled across the life cycle in any direction.

Microsoft adopts 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.
• A model represents a set of abstractions that support a developer in a well-defined aspect of development.
• Since models can abstract and aggregate information from a number of artifacts, they can more readily support consistency checks and other forms of 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.

Microsoft calls modeling languages defined in these ways Domain Specific Languages or DSLs.

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

Adpoted from Visual Studio 2005 Team System Modeling Strategy and FAQ.