Having spent some time looking at the important implementation features, we'll round off this chapter by returning to the core design features of Application Designer. We'll tie up a few loose ends by covering some of the additional capabilities that did not fit neatly into our running example.
One of the key features of the Distributed System Designers that distinguishes them from some precursor modeling tools such as Visio for Enterprise Architects and Rational Rose is its tight model and code synchronization. This ensures that any changes made in the code can be reflected in the design diagrams, and vice-versa, without any further code or model mitigation, thus breaking down the artificial barrier between design and coding. You'll look at this feature in more detail when considering Class Designer, but the principle can be demonstrated quickly here in the context of Application Designer.
Suppose you decide that the sellStock and buyStock methods provided by your dealing services are not sufficient because they return only the number of shares bought or sold. You'd now like those methods to return the price at which the shares were dealt and maybe the exact time that the deal was transacted. You could conceive two new classes—StockPurchase and StockSale—to encapsulate these details, and change the signatures of the two DealingService methods from
public int sellStock(string stockSymbol, int numberOfShares) public int buyStock(string stockSymbol, int numberOfShares)
public StockSale sellStock(string stockSymbol, int numberOfShares) public StockPurchase buyStock(string stockSymbol, int numberOfShares)
Make that change in code in the file DealingService.cs. Then click the MarketMaker's DealingService endpoint on the diagram to determine whether the changes are reflected immediately in the Web service Details window.
This chapter has focused on creating an application design from scratch, with the possible incorporation of some existing (external) Web services and databases. That is the approach you would usually take.
Of course, we all know that it doesn't always work like that. You may well encounter a system that has been implemented without a design, at least without a formal documented design based on Team Edition for Architects notations or UML. In addition, you may well be charged with documenting the design of that system after the fact. Furthermore, even for a so-called "new development," you might find that in fact this is a modification to an existing deployed system, in which case you will need a representation of the existing applications and services before you start.
To address these problems, Application Designer enables you to reverse engineer existing solutions as follows:
Add an application diagram to an existing solution, in which case application definitions will appear automatically on the diagram.
Add a suitable existing project or website to a Distributed System Solution—that is, a solution that has an application diagram.
Thanks to synchronization between the model, the code, and the other solution items, other changes you make will also be reflected in the application diagram, such as adding a web reference in the Solution Explorer, or adding a database connection entry in the configuration file.
By right-clicking any application in Application Designer and choosing Settings and Constraints, you launch the Settings and Constraints Editor. Do that now, or look ahead to Figure 2-12 to see what the Settings and Constraints Editor looks like.
We'll cover that in more detail in the next two chapters, where you'll learn how constraints in one layer are created against settings in another layer. For example, constraints can be set from the application layer (Application Designer, this chapter) against settings in the hosting layer (Logical Datacenter Designer, next chapter). The idea is that the infrastructure architect can constrain the application layer while allowing the application architect to request a set of features in the target deployment environment. Ultimately, the application design will be validated against the constraints and topology defined for the logical datacenter.
In Figure 2-12, we have launched the Settings and Constraints Editor for the StockBroker application, which by default is constrained to being hosted on an IIS Web Server. If that application is subsequently bound to a logical server (see Chapter 4) that does not have the appropriate IIS Web Server settings, then the constraint will not be satisfied, and a warning will occur on validation, indicating that the application cannot be successfully deployed to that server.
Furthermore, the settings and constraints information specified at the application level may be redefined or overridden in System Designer, prior to being evaluated for deployment; as you'll learn in Chapter 4.
You can print your application diagram by selecting the File Print menu option, which seems to work quite well. Be sure to check the page setup properties (by choosing File Page Setup) first, as by default these might be set to print your diagram across several pages.
The other obvious way to reproduce your diagram as hardcopy is to copy the shapes from the design surface and paste them into Microsoft Word. Just press Ctrl+A (select all) followed by Ctrl+C (copy) in Visual Studio, and then Ctrl+V (paste) in Word.
You can also use the right menu option, Copy Image, which will make the copy a vector image. This can be pasted into most graphics programs, Microsoft Word, and so on. This results in higher quality, as it can be rescaled and manipulated without loss of quality.
This enables you to include the diagram in a design document, and you could use the same technique to paste the diagram into Visio—as long as you bear in mind that all you would be pasting is a bitmap, not a Visio interpretation of the application details.
In Chapter 5, you will discover that Class Designer allows class diagrams to be exported as image files. Unfortunately, this feature is currently not supported by Application Designer.