Unified Modeling Language and Object-Oriented Design

Feb. 26, 2003 12:00 AM

When constructing enterprise-level object-oriented applications, it is imperative to incorporate a well-organized, systematic approach to the development of the system. Most software application failures can be traced back to the lack of a unified governing project design among the various participants and owners of the project. It is one thing to build small, self-contained applications working with a team of one, but quite another to build a multitiered, enterprise-level application with a team of many. A good analogy is to compare building a storage shed with constructing a house. You can probably get away with haphazardly constructing a functional shed in the back yard. You cannot, however, successfully construct a house or office building in a similar fashion.

Enterprise-level software projects utilize teams of developers. As a member of a team, you will be asked to convert the design documents into actual implementation code. Furthermore, since modern software design is an iterative process, you will be asked for input on the development and refinement of the design during the coding phase. Just as Detroit has found that it is critical to have empowered assembly line workers who actively contribute to the design and development process of building cars, enterprise architects are dependent on application programmers for input on the refinement and development of the application design. Therefore, a software developer needs to be familiar with the purpose and structure of the various design documents used to manage the development of the application. Furthermore, lead programmers are often asked to sit in on design sessions and develop some of the design documentation. As a result, lead programmers must be comfortable working with tools such as Visio to develop the design documents.

This article is the first in a series that will introduce you to the goals of software design, the Unified Modeling Language design documents commonly used to aid in the design of software applications, and the use of Visio to create the UML design documents introduced.

The Goals of Software Design
Recent analysis of the success of software application projects has painted a bleak picture. The Standish Group conducted a study of 30,000 application projects of various sizes and across various industries. The study revealed that less than 30% of the projects were considered successful. Success is defined as completed on time, on budget, and containing the original feature set commissioned. The study also revealed that historically 25% or more of projects were cancelled before completion. Analysis of the data from the study reveals that the underlying cause of failure is not the complexity of the technology or the skill sets of the programmers involved in the project. The major reason for failure stems from a lack of communication, accountability, and ownership. In other words, a major factor in the failure of application projects is a lack of a governing project management and design methodology.

While there are many viable design methodologies to choose from, successful design methodologies have some common characteristics. They use an empowered team approach to developing software applications and encourage small iterative development cycles. Communication among project participants is carefully monitored and facilitated through a combination of formal and informal documentation. Investing in a sound design methodology will greatly increase the likelihood the project will succeed and accomplish the following:

Provide an opportunity to review the current business process and fix any inefficiencies or flaws uncovered

Educate customers as to how the software development process occurs and incorporate them as partners in this process

Create realistic project scopes and timelines for completion

Provide a basis for determining the software testing requirements

Reduce the cost of and time required to implement the software solution

The Unified Modeling Language
At the root of any design, methodology is a series of formal or informal design documents (models). These documents are a valuable aid used to focus development efforts and to facilitate communication between the various team members. In the early '80s, several software-modeling languages were being developed in an effort to standardize the documents and notations used to model object-oriented software applications. In the mid '90s, the various versions were consolidated into the Unified Modeling Language specification. The specifications were submitted to the Object Management Group (OMG), a nonprofit consortium of leading software industry companies, for approval.

Since the UML specifications are overseen and governed by the OMG, UML is a nonproprietary open specification. As such, it has been adopted and incorporated into many object-modeling tools on the market today. An added advantage is that UML is agnostic to the language implementation of the model. The same UML design can be converted into a variety of different object-oriented languages, such as Java, C#, VB.NET, or Smalltalk. As a matter of fact, many of the leading design tools also enable forward engineering from the UML model into the class structure of several popular object-oriented languages.

UML consists of a series of textual/graphical models of the proposed solution. These models are used to define the system scope, components of the system, user interaction with the system, and how the components of the system interact with each other to implement the functionality of the system. Some common documents (models) used in UML are:

Use case: A textual/graphical description of how the system will behave from the user's perspective. Users can be humans or other systems.

Class diagram: A visual blueprint of the objects that will be used to construct the system.

Sequence diagram: A model of the sequence of object interaction as the program executes. Emphasis is placed on the order of the interactions and how they proceed over time.

Collaboration diagram: A view of how objects are organized to work together as the program executes. Emphasis is placed on the communications that occur between objects.

Activity diagram: A visual representation of the flow of execution of a process or operation.

Defining System Scope
The first step in modeling the application is to define the system scope. In order to define the scope of the system, an open dialog must take place between the clients (users of the system), the system designers, and the system programmers. The goal of the dialog is to clearly define and document the business processing the system must perform and establish realistic scope and expectations of the clients. In the past, most of the dialog between the clients of the system and the programmers was conducted indirectly through a system architect. This isolation of the clients from the programmers is ineffective. The role of the architect is not to act as a go-between, but rather as a facilitator in the design process. His or her job is to focus the discussions and ensure that the clients and programmers agree on the project scope. The architect must help to define the core requirements of the system and which requirements will be incorporated into future rollouts.

The outcome of the scoping dialog is a set of clearly defined statements detailing the functional requirements of the system (collectively referred to as the system requirement specifications or SRS). These statements identify the functionality of the system in terms of how the uses will interact with the system. The technical requirements of the system will be defined later in the design process. The following statements are taken from the SRS of a class registration system being designed for a technical education center.

Nonregistered Web users can search the Web site for course information, including course outline, prerequisites, and schedule.

New students must complete an online registration form providing their name, address, phone number, e-mail address, and billing information.

Students are classified as public or corporate. Corporate students must be affiliated with a preregistered company and include company and contact information.

