Flylib.com

Books Software

 
 
 

Designers and VSTS


Designers and VSTS

This chapter has covered a simplified navigation designer concept that would enable users to model the navigation of an application or website. Abstracting from the end technology, it could be extended in any direction to allow for modeling of different semantics, such as auditing and logging.

In Part IV in this book, we describe how you can build your own custom Work Item types for use by Team System. The process you've already seen is fairly cumbersome in that you have to construct an XML document adhering to the supplied WIT schema.

This in itself is fine, but a Work Item type can become incredibly complex when you have to start modeling the workflow around State Transitions, which is very hard to visualize and understand when it's represented in an XML file format.

You could easily define a language model for Work Item types and construct a designer using the DSL Tools. The only code you would need to write would be code to translate the XML file format of Work Item types into the language model and back again.

This translation section would be very easy to implement; you could use XSD.EXE supplied with the .NET Framework to create a .NET object model from the Work Item Schema, load the XML into this object model, and iterate through all of the concepts, constructing the equivalent language model elements allowing the user to visualize the Work Item structure in the designer. Saving changes would be the same process but in reverse.

Apart from the translation code, you won't have to write any other code, which is very compelling when you consider how much code you would have to write yourself! A screenshot of a prototype WIT designer that one of the authors has developed is shown in Figure 6-19. States are represented by the boxes on the diagrams. Fields in the domain model are not represented as boxes but as dynamic toolbox items, and transitions between states are represented by the lines between states.

image from book
Figure 6-19



Summary

In this chapter, we discussed the background to the DSL Tools and discussed some scenarios whereby a graphical designer could be used to simplify software development and provide a technology abstraction. We detailed the background to our sample Navigation Designer and walked through creating the navigation language and its associated graphical language, resulting in a fully fledged designer integrated with Visual Studio 2005.

With this sample designer, we then detailed how you might use the resulting domain model and demonstrated some code that created a working ASP.NET project from the domain model.

In the next chapter, we cover the Microsoft Dynamic Systems Initiative (DSI) and the System Definition Model (SDM). The SDM Visual Designers in Visual Studio 2005 are built using a domain-specific language.



Chapter 7: Dynamic Systems Initiative and the System Definition Model

Overview

In this chapter, we will show how the Distributed System Designers in Visual Studio Team Edition for Software Architects are the first deliverable of the Dynamic Systems Initiative that are aimed at improving the design and validation of distributed systems. We will also describe the System Definition Model architecture and how it can be used to capture distributed system knowledge. We will conclude this chapter by creating a Windows Mobile Device component, described in SDM, that can be plugged into and extend the Application Design surface.

Industries worldwide are investing in simulation technology. Chip, automobile, and aerospace manufacturers, government agencies, and financial firms are increasingly relying on models to simulate real-world behaviors of their products and services. The payoff is to cheaply predict or uncover design flaws or operational errors in the product or service before they're laboriously produced, tested , and deployed into the real world.

With the industry aimed toward simulating increasingly complex systems, advances in hardware are being pursued at a breakneck pace. Today's supercomputers exercise models at teraflop speeds to simulate rapid crash tests of fenders. In five years , the computing industry hopes to build a supercomputer running at petaflop speeds capable of simulating the impact of the entire car system.

Advances in software tools give users enhanced capability to capture models of complex systems and exercise them within virtual computer environments. For instance, specialized software tools help to create clinical models that enable medical students to virtually visualize and even feel patient procedures.

Yet, for all this virtual computerization, businesses are ill prepared to effectively preempt problems within their own increasingly complex and costly information technology (IT) infrastructure. They are unable to use software to readily understand the often significant effects a change in one part of their system can have on their overall environment.

The rate and intricacies of new business application requirements are swelling. The interdependencies between heterogeneous software and hardware are rising ; and as these interdependencies increase, so does the complexity that spans the entire IT life cycle from designing, developing, and deploying to managing and operating these distributed systems.

While developing these new distributed systems is requiring increasing amounts of effort, time-to-market pressures have never been higher. Increased system complexity drives cross-team coordination to new limits. Deploying new systems often requires buying new hardware, and demands numerous development iterations to optimize the system. Once out the door, the manual nature of operations means that some customers spend as much as 75 percent of their IT budget on system maintenance.

In such an environment, the ability to predict failure is daunting — and failure to predict is costly.

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

So that's the problem we face — but how to solve it? Well, modeling helps, but modeling by itself is insufficient.

The modeling challenge for IT today is not simply to represent the structure and architecture of each system in a distributed environment or to additionally describe the behavior and processes of these systems. Nor is it to bring more computing power to bear on the models and processes already in place. The challenge is to provide a holistic modeling experience that can persist beyond design, where models share a common definition of IT knowledge and behavior so that they can communicate among themselves , especially within heterogeneous IT environments.

This kind of modeling support is unlikely to come from modeling tools that have little capability to model knowledge and communicate with a system in generic ways. Nor is it likely to come from tools that provide generalized solutions to designing but treat the deployment and operation of these complex distributed systems as an afterthought.

Rather, a new systemic approach is needed, a technology able to shift operational intelligence into the design of the application itself. The Dynamic Systems Initiative, and in particular Systems Definition Modeling, provides that direction. The Dynamic Systems Initiative (DSI) is an effort by Microsoft to deliver, over time, a coordinated set of solutions that dramatically simplify and automate how businesses design, deploy, and operate these distributed systems. At the heart of the DSI is a modeling language called the Systems Definition Model (SDM). SDM is used to create models of distributed systems, which it does by defining system building blocks capable of accurately capturing descriptions and behaviors pertinent to the system's development, deployment, and operation. With SDM, administrators, system integrators, and vendors can create a living blueprint of an entire system, which can be dynamically maintained at any point in the system's life cycle.

This chapter introduces you to the Systems Definition Model (SDM) architecture and describes the runtime environment that allows for modest simulation scenarios, such as validating at design time whether an application can be deployed to a target environment. We then investigate the SDM object model and schema used to author a systems structure and behavior. Lastly, this chapter provides a nontrivial example of Team Architect extensibility using the SDM SDK.

This chapter is developer focused and will not focus on DSI areas such as driving toward more operationally aware Windows platform with virtualization, management technologies and tools, automated deployment, configuration, and monitoring.

It is assumed that the reader has a basic understanding of the XML Schema Definition ( .xsd ) format.