Step 4: Design

Show the relations among the elements with Component Diagrams. Add other diagrams where they shed light on the components.

In this step, you’ll assign the interfaces and user interfaces discovered in Step 3 to components, and then show the relationships between components and interfaces in Component Diagrams. You’ll try to identify existing components and interfaces that can be reused, along with new components that will support the new interfaces.

A Component Diagram is a way of depicting the executables and other components that form the logical architecture of your system. At its core, a simple Component Diagram consists of four elements: components, interfaces, realizations, and dependencies. Each of these elements is described in the following sections.

A component depicts a deployable part of your system: an executable, a library, a data store, etc. It’s a physical representation of a group of related classes and objects within your design.

In a Component Diagram, a component icon appears as a rectangle with two rectangular “attachment points” (which are purely decorative; nothing actually attaches to them).

Components: A .NET Perspective

In a .NET solution, a component is any chunk of code or data that you deploy and maintain. Some examples include

• An EXE that represents a console app, a WinForms app, or a Windows service

• A DLL that represents a code library, a WinForms custom control library, or an ASP.NET control library

• The ASPX files that define the Web pages in an ASP.NET site

Some UML practices and tools go even farther, modeling components for the source files that make up your solution as well.

An interface represents one or more related services realized (i.e., provided or implemented) by a component. One component may realize multiple interfaces; and multiple components may realize a given interface.

In a Component Diagram, an interface icon appears as a circle. An interface should also include documentation of its attributes and operations. These might be depicted in a Class Diagram, using the standard class notation with the UML «interface» stereotype; or you might simply list them.

Interfaces: A .NET Perspective

It is important to remember that UML is conceptual, not technological: it isn’t tied to a particular technology; rather, its concepts can be used to represent a range of technologies. When people name things, unfortunately, they have a tendency to reuse and overload terms; and thus, the names are potentially confusing when different speakers come from different backgrounds.

So from a UML perspective, any mechanism that two components use to communicate is an interface: socket messages, HTTP messages, .NET Remoting calls, SQL calls, etc. But in .NET, “interface” has a very specific meaning: a precise protocol by which you can specify a set of operations and attributes that may be used by multiple client classes and provided by multiple server classes. A .NET interface may certainly be modeled as an interface in UML; but not every UML interface is a .NET interface. (You may find it useful to use stereotypes to distinguish various kinds of interfaces.)

A realization indicates that a component realizes a given interface. It’s indicated via a solid line connecting the component to the interface.

In general, a dependency in your model indicates that one element makes use of or depends upon another; and thus changes in the source element will necessitate changes in the dependent element.

In Component Diagrams specifically, dependencies are drawn from components to the interfaces they make use of. A dependency appears as a dashed arrow.

Given these elements, then, a Component Diagram depicts components, interfaces realized by them, and dependencies from components to interfaces. Figure 2-18 is a Component Diagram that depicts the interfaces and components discovered in the Kennel Management System so far.

Figure 2-18.  Component Diagram for the Kennel Management System

So how do you arrive at this diagram? I’ll discuss that shortly, in the section “Step 4: Process in Detail,” where you’ll also see how to extend the diagram to more completely reflect your architecture; but first let’s take a quick look at .NET components.

Components: A (Further) .NET Perspective

Now the .NET developers have to make some specific technology choices, based on the interface technology choices from Step 3. ASP.NET pages and Web services have to be assigned to URLs and deployed to one or more Web sites. Each WinForm needs to be assigned to a component. Does one component provide all forms, or do you have forms distributed among multiple components? If you’re using interfaces or .NET Remoting, which components provide these services? If you’re using ADO.NET, which databases and tables and queries and views will you access? These and many more questions are part of designing a .NET architecture.

Exercise 204: Assign Interfaces to Components with Component Diagrams:

Build Component Diagrams based on the work you’ve already completed in previous exercises. Work with your team to pick out the interfaces from your swimlaned Activity Diagrams from the last step, define components, and create dependencies between them. The next section explains the process in detail.