|
||||||
|
|
|||||
|
Model Apps More Effectively
VSLive! San Francisco, March 24, 2004
Visual Studio Magazine's Editor in Chief Patrick Meader spoke with Microsoft's modeling maven Keith Short recently. Short spearheads Microsoft's effort to overcome the "curse of the CASE tools" and bring modeling tools into everyday use by mainstream developers working with Visual Studio .NET. Naturally, Meader was curious to know how Microsoft's product strategy differed from previous, largely unsuccessful efforts to popularize UML and other modeling tools. Enter Microsoft's new Visual Studio Distributed Architecture Designer technology, code-named "Whitehorse." Whitehorse will be included in the future Visual Studio .NET release code-named "Whidbey," whose second alpha version is being demonstrated at VSLive! this week. Patrick Meader: Microsoft is adding modeling capability to Visual Studio .NET. I can hear developers groaning already. What do you say when you see them rolling their eyes? Keith Short: I tell them that this tool will do for modeling what Visual Basic did for creating user interfaces (UIs), event-driven programs, and client/server applications. Before Visual Basic, only the most skillful developers—perhaps the top 10 percent—could create client/server applications. But with the advent of Visual Basic, suddenly nearly all developers could create such applications. Writing them evolved into how you implement your business rules, not how you draw your UI. We think these modeling tools will similarly broaden who uses modeling tools, as well as how often developers will use them—especially in the creation of service-oriented architectures (SOAs). Today, creating an SOA application means pooling a few top developers in your group. We believe Visual Studio Distributed Architecture Designer (code-named "Whitehorse") will change that. Will Whitehorse Convert Non-Modelers? Keith Short: People who tried to use CASE and modeling tools in the past often ran into significant problems. The most typical problem was that the model and the application quickly got out of synchronization. Even if developers used good products to synchronize the code and the diagrams, inevitably the effort required for developers to keep the model in sync with the code became overwhelming, so they abandoned these tools. We're looking at how developers actually work to ensure that the diagrams complement what they do, rather than simply provide a new document for developers to fill in before they start to code. Consider a classic UML-based class diagram. One of the problems is that UML in effect defines its own type system. Then you find yourself trying to match that type system to whatever type system you're using. You can always figure out how to do this, but you will also lose something in the process. This is what makes it so hard to keep diagrams and code in sync. It leads to developers abandoning the use of class diagrams, even though the diagrams provide a solid way to document what they're doing. We want to get around this problem by avoiding type mismatch while giving developers the ability to visualize what they're doing. They'll be able to see the structures inherent in the classes in a CLR program, whether it's Visual Basic .NET or C#. This will give developers all kinds of useful information. And yes, some developers might want to structure a program in advance by drawing boxes and lines that explain how the code should be structured, then use this diagram to produce the outlying classes so they can write the code into them. The elimination of type mismatch will keep the model and the code in sync in real time, without ever getting into the problems presented by the old CASE tool approach. Patrick Meader: You said Visual Studio Distributed Architecture Designer (Whitehorse) would change all this. Visual Studio Distributed Architecture Designer is Microsoft's new modeling tool? Keith Short: Whitehorse is the code name for a project including a designer-building technology and several model-driven designers, all part of the coming Visual Studio .NET release code-named "Whidbey." These designers will introduce the concept of model-driven development in Visual Studio .NET. Our goal with these designers is to simplify development through the use of diagrammatic, model-driven development tools on the .NET Framework. Patrick Meader: What will the Visual Studio Distributed Architecture Designer–based designers in Whidbey do? Keith Short: Whidbey will ship with a class designer, a distributed service designer, and a logical datacenter designer. The class designer shows you the structure of your CLR code, lets you auto-generate some code, and reflects code changes back in the model. The distributed service designer lets you take a snapshot of your applications and architecture, including any Web services you might employ. The logical datacenter designer lets you take a snapshot of your deployment environment. Together, these three designers give you tremendous control over and information about your project and its operating environment in an intuitive, visual way. The Web Services Connection Keith Short: The distributed service designer (which will get a new name at ship time, along with the other tools) will help you figure out how the application is structured when you build it from several Web services. This begins to address how people build SOAs. The boxes you see onscreen represent Web services, while the lines between them represent the messages the Web services can interchange with one another. Here we're tackling the need to make the diagram intrinsically related to the artifacts developers actually use. We want to get to the point where you can get some value from a diagram that shows the interrelationships between several Web services. Moreover, we want to ensure that our diagram complements what you do in the normal process of creating the solution. Today, you can derive such information from the solution without diagrams. However, doing things that way takes a lot of hard work. In contrast, you can see the relationships at a glance when you look at this automatically generated diagram. You can always keep the class designer in sync with the classes in a project. Similarly, you can always keep the distributed service designer in sync with the project structure in Visual Studio and the artifacts deposited in Visual Studio that represent the concept of a Web service. This helps both developers and architects, and we think we can avoid the synchronization pitfall of previous tools in this category. Patrick Meader: And the logical datacenter designer? Does that model your app to your physical datacenter architecture? Keith Short: The logical datacenter designer lets you take a snapshot of your deployment architecture. This lets the architect or network architect build a representation of the services offered by the datacenter, including what types of services exist, the types of software loaded onto these servers, and how those servers intercommunicate. The designer also tells you what virtual network segments exist in the datacenter. This model helps you understand the logical structure of your datacenter; you don't use it to describe the actual, physical servers. Developers need to know whether the existing system's infrastructure supports your app's requirements. Does the infrastructure meet the security requirements mandated by the app? You also want to know whether you've described the application well enough to know whether it will meet the constraints of what actually exists in the datacenter. Design for Operations Keith Short: As a developer, you'd like early confirmation that the way you're building your application will meet the constraints dictated by the datacenter. We call this process "design for operations." If I can make this information available at design time, developers can validate that their design will work before committing all their resources to it. That is a key part of what we're trying to do with the Visual Studio Distributed Architecture Designer technology in Visual Studio .NET's Whidbey release. Patrick Meader: Can you opt out of deploying these modeling tools? They won't be baked in so deeply you'll be required to use them? Keith Short: Correct. You can choose to develop exactly as you do now, without changing how you approach coding. Of course, we hope developers will choose to use them, because they'll add value to a project by providing a holistic view of the class structures, along with an architectural view of the Web services in the solution. Patrick Meader: What if I'm writing an app that my infrastructure doesn't support, but will support by the time I deploy? Can your tools handle this? Keith Short: Yes. For example, you might require a firewall that doesn't yet exist in your datacenter. You can continue with your system's design and implementation—you just wouldn't be able to validate it against your logical datacenter. However, the requirement would stand out as a requirement. In a real-life scenario, you'd negotiate this during design time, not at deployment time. The point is that we now have information on the app's architecture, the services the app subscribes to or utilizes, as well as the app's deployment environment. This is a powerful combination, and you can use these different snapshots and capabilities to tremendous effect. Read Part 2 of Patrick Meader's interview with Keith Short, in which Keith discusses the reasons Microsoft chose not to go with a UML-based approach, the issues of using Visual Studio Distributed Architecture Designer in heterogeneous environments, and more. About Keith Short |
