2-3 is a State diagram that was created with Microsoft Office Visio 2007. This section is a tutorial for creating a portion of that State diagram and a general overview of Microsoft Office Visio 2007. For a comprehensive book on Microsoft Office Visio 2007, I would recommend Microsoft Office Visio 2007 Inside Out, authored by Mark Walker and published by Microsoft Press.

Creating a UML diagram begins with selecting the appropriate template in Microsoft Office Visio 2007. Start Microsoft Office Visio 2007. From the menu, choose File, and then choose New. From the New submenu, select Software and Database. A list of diagrams should appear on the drop-down menu. Choose UML Model Diagram (Metric) or UML Model Diagram (US Units) from this list, depending on your preference. After selecting the template, an empty environment, including a new Visio document, is presented. Conversely, an existing document can be opened from the menu with File and then Open or simply by selecting the relevant document from the most recently used (MRU) list.

The Microsoft Office Visio 2007 environment includes a Visio document, Shapes pane, Model Explorer, default toolbars, and menu. 2-6 shows the standard environment for a UML diagram.

Figure 2-6. Visio environment for a new template.

The UML Model Diagram stencil, as expected, has several stencils for creating an assortment of UML diagrams:

You can drag shapes from a stencil onto the Visio document. The drawing document is similar to most graphics windows, where graphical elements can be selected (handles will appear), dragged, resized, deleted, edited, and so on. Some shapes can be connected to other shapes. For example, an Interface shape can be connected to a Class shape. Both of these shapes are found in the UML Static Structure stencil. When connecting, the intersection of the two shapes is highlighted. This is the same behavior observed when connecting any two shapes.

The Model Explorer contains all of the models for a software system, which could include several diagrams. It is organized into models and packages that provide a hierarchal structure to the Model Explorer. Each model represents a model of a software system, while packages offer different views of a software system. 2-7 shows the default Model Explorer of Microsoft Office Visio 2007. The Static Model is the root folder for any new UML Model diagram. You can customize this folder as desired. Each model has one top package, appropriately called Top Package, which is the root package for the model. There is only one root package in the model—all other packages are organized within this package. Packages can contain other packages. In addition, a package can contain diagrams. Collectively, the diagrams in a package represent a particular view of a model.

Figure 2-7. Model Explorer of the Visio environment.

Here are steps to create the correct model and related packages for the retail banking system. The top model will be renamed YourName Bank to represent your banking company. We will create a package called Retail Banking for branch banking. There will be a second package called Private Banking to model a software system for high–net worth clients.

Here are the steps to create a Class diagram:

Attributes, operations, constraints, and other information pertaining to the class can be defined in the Properties window. Information is grouped in categories. For example, the Operations category allows the adding, removing, and moving of class methods. You can switch between categories of information in the Categories list box. The Employee class has four attributes and no operations.

Here are the steps to add attributes to the Employee class.

The Manager and Teller classes inherit the Employee class. As such, we do not have to replicate in the child classes the attributes inherited from the Employee base class. The Employee class has no methods to be inherited. Child classes refine the base class and therefore become specialty classes. As such, both the Manager and Teller classes add members that make them specialty classes. In the Class shape for child classes, only the unique attributes and operations should be added.

Here are the steps to add the Manager and Teller class shapes to the class diagram.

Classes can be related through inheritance, association, or composition. There is a shape for each of these relations in the UML Static Structure stencil. Inheritance is defined with the Generalization shape. If a base class is inherited by more than child class, use multiple Generalization shapes. You can create an association between two classes with the Binary Association shape. For composition, use the composition shape. Multiplicity defines the numeric relation between the two classes (class¹ and class²) that comprise a composition. For example, a multiplicity of 1 to 1 means that there is exactly one class¹ for each class² in the binary association. An example of a 1 to 1 relationship would be a bank and bank president. The bank, which exists, has one—and only one—bank president. Another type of multiplicity is 1..n to *. This means that there is at least one class¹, where for any class¹ there is any number of class². An example of 1..n to * would be bank branch and customers. There is at least one bank branch. Each bank branch could have any number of customers.