Registered students can reserve a seat in an upcoming class.

The Use Case Document
After the system requirements have been defined, the next step is to transform these statements into a series of use case models. A use case model is a visual diagram often accompanied by a textual description that defines how the external entities will interact with the system. The external entities can be either human or other software applications and are referred to as actors. A use case is depicted by an oval in the diagram and a communication line connects the use case with the actors involved. Figure 1 represents a use case for the class registration system introduced previously. Each use case can be mapped to a corresponding statement in the SRS document.

The textual description of the use case should be succinct and focused on describing the interaction between the actor and the system. It should be emphasized that the internal processing of the system has yet to be developed and should not be included in the use case description. It is often helpful to include any pre and post conditions that need to be identified for the use case. The following textual description is associated with the use case depicted in Figure 1.

A Web user views the course information lookup page. The Web user enters course search criteria. The search criteria can be course number, type, or keywords used in the course description. After submitting the search request, the user is presented with a list of matching courses and upcoming scheduled dates.

Preconditions: None.

Postconditions: Registered students can sign up for a class. Non- registered students can complete a registration form and sign up for a class. If we examine the postconditions of this use case, we can identify another use case. The Class Registration use case describes the process of registering for a class. A precondition for this use case is the View Course Information use case. This type of relationship between two use cases is often referred to as inclusion. The Class Registration use case must use the View Course Information use case. The View Course Information use case can be used independently of the Class Registration use case and is the reason we break these up into two distinct use cases. Figure 2 demonstrates how inclusion is represented in a use case diagram. An arrow points from the dependent use case to the independent use case and is marked with the "uses" keyword.

Use cases can also be related through extension. A base generic use case is defined that is extended by other use cases. For example, we can define a base Register Student use case. This use case is then extended by more specific use cases such as a Register Public Student use case and a Register Corporate Student use case. The main difference between inclusion and extension is that the extended use case is not used alone. It defines common functionality that will be incorporated into several other use cases. Figure 3 shows a diagram depicting use case extension.

Using Visio to Construct a Use Case Document
To help in the process of developing the various UML models, many programmers and architects use a Computer Aided Software Engineering (CASE) tool. Although there are several excellent third-party CASE tools on the market, one of the most popular tools, Visio, is included in the Enterprise Architect version of Visual Studio .NET. Visio allows you to create professional-quality diagrams, generate customizable UML reports, publish UML models as Web pages, and synchronize the UML model with the programming code.

Before demonstrating the use of Visio, a word of caution is in order. Although I find using a CASE such as Visio very beneficial in the generation of UML models, having a CASE tool is not a requirement for UML modeling. One of the best UML modeling tools available is a whiteboard and a marker. I cannot emphasize strongly enough that most of the value of UML modeling is not in the documents created. The value is in the process. Creating the various documents forces you to systematically think through the issues necessary to successfully design your application. The time you invest in this process will reap huge dividends when you start coding the application.

Complete the following steps to create a use case diagram using Visio. If you do not have Visio installed, follow along and complete the diagram using paper and pencil.
1.   Start up Visio. On the File menu, choose New>Software>UML Model Diagram.
2.   Locate the Shapes window on the left side of the screen. This window includes a tab for the common UML diagrams. Select the UML Use Case tab (see Figure 4).
3.   From the Shapes window click and drag the Actor shape onto the design surface. Right-click the Actor shape on the design surface and choose Properties. You are presented with a UML Actor Properties window. (see Figure 5). Change the name to "Student" and add a description of "registered student". After adding a name and description, click the OK button.
4.   From the Shapes window click and drag the Use Case shape onto the design surface. Right-click the Use Case shape on the design surface and choose Properties. You are presented with a UML Use Case Properties window. Change the name to "View Course Information" and add the following description:

A student views the course information lookup page. The student enters course search criteria. The search criteria can be course number, type, or keywords used in the course description. After submitting the search request, the student is presented with a list of matching courses and upcoming scheduled dates.
After adding a name and description, click the OK button.
5. From the Shapes window click and drag the Communicates shape onto the design surface. Attach one end of the Communicates shape to the Actor shape and the other end to the Use Case shape. The line will turn red if it is not attached properly. Right-click the Communicates shape on the design surface and choose Shape Display Options. You are presented with a UML Shape Display Options window. Click on the Suppress First end and Second end checkboxes. When finished, click OK.
6. Add another Use Case shape to the design surface. Name the use case "Class Registration" and add the following description:

After looking up the course information and retrieving a class identification number, the student enters a username and password. The student submits the request and class confirmation information is displayed.

7. From the Shapes window click and drag the Uses shape onto the design surface. Attach the tip of the Uses shape arrow to the View Course Information use case and the tail end to the Class Regis- tration use case. The arrow will turn red if it is not attached properly. Figure 6 shows the completed diagram.

Summary
This article introduced the Unified Modeling Language and the goals of software design. You have seen how use case diagrams help define the processes necessary to meet the required system functionality and scope and how Visio can aid in the development of use case diagrams. Next time I will focus on developing a UML class diagram. Class diagrams help to model the classes needed to implement the functionality of the application.

Related Links

About Dan Clark
Dan is a Microsoft Certified Trainer, Microsoft Certified Solution Developer, and a Microsoft Certified Database Administrator. For the past seven years he has been developing applications and training others how to develop applications using Microsoft technologies. Dan has been developing and training Microsoft's .NET technologies since the early betas. He has recently authored the book "An Introduction to Object-Oriented Programming with Visual Basic .NET," published by Apress.