第 29 页

the Data Connections node in more detail. Chapter 24 wraps it all up with an in-depth look at

managing SharePoint resources using the Server Explorer.

fiGure 9-17

10

Modeling with the Class

Designer

what’s in this chaPter?

.

Using the Class Designer to create a graphical visualization of your

class architecture

.

Easily generating and refactoring your classes with the Class

Designer

.

Using the Modeling Power Toys for Visual Studio 2010 add-in to

better work with large class hierarchies

Traditionally, software modeling has been performed separately from coding, often

during a design phase that is completed before coding begins. More often than not,

the modeling diagrams that are constructed during design are not kept up to date as

the development progresses, and they quickly lose their value as design changes are

inevitably made.

The Class Designer in Visual Studio 2010 brings modeling into the IDE, as an activity that

can be performed at any time during a development project. Class diagrams are constructed

dynamically from the source code, which means that they are always up to date. Any change

made to the source code is immediately reflected in the class diagram, and any change to

the diagram is also made to the code.

This chapter looks at the Class Designer in detail and explains how you can use it to design,

visualize, and refactor your class architecture.

176 .

chaPter 10 modeling WiTh The clASS deSigner

creatinG a class diaGraM

The design process for an application typically involves at least a sketch of the classes that are

going to be created and how they interact. Visual Studio 2010 provides a design surface, called the

Class Designer, onto which classes can be drawn to form a class diagram. Fields, properties, and

methods can then be added to the classes, and relationships can be established between classes.

Although this design is called a class diagram, it supports classes, structures, enumerations,

interfaces, abstract classes, and delegates.

There is more than one way to add a Class Diagram to your project. One way to add a Class

Diagram is through the Add New Item dialog, as shown in Figure 10-1. This will create a new blank

Class Diagram within the project.

fiGure 10-1

You can also add a new Class Diagram to your project by selecting the View Class Diagram button

from the toolbar in the Solution Explorer window or by right-clicking a project or class and selecting

the View Class Diagram menu item. If the project is selected when you create a Class Diagram in

this way, Visual Studio will automatically add all the types defined within the project to the initial

class diagram. Although this may be desirable in some instances, for a project that contains a large

number of classes the process of creating and laying out the diagram can be quite time consuming.

Unlike some tools that require all types within a project to be on the same diagram, the class

diagram can include as many or as few of your types as you want. This makes it possible to add

multiple class diagrams to a single solution.

The Design surface .

177

The scope of the Class Designer is limited to a single project. You cannot add

types to a class diagram that are defined in a different project, even if it is part of

the same solution.

The Class Designer can be divided into four components: the design surface, the Toolbox,

the Class Details window, and the property grid. Changes made to the class diagram are saved

in a .cd file, which works in parallel with the class code files to generate the visual layout shown in

the Class Designer.

the desiGn surface

The design surface of the Class Designer enables the developer to interact with types using a

drag-and-drop-style interface. You can add existing types to the design surface by dragging them

from either the class view or the Solution Explorer. If a file in the Solution Explorer contains more

than one type, they are all added to the design surface.

Figure 10-2 shows a simple class diagram that contains two classes, Customer and Order, and an

enumeration, OrderStatus. Each class contains fields, properties, methods, and events. There is

an association between the classes, because a Customer class contains a property called Orders

that is a list of Order objects, and the Order class implements the IDataErrorInfo interface. All this

information is visible from this class diagram.

fiGure 10-2

178 .

chaPter 10 modeling WiTh The clASS deSigner

Each class appears as an entity on the class diagram, which can be dragged around the design

surface and resized as required. A class is made up of fields, properties, methods, and events.

In Figure 10-2, these components are grouped into compartments. You can select alternative

layouts for the class diagram, such as listing the components in alphabetical order or grouping

the components by accessibility.

The Class Designer is often used to view multiple classes to get an understanding of how they

are associated. In this case, it is convenient to hide the components of a class to simplify the

diagram. To hide all the components at once, use the toggle in the top-right corner of the class on

the design surface. If only certain components need to be hidden, they can be individually hidden,

or the entire compartment can be hidden, by right-clicking the appropriate element and selecting

the Hide menu item.

the toolbox

To facilitate items being added to the class diagram there is a Class Designer

tab in the Toolbox. To create an item, drag the item from the Toolbox

onto the design surface or simply double-click it. Figure 10-3 shows the

Toolbox with the Class Designer tab visible. The items in the Toolbox can be

classified as either entities or connectors. Note the Comment item, which can

be added to the Class Designer but does not appear in any of the code; it is

there simply to aid documentation of the class diagram.

entities

The entities that can be added to the class diagram all correspond to types in

the .NET Framework. When you add a new entity to the design surface, you

need to give it a name. In addition, you need to indicate whether it should be added to a new file or

an existing file.

You can remove entities from the diagram by right-clicking and selecting the Remove From

Diagram menu item. This does not remove the source code; it simply removes the entity from

the diagram. In cases where it is desirable to delete the associated source code, select the Delete

Code menu item.

You can view the code associated with an entity by either double-clicking the entity or selecting

View Code from the right-click context menu.

The following list explains the entities in the Toolbox:

.

Class: Fields, properties, methods, events, and constants can all be added to a class via

the right-click context menu or the Class Details window. Although a class can support