As mentioned previously, both Manager and Teller classes inherit the Employee class. In addition, the relationship between Manager to Teller is 1 to 1..*. Each bank manager can manage one or more tellers. Here are the steps to define the relationships among the Manager, Teller, and Employee classes.

Retail banking customers have either a checking or savings account. The checking and savings accounts are related. They are both "is a" kind of bank accounts. In object-oriented programming, "is a" implies inheritance. In this circumstance, Account is a base class and holds the common members of the Checking and Savings classes. Both the Checking and Savings classes then inherit from the Account base class. For the purpose of this example, only the Account class is defined. Customers must have an Account class.

Here are the steps to create the Account and Customer classes.

Tellers handle a single customer at a time, if any. This is a 1 to 0..1 relationship, where a teller can have zero or one customers. In addition, customers can have one or more accounts, such as checking and savings accounts. This implies composition between the Customer and Account classes and a 1 to 1..* relationship.

The Teller, Customer, and Account classes were created in the previous steps. Here are the steps to define the relationship among the Teller, Customer, and Account classes.

Most of the class diagram, as shown previously in 2-3, has been completed. For practice, you might consider finishing the diagram. Once the modeling is completed, what is the next step? You might say, "at long last, coding!" Not actually. Before coding, there is one more step: prototyping.

In .NET, instrumentation can be orchestrated using tracing. The Trace and TraceSource classes offer considerable flexibility for this purpose. We have come a long way since the printf command. If you are not familiar with printf, you are probably under 30 and do not own a C++ book.

Simple tracing is available with the Trace class. Most of the methods of the Trace class are implemented as static methods, which are called on the class. Alternatively, you can use the TraceSource class. The TraceSource class has additional functionality for advanced tracing, such as additional tracing levels and filtering. The Trace and TraceSource classes are discussed fully in Chapter 9. This chapter presents only enough information on tracing to demonstrate prototyping. The TraceSource class, not the Trace class, is used in this chapter. It is preferred because of added flexibility.

Both the Trace and TraceSource classes allow remote activation of tracing using a configuration file. You do not have to modify and rebuild the application to change the status of instrumentation. This avoids introducing inadvertently bugs just to enable or disable instrumentation. This also allows nondevelopers, such as architects and testers, to control instrumentation. This is particularly important because individuals in this role may not even have access to a compiler.

There are three levels of configuration files: application, public policy, and machine configuration file. In this chapter, we focus on the application configuration file. An application configuration file will allow you to control instrumentation of a specific application. Application configuration files are placed in the same directory of the assembly. The file name of the configuration file is name.extension.config. For example, myapp.exe.config is the configuration file for myapp.exe. This is discussed more broadly in Chapter 3.

Here is a sample configuration file that controls tracing.

<configuration>
  <system.diagnostics>
    <sources>
      <source name="myTraceSource"
        switchName="mySwitch">
        <listeners>
          <add name="console"
            type="System.Diagnostics.ConsoleTraceListener">
          </add>
           <remove name="Default"/>
        </listeners>
      </source>
    </sources>
    <switches>
     <add name="mySwitch" value="error"/>
   </switches>
 </system.diagnostics>
</configuration>

Tracing is defined within the system.diagnostics element. The name of a particular trace source is identified in the source element. The source name is used in application code to identify the corresponding trace source, which is provided in the constructor of the TraceSource class. Listeners are the target of tracing and defined within the listeners elements. Each listener is added with an Add element. You can have multiple simultaneous listeners, such as the console, file, eventlog, and so on. The Switches element contains the available switches, which are used to filter message sent to the listeners. Individual switches are added with an Add element. The value attribute of the Add element identifies the type of switch.

Here is sample code that uses the preceding configuration file.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Diagnostics;
namespace ConsoleApplication {
    class Program {
        private static TraceSource mySource =
            new TraceSource("myTraceSource");

        static void Main(string[] args){
            Activity1();
            mySource.Close();
            return;
        }
        static void Activity1(){
            mySource.TraceEvent(TraceEventType.Error, 1,
                "Error message.");
            mySource.TraceEvent(TraceEventType.Warning, 2,
                "Warning message.");
        }
    }
}

