|
||||||
|
|
|||||
|
 |
 |
Back to VSLive! San Francisco Show Daily Home
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. |
|
|
|||||||||||||||||||