nested types, they cannot be added using the Designer surface. Classes can also implement

interfaces. In Figure 10-2, the Order class implements the IDataErrorInfo interface.

fiGure 10-3

The Toolbox .

179

.

Enum: An enumeration can only contain a list of members that can have a value

assigned to them. Each member also has a summary and remarks property, but

these appear only as an XML comment against the member.

.

Interface: Interfaces define properties, methods, and events that a class must implement.

Interfaces can also contain nested types, but recall that adding a nested type is not

supported by the Designer.

.

Abstract Class: Abstract classes behave the same as classes except that they appear

on the design surface with an italic name and are marked as Abstract (C#) or

MustInherit

(VB).

.

Structure: A structure is the only entity, other than a comment, that appears on the

Designer in a rectangle. Similar to a class, a structure supports fields, properties, methods,

events, and constants. It, too, can contain nested types. However, unlike a class, a structure

cannot have a destructor.

.

Delegate: Although a delegate appears as an entity on the class diagram, it can’t

contain nested types. The only components it can contain are parameters that define

the delegate signature.

connectors

Two types of relationships can be established between entities. These are illustrated on the class

diagram using connectors, and are explained in the following list:

.

Inheritance: The Inheritance connector is used to show the relationship between classes

that inherit from each other.

.

Association: Where a class makes reference to another class, there is an association between

the two classes. This is shown using the Association connector.

If a relationship is based around a collection — for example, a list of Order objects — this can

be represented using a collection association. A collection association called Orders is shown

in Figure 10-2 connecting the Customer and Order classes.

A class association can be represented as either a field or property of a class, or as an association

link between the classes. You can use the right-click context menu on either the field or property or

the association to toggle between the two representations.

To show a property as a collection association you need to right-click the

property in the class and select Show as Collection Association. This hides

the property from the class and displays it as a connector to the associated

class on the diagram.

180 .

chaPter 10 modeling WiTh The clASS deSigner

the class details

You can add a component to an entity by right-clicking and selecting the appropriate

component to add. Unfortunately, this is a time-consuming process and doesn’t afford you the

ability to add method parameters or return values. The Class Designer in Visual Studio 2010

includes a Class Details window, which provides a user interface that enables components to be

quickly entered. This window is illustrated in Figure 10-4 for the Customer class previously shown

in Figure 10-2.

fiGure 10-4

On the left side of the window are buttons that can aid in navigating classes that contain a large

number of components. The top button can be used to add methods, properties, fields, or events to

the class. The remaining buttons can be used to bring any of the component groups into focus. For

example, the second button is used to navigate to the list of methods for the class. You can navigate

between components in the list using the up and down arrow keys.

Because Figure 10-4 shows the details for a class, the main region of the window is divided into

four alphabetical lists: Methods, Properties, Fields, and Events. Other entity types may have

other components, such as Members and Parameters. Each row is divided into five columns that

show the name, the return type, the modifier or accessibility of the component, a summary, and

whether the item is hidden on the design surface. In each case, the Summary field appears as

an XML comment against the appropriate component. Events differ from the other components in

that the Type column must be a delegate. You can navigate between columns using the left and right

arrow keys, Tab (next column), and Shift+Tab (previous column).

To enter parameters on a method, use the right arrow key to expand the method node so that a

parameter list appears. Selecting the Add Parameter node adds a new parameter to the method.

Once added, the new parameter can be navigated to by using the arrow keys.

layout .

181

the ProPerties window

Although the Class Details window is useful it does

not provide all the information required for entity

components. For example, properties can be marked

as read-only, which is not displayed in the Class Details

window. The Properties window in Figure 10-5 shows

the full list of attributes for the Orders property of the

Customer

class.

Figure 10-5 shows that the Orders property is

read-only and that it is not static. It also shows that

this property is defined in the Customer.cs file. With

partial classes, a class may be separated over multiple

files. When a partial class is selected, the File Name

property shows all files defining that class as a

comma-delimited list. Although some of these

properties are read-only in this window, they can, of

course, be adjusted within the appropriate code file.

layout

Because the class diagram is all about visualizing

classes, you have several toolbar controls at your

disposal to create the layout of the entities on the

Designer. Figure 10-6 shows the toolbar that appears as part of the Designer surface.

The first three buttons control the layout of entity components. From left to right, the buttons are

Group by Kind, Group by Access, and Sort Alphabetically.

The next two buttons are used to automate the process of arranging the entities on the design

surface. On the left is the Layout Diagram button, which automatically repositions the entities on

the design surface. It also minimizes the entities, hiding all components. The right button, Adjust

Shapes Width, adjusts the size of the entities so that all components are fully visible. If a single

component is selected, the “Adjust Shapes Width” button adjusts the width of only that component.

If no components are selected, the width of all components are adjusted.

Entity components, such as fields, properties, and methods, can be hidden using the Hide

Member button.

The display style of entity components can be adjusted using the next three buttons. The left button,

Display Name, sets the display style to show only the name of the component. This can be extended

to show both the name and the component type using the Display Name and Type button. The right

button, Display Full Signature, sets the display style to be the full component signature. This is

often the most useful, although it takes more space to display.

The remaining controls on the toolbar enable you to zoom in and out on the Class Designer, and to