In the code, an instance of a TraceSource class is created. In the constructor, we associate this trace source with the one in the configuration file (i.e., myTraceSource). The new trace source will then inherit the settings from the configuration file, such as displaying to the console window as a listener. The two TraceSource.TraceEvent commands trace to this listener. The ultimate status of the messages is controlled by the trace switch settings in the configuration file. An error and warning messages are sent. However, only the error message is displayed. The warning message is filtered per the switch in the configuration file. Change the value of the switch in the configuration file from error to warning. Now both the warning and error messages are displayed. This change can be made without having to recompile the application, which is one of the benefits of using the TraceSource class and configuration file.

A picture is worth a thousand words. For the Visual Studio Class Designer, instead of words, we are referring to lines of code. The Class Designer is a depiction of a UML class diagram. You can quickly and easily convey some of the concepts of a class diagram, such as class relationships and membership. Complex concepts, such as composition, can be easily rendered in a visual chart. Like a UML diagram, the primary components of the Class Designer are classifiers, such as classes, structures, interfaces, delegates, and enums. You can forward engineer from the Class Designer and convert classifiers from visual representations into code. You can also reverse engineer from code to a Visual Studio class diagram. A class diagram is a Class Designer document.

The Class Designer is excellent for rapid prototyping. There are convenient steps for creating stubs for methods and properties. Beyond creating stubs, the class diagram is automatically synchronized to the project code. Changes to the class diagram are instantly reflected in the code and vice versa. Add a method to a class in the class diagram, and simultaneously a method is added to the same class in the project. Delete an attribute from an interface in the source code, and the associated attribute is removed from the related interface in the class diagram. This synchronization highlights one of the other benefits of the Class Designer, which is refactoring. You can visually and easily refactor an application, including renaming variables, changing accessibility, changing attribute type, updating function prototypes, and more.

After prototyping the software system using the Visual Studio Class Designer, you can easily instrument the resulting code. You can even create a snippet that will automatically insert the appropriate tracing commands for each operation.

There are three important components to the Visual Studio Class Designer: the class diagram, Class Designer toolbox, and Class Details window. As mentioned earlier, a class diagram is an instance of a Class Designer document. The Class Designer toolbox contains shapes that are used to complete the class diagram. Finally, the Class Details window allows you to add, view, and edit members of classes, structs, and interfaces. 2-10 shows the Class Designer environment.

Figure 2-10. The Class Designer, which includes the class diagram, toolbox, and Class Details window.

There are several ways to add a class diagram to a Visual Studio project:

You can then build the class diagram using drag and drop from the Class Designer toolbox. Drag shapes from the Class Designer toolbox onto the class diagram document. The toolbox includes all the requisite classifiers: class, struct, interface, enum, and delegate.

When you drop a classifier shape on the class diagram, the New dialog box will be presented. In the New dialog box, name the classifier, accessibility, and the file to place the entity. The shape is then added to the class diagram.

After adding a shape, you might also want to edit a particular shape. To modify a shape on the class diagram, first select the shape. A selected shape is highlighted with handles. Edit the shape from the Class Diagram menu. You can also use the context menu to add a member or edit the shape in some other manner. For example, to add a method to a class shape from the Class Diagram menu, select Add and then Method. You can then name the new method. In the Class Details window, define the prototype of the method by entering the return type and parameters. Expand the method row for the class in the Class Details window to view or add parameters. You can also add methods, properties, and attributes directly in the Class Details window instead of using the menu system.

Prototyping with the Class Designer is easy. Why? It is automatic. Add an operation to a class or struct and the stub is automatically created. You can then instrument the operation with an Enter and Exit message. Even the Enter and Exit methods can be automated in Visual Studio using code snippets. Code snippets are reusable snippets of code. Snippets can be parameterized to allow customization whenever the snippet is used. This adds considerable flexibility.

<CodeSnippet Format="1.0.0">
  <Header>
    <Title>
      Instrument TraceSource
    </Title>
  </Header>

  <Snippet>
    <Code Language="CSharp">
      <![CDATA[class Instrument
      {
          public static System.Diagnostics.TraceSource ts =
              new System.Diagnostics.TraceSource("Instrumentation");

       }]]>
     </Code>
  </Snippet>

</CodeSnippet>

<CodeSnippet Format="1.0.0">
  <Header>
    <Title>
      Instrumentation Enter Exit
    </Title>
  </Header>

  <Snippet>
    <Declarations>
      <Literal>
        <ID>Class</ID>
        <ToolTip>Name of surrounding class</ToolTip>
      </Literal>
      <Literal>
        <ID>Function</ID>
        <ToolTip>Function to instrument</ToolTip>
      </Literal>

    </Declarations>

    <Code Language="CSharp">
      <![CDATA[Instrument.ts.TraceEvent(System.Diagnostics.TraceEventType.Start, 1,
          "Entering $Class$.$Function$");

    // Insert code here

    Instrument.ts.TraceEvent(System.Diagnostics.TraceEventType.Stop, 2,
            "Leaving $Class$.$Function$");]]>
   </Code>
  </Snippet>

</CodeSnippet>

This walkthrough demonstrates prototyping and the instrumenting of code using Visual Studio. We will convert part of the UML Class Diagram for the retail banking system (see 2-3, shown previously) to a Visual Studio Class Diagram. Afterward, the class operations will be prototyped and instrumented. Because the intent is to validate the sequence diagram, we will omit attribute and other extraneous information. The aforementioned snippets for instrumentation will be used to instrument the methods of the application. Therefore, you must create and import the snippets before the walkthrough. Steps for importing a snippet can be found online at MSDN. Search for articles on code snippets. The walkthrough uses a console project.

Here are the steps to add a new class diagram to the project. A shape is then added to the diagram.

Add the Employee, Manager, and Teller classes to the class diagram. Employee is the base class to the Manager and Teller classes. Here are the steps.

2-11 shows the Visual Studio class diagram for the retail banking system.

Figure 2-11. The Visual Studio class diagram for the retail banking system.

The function prototypes already exist. This occurred when the methods were added to the class diagram. The next step is to instrument the functions. First, we must create the TraceSource object to be used. This can be done with the snippet provided earlier. Here are the steps:

The trace source is controlled from an application configuration file. In our example, tracing should be sent to a console window. We also want to display all activity tracing, which includes the Start and Stop events used in the instrumenting of the methods. Here is the application configuration file:

<configuration>
  <system.diagnostics>
    <sources>
      <source name="Instrumentation"
        switchName="sourceSwitch">
        <listeners>
          <add name="console"
            type="System.Diagnostics.ConsoleTraceListener">
          </add>
           <remove name="Default"/>
        </listeners>
      </source>
    </sources>
    <switches>
      <add name="sourceSwitch" value="ActivityTracing"/>
    </switches>
  </system.diagnostics>
</configuration>

So far, we have created the class diagram, prototyped the methods, defined an instance of the TraceSource class, and added an application configuration file. You are ready for the last step. That step is to instrument the methods of each class. A snippet is used to instrument the Enter and Exit events of a method.

According to the class diagram, there is a relationship between the Customer and Teller classes. For this reason, the Teller class is embedded in the Customer class. The Teller class is exposed as a property of the Teller class. In the Customer class, you need to update the Teller property to use automatic Get and Set functions, as shown in the following code.

public Teller Teller
{
    get; set;
}

According to the sequence diagram, the Customer.Withdrawal method calls Teller. CustomerWithdrawal, while Customer.Deposit calls Teller.CustomerDeposit. The prototype should confirm this sequence. In Main, the code is written to test this sequence.

static void Main(string[] args)
{
    Customer cust = new Customer();
    cust.Teller = new Teller();
    cust.Deposit();
    cust.Withdrawal();
}

Run the program, and view results. Congratulations! You have validated the sequence diagram. There were a few steps to accomplish this. Of course, this is a simple example. The more complex the application, the greater the return on investment. You are ready to begin full coding.