With the needs of the business world becoming entangled in a web of complexities such as conflicting requirements, potential miscommunication, and technological risks, it is imperative for software development teams to adopt a technique that can effectively capture the real-world context for business requirements and problems (the problem domain), and then evolve them towards defining a software solution.

The value of using object-oriented analysis and design techniques for developing software derives from two facts; it enables the real world business complexity to be addressed in a very modular and disciplined manner, and promotes the development of software solutions that are inherently maintainable over time.

However, prerequisites exist for designing object-oriented software solutions. The first is fluent communication among everyone involved in creating and deploying the software solution—the more complex the solution, the more critical communication becomes. The second prerequisite is a unified language that describes concisely and without misinterpretations the software analysis and design tasks at hand that will ultimately dictate the solution system.

In the past, there were “Method Wars” where many formal object-oriented software development methodologies, each with its own proprietary language, battled to be the standard approach for capturing the analysis and design efforts of a project. This was a trying time for everyone involved in object-oriented development projects because there was no consistency in how software solutions were methodically analyzed, designed, and developed. The leading methodologists in this paradigm—Grady Booch, James Rumbaugh, and Ivar Jacobsen, also known as the “Three Amigos,” resolved this frustration by establishing the Unified Modeling Language, or UML, which today has emerged as the de facto software development blueprint language.

As a software developer, you will be challenged to create software solutions where the need for the solution initially surfaced as a problem to be solved. This chapter’s focus is to explain clearly how to use UML effectively in the Analysis and Design phases of a software development lifecycle.

The Unified Modeling Language (UML) is a graphical object-oriented modeling language that provides a visual syntax for capturing the important elements from a business problem domain and documenting it as a series of visually self-describing models, known as artifacts. A collection of artifacts pertaining to a specific business problem is known as the model domain.

UML does not describe or dictate how software should be developed. Instead, it promotes a process of abstraction where the essential elements and their respective attributes within the context of a business problem are separated from the whole business problem. This provides an extremely visually oriented and focused platform for deriving a software solution.

UML supports many types of artifacts, because there are many perspectives from which to observe a software system depending upon who you are in relation to the project. For example, a software developer will be interested in converting the design of the software into programming code, while a business analyst will be interested in the behavior of the software solution in relation to the initial problem domain. The UML artifacts are categorized by eight primary diagrams, as described in Table 3.1. Textual artifacts do exist in the context of these eight diagrams and will be discussed later in this chapter with their respective diagrams when applicable.

Each UML diagram in Table 3.1 models a specific aspect of a software system, and hence contributes to the overall abstraction process of a problem domain. For example:

The artifacts also exist as living documents that provide an ideal reference for software maintenance by providing all the traceable details of what the software was intended to do and how it intended to do it.

One of the definitions of discipline is the knowledge or training gained from misfortune or bad conduct. The objective of a software development methodology is to adopt and then promote a series of disciplines that, if followed in a methodical and disciplined manner, can lead to a successful software development process. There are a variety of methodologies that can be applied towards the development of object-oriented software, such as the Rational Unified Process (RUP), eXtreme Programming (XP), and Feature-Driven Design. These methodologies provide structure to help monitor a predictable schedule by assigning phases or steps to the development lifecycle.

UML by design, is neither a methodology nor identified with any one particular software development methodology. No matter which methodology you decide to use, UML can be embraced as a standard modeling notation. The modeling notations provided by UML exclusively address the analysis and design phases of a software development lifecycle, where UML artifacts are used to record the analysis and design decisions. Through the visual representation of the analysis and design phases using UML, you can easily:

However, the approaches and activities undertaken in the analysis and design phases to derive UML artifacts are governed by which methodology you are using.

UML artifacts are primarily diagrams with supporting textual information. To efficiently generate these diagrams and manage their supporting information, it is extremely important to leverage an analysis and design modeling tool that supports the UML standard as specified by the Object Management Group (OMG). There are plenty of modeling tools, graphics packages, and Java Integrated Development Environments (IDEs) that do provide UML support.

However, the Together ControlCenter (TCC) 6.0 product from the TogetherSoft Corporation is the modeling and development product of choice within this book. The motivations for this decision are because TCC is the only product that successfully provides an intuitive end-to-end Model-Build-Deploy development platform for constructing J2EE enterprise solutions on the BEA WebLogic Platform 7.0. The TCC enables business analysts, application architects, and software developers to leverage a single modeling and development environment, minimizing the need to acquire, learn, and use multiple products.

Also, the TCC is the only development tool that works the way developers work. Because TogetherSoft understands that development is iterative, TCC provides features that encourage forward momentum throughout development, for example:

Another advantage that will be of primary importance to an enterprise is that the TCC product itself is not bound to any specific development methodology nor does it enforce any. This enables project teams to decide a methodology based on the type and scale of their project, rather than based on a modeling tool.

As previously mentioned, UML is an object-oriented modeling language. The models that are created provide a visual representation of the structure and behavior of a solution software system. UML diagrams are created by grouping a collection of elements tied together by relationships. These elements are the building blocks of UML. There are four types of UML elements: structural, behavioral, grouping, and annotational, which are described in the following sections.

The Grouping Elements of UML

Grouping elements provide a means to organize the UML structural and behavioral elements through the employment of package elements. A package is basically a general purpose container into which related elements can be placed, similar to a folder or directory in an operating system (see Figure 3.9).

Figure 3.9. The UML representation of a package.

Package diagrams are optional to UML and not discussed in this chapter.

The Annotational Elements of UML

Annotational elements constitute the explanatory parts of a UML model. For example, the note element can be used to attach a comment to another element (see Figure 3.10).

Figure 3.10. The UML representation of a note.

During the Analysis phase a current list of system requirements are analyzed to understand, evolve, communicate, and establish what the system requirements will be for a technical solution to a business problem. The emphasis in the Analysis phase is to understand what the requirements do as opposed to how to implement the requirements, which is the primary focus of the Design phase. It is in the Analysis phase where UML can be first introduced.

In UML, use cases are the primary tool for analyzing and driving the specification for a system. The objective of the use cases is to model the external interactions of a system under consideration, by visually describing who will use the solution system and how will they use it.

In UML terminology, any user of the system is referred to as an actor, which can be a person or another entity, such as a software system that exists outside the bounds of the system being defined. Each actor plays a role and generates events that cause the system to perform a value-based scenario on its behalf. From scenarios you can understand the behavior of a system because they describe a specific sequence of events, from the triggering event that begins the scenario to its logical conclusion. Identifying who the actors are is key to the analysis of a system as the scope of the system and the required external interfaces begin to emerge when actors are identified.

A use case defines how an actor interacts with the system. Developing a use case is all about building a portfolio of scenarios and alternatives of how actors interact with a system and following through their interactions until you get a complete understanding of how the system should conceptually respond. A use case can encompass many scenarios, for example:

The visualization of the use case is provided with the Use Case diagram. Associated with Use Case diagrams are textual artifacts called Use Case specifications that typically contain the following details:

The contents of the use case specification are not specified by UML, and are completely at the discretion of the project team to specify. However, it is recommended that the granularity of the use case specification be at a level that eases the comprehension of the Use Case diagrams.

The Features of a Use Case Diagram

This section will enable you to understand how to develop Use Case diagrams by illustrating simple scenarios of a Customer interacting with a Library System under analysis, as illustrated in Figure 3.11.

Figure 3.11. A Use Case diagram of a Customer interacting with a Library System.

• The system under consideration is defined in the context of a System Boundary and is represented by a rectangle. In Figure 3.11, the System Boundary is the Library System.

• Actors are represented as stick figures. The only Actor in Figure 3.11 is the Customer because it is the only external entity interacting with the Library System and initiating the following use cases:

  • Reserve Book

  • Cancel Book reservation

  • Pickup Reserved Book

  • Borrow Book

  • Renew Book

  • Return Book

  • Pay Late Return Fee

  • Charge Account

  The UML notation illustrated in Figure 3.12 represents UML entities and concepts that are not people but nevertheless interact with the system, such as organizations, hardware or software systems, and date/time-based systems.

  

  Figure 3.12. The UML representation of a non-person actor.

• The use cases performed by the Customer actor are represented as bubbles, as illustrated in Figure 3.11.

  Note

  Use cases are always written in the same vocabulary as the end-user to ensure a consistent method for communicating system analysis and new requirements.

• The connection between actors and associated use cases is known as a communication association (communication for short) and is represented as a single line between an actor and a use case, as illustrated in Figure 3.11.

• Generalizations or parent-child relationships between use cases are annotated as a line with a triangular arrow head toward the parent use case. An example of a use case generalization is illustrated in Figure 3.11, where the Pay Late Return Fee is a parent use case and Charge Account is the child.

  Note

  A use case generalization shows that one use case is simply a special kind of another use case.

• When one use case can be factored out of two or more use cases, the relationship between the use cases is known as an include relationship and is annotated as a dotted line with an <<include>> label. In Figure 3.11, the Borrow Book use case can be factored out of the Pickup Reserved Book and Renew Book use cases.

• When one use case is a variation of another, the relationship between the two use cases is known as an extend relationship and is annotated as a dotted line with an <<extend>> label. The extension point, which determines when the extended case is appropriate, is written inside the base use case. In Figure 3.11, the extend relationship can be seen between Pay Late Return Fee and the Reserve Book, Borrow Book, and Return Book use cases. The extension point in the Pay Late Return Fee use case is “No Fine Due.”

UML Class diagrams are imperative to any object-oriented design effort, as they provide the static design view of the solution system and the structure of the code that will be produced in the development effort. However, they can also be used in the Analysis phase, where they are aptly known as conceptual models. The objective of a conceptual model is to capture the concepts that need to be addressed by a system, the properties of those concepts, and how they are related. A byproduct of developing conceptual models is a greater understanding of a system’s business context, because the captured concepts will be derived from the stakeholder’s perspective and vocabulary. Because conceptual models are drafted in the Analysis phase, they will not be as rich as traditional Class diagrams, which will be discussed later in this chapter. However, they do provide a great foundation for the Class diagrams that will be produced in the Design phase.

The Features of a Conceptual Model

The idea behind conceptual modeling is to capture the primary concepts or ideas behind the solution system, with which the stakeholders must be familiar. Concepts can be derived directly from a system’s requirements specification, for example by extracting the following candidate concepts:

• Tangible objects

• The roles of end-users

• Transaction types

• Places and locations

• Organizations

• Events

Note

This list only provides examples of candidate concepts and should not be used as a complete reference for identifying concepts.

Alternatively, concepts can be derived from facilitated workshops geared towards identifying concepts with the stakeholders. It is important to ensure the concepts that are identified have structural attributes that further describe the concept in the context of the stakeholder business environment. UML does not specify how you can develop conceptual diagrams; it only provides the notation to capture them, which is illustrated in Figure 3.13.

Figure 3.13. The UML representation of a concept.

Note

A UML representation of a concept does not contain any associated behavior because it is more aligned with the design of a system rather than the analysis.

Referencing Figure 3.13, an example of a Manager concept, including its attributes, is illustrated in Figure 3.14.

Figure 3.14. An example of a Manager concept.

Relationships between concepts in UML are expressed as a single line called an association. Each association has a descriptive name and a multiplicity (cardinality) that describes the number of instances a concept can participate in the relationship. The multiplicity is expressed as a number at the ends of an association using the following syntax:

• * means many (zero or more).

• 1..* means one or more.

• 1..n, means 1 to exactly n, where n is a specific number.

• m..n, means m through to exactly n, where m and n are specific numbers.

For example, Figure 3.15 illustrates a relationship where one CEO concept manages one or more Director concepts.

Figure 3.15. An example of an association between a CEO concept and a Director concept.

When drawing a conceptual model, the best approach is to take one concept, identify all its associations and cardinalities with other concepts, and then move to the next concept and apply the same approach and so on.

A Class diagram created in the Design phase provides a visual representation of each class that is contributing to a Use Case realization. Class diagrams are an essential aspect of any design effort because they directly portray the code that will be developed for a system. UML does not provide a mechanism for developing a Class diagram. However, the information needed to identify classes and their associated relationships can be derived directly from a conceptual model, if it exists, or from the objects that can be identified from the respective use case.

The Features of a Class Diagram

A Class diagram represents each class as a table with the following three sections:

• A class name that identifies the class.

• A list of attributes that describes the properties of the class.

• A list of operations that describes the behavior of the class.

For the UML notation for representing a class, refer to Figure 3.3.

The relationships between classes within a Class diagram are represented by connecting lines indicating either an association or generalization-type relationship. The type of relationship is indicated by the line style.

Association Relationships

Relationships between classes are expressed as associations with a navigability arrow indicating which direction the association can be traversed or queried. If multiplicity is not indicated, the association is assumed to be a one-to-one relationship between the classes. An example of a one-to-five through 10 association is illustrated in Figure 3.16.

Figure 3.16. An example of a one-to-five through 10 association between two classes.

When the association between two classes is not obvious, a role name can be used to uniquely identify one end of an association. In most cases, the class or an attribute name that clarifies the association can be used as the role name. Figure 3.17 illustrates how the multiplicity and role names can be placed on an association.

Figure 3.17. The UML notation for using multiplicity and role names together on the same association.

When using role names and multiplicity with associations, the class diagram can become quite complicated to read. It is important when reading an association between two classes that you read from one specific direction (class), using the navigability arrow to follow the association to the target role and multiplicity. For example, the associations illustrated in Figure 3.18 can be described as follows:

Figure 3.18. An example of reading an association with a multiplicity and role name.

• A lecturer teaches many (zero or more) courses.

• Each course has many (zero or more) lecturers and between 10 and 20 students.

• A student takes many (zero or more) courses.

To support the design of object-oriented systems, UML supports three special types of associations in the context of Class diagrams: Reflexive, Aggregation, and Composition associations.

A Reflexive association describes an association relationship between objects of the same class. Such a recursive association is shown as an association that originates and terminates at the same class. For example, Figure 3.19 illustrates a reflexive association where a person manages many persons in the role of staff and a person is managed by zero or one person in the role of manager.

Figure 3.19. An example of a Reflexive association.

An Aggregation association describes an association between a class (the container class) that can be aggregated from other classes (aggregate classes). An Aggregation association is drawn with an open diamond tip pointing to the container class from the aggregate classes. A feature of the container class is that it has the aggregate class as an attribute, but does not control the life span of the aggregate class. An example of an Aggregation association is illustrated in Figure 3.20, where a computer is an aggregation of the CPU, disk, memory, and video card classes.

Figure 3.20. An example of an Aggregation association.

A Composition association is a stronger form of Aggregation association in that it implies the container class cannot exist without its composite (aggregate) classes. A composition relationship is drawn as a filled diamond tip pointing to the container class. An example of a Composition association is illustrated in Figure 3.21, where a book cannot exist without a cover.

Figure 3.21. An example of a Composition association.

Generalization Relationships

Generalization relationships support the concept of inheritance (reuse) in UML Class diagrams, where common attributes and operations are factored out of similar classes and assigned to a broader superclass (base class). Classes that inherit the attributes and operations of a superclass are known as subclasses (derived classes). A subclass can override the inherited attributes and operations, or add its own attributes and operations to them.

Note

The process of defining subclasses is known as specialization and is applicable in Use Case diagrams to represent inheritance.

In UML a generalization relationship is indicated with an arrow head pointing at the superclass. Figure 3.22 illustrates a generalization relationship where an Animal class is the superclass and the Dog and Person classes are its subclasses.

Figure 3.22. An example of a generalization association.

Interaction diagrams are about deciding and modeling how your system will achieve what you described in your use case models. Interaction diagrams enable you to visualize, specify, construct, and document the dynamics of how each object in your system interacts (exchanges messages) in order to perform a particular task. The context of a task equates to a single use case scenario.

UML provides two types of interaction diagrams that can be used to model the interactions between objects within the context of a use case scenario: Sequence and Collaboration diagrams. The Sequence and Collaboration diagrams represent two dynamic perspectives to view exactly the same information as they both model the messages that are passed between objects. Also, Sequence and Collaboration diagrams are isomorphic, implying that you can easily derive one from the other. In fact, most modeling tools, such as the Together ControlCenter, will automatically generate one diagram from the other.

Distinctions between the Sequence and Collaboration diagrams exist in how they portray the same information, as follows:

Both Interaction diagrams provide a visual representation of the objects in a system’s design and the order they send messages to each other. In UML terminology, sending a message refers to calling one of the operations (methods) of an object. Hence, the Class diagrams in conjunction with the Interaction diagrams can provide an initial platform to begin coding a solution.

Because Sequence and Collaboration diagrams are isomorphic, you can learn how to model one of them and catalyze your comprehension of the other through the use of a professional modeling tool, which can perform the conversion between the two model types. The following section will describe the most common features of a Sequence diagram.

The Features of a Sequence Diagram

As illustrated in Figure 3.23, a Sequence diagram has two dimensions:

• The time dimension (Y-axis) represents the progression of time.

• The object dimension (X-axis) represents the different objects that interact in a specific use case scenario.

  

  Figure 3.23. The dimensions of a Sequence diagram.

Note

The axes can be interchanged, so that time proceeds horizontally to the right and different objects are shown as horizontal lines.

The control of flow by time in a use case scenario is represented in a Sequence diagram through the following:

• Objects that interact in the context of a use case. The objects that initiate interactions are typically placed on the left of the object dimension, with subordinate objects to their right.

• An object lifeline represents the existence of an object over a period of time. Objects that exist throughout an interaction should appear at the top of the object dimension with their lifelines drawn parallel to the Time dimension. Objects that are created and destroyed dynamically (transient objects) have object lifelines that begin and end with a receipt of a message.

• A focus of control, also known as the Activation bar, illustrates the period of time an object is performing an action. Actions can either be performed directly by an object, or through a subordinate object to which it has sent messages.

• Links provide a semantic connection between objects. They serve as a path along which one object can dispatch a message to another object.

• Messages specify communication from one object to another, with an expectation that an activity will be performed by the recipient object.

Figure 3.24 illustrates how you can represent objects, object lifelines, focus of control, links, and messages in the context of a Sequence diagram.

Figure 3.24. The representation of objects, object lifelines, focus of control, links, and messages in the context of a Sequence diagram.

In addition to the basic flow of control, as illustrated in Figure 3.24, you can also represent the following control flows in a Sequence diagram:

• Selection, as illustrated in Figure 3.25.

  

  Figure 3.25. The representation of a selection flow in a Sequence diagram.

• Recursion, as illustrated in Figure 3.26.

  

  Figure 3.26. The representation of a recursive flow in a Sequence diagram.

• Iteration, as illustrated in Figure 3.27.

  

  Figure 3.27. The representation of an iterative flow in a Sequence diagram.

The Sequence diagram in Figure 3.28 represents the focus of control, conditional selection, recursion, creation, and destruction aspects of a Sequence diagram.

Figure 3.28. The representation of a focus of control, conditional selection, recursion, creation, and destruction aspects of a Sequence diagram.

The Collaboration diagram for the Sequence diagram represented by Figure 3.28 is illustrated in Figure 3.29, which can easily be generated using a professional modeling tool.

Figure 3.29. The Collaboration diagram representing the Sequence diagram in Figure 3.28.

Note

A Sequence and Collaboration diagram based on a use case scenario is described in the section “UML By Example—The Book Store,” which appears at the end of this chapter.

Tip

Because object-oriented software development is an iterative process, it is often very helpful to write some prototype code to help solidify the design. This becomes evident while developing Sequence diagrams, where you may realize that you need a message that is not yet an operation in the Class diagram. You must therefore update the Class diagram to include the new operation. To maintain traceability, any modifications to your analysis or design must be put back into all affected diagrams. This is not as bad as it sounds if you are using a professional UML modeling tool, such as the Together ControlCenter.

The Statechart diagram shows the sequence of object states a single class can exhibit during its lifetime, together with the events that cause the changes of state. This is in contrast to the Interaction diagrams, which show the interaction between multiple classes.

The classes of objects that a Statechart examines can be derived from UML diagrams, such as Use Case, Class, or Interaction diagrams. The intent is not to develop Statechart diagrams for every class in a system—only those that show variable or complex behavior (reactions) to events dispatched from outside their context should be considered. For example, in the Model, View, Control (MVC) design pattern, it is the responsibility of the Control to react to events. For this reason, the behavior of the Control is a good candidate for a Statechart diagram.

The Features of a Statechart diagram

A Statechart is typically comprised of the following elements:

• A state belongs to a single class and represents a combination of possible attribute values that the objects of this class may assume during the life of the class. The UML notation for representing states is illustrated in Figure 3.8.

• An event is the occurrence or stimuli that triggers a state transition. For example, an object receives a message. Events can also have arguments that are passed from state to state as well as actions, which are regarded as atomic operations that prematurely terminate.

• A transition is a relationship between two states. It implies that when a change of state is caused by an event in the first state, the object will move to the second state. All events exist in the context of transitions, as illustrated in Figure 3.30.

  

  Figure 3.30. The UML representation of States, Events, and Transitions.

Figure 3.31 illustrates an example Statechart diagram that has been derived from a Sequence diagram.

Figure 3.31. A Statechart diagram that has been derived from a Sequence diagram.

An Activity diagram is a special form of state diagram that is used to model a sequence of behaviors and conditions taking place within the context of a workflow process. In many perspectives, Activity diagrams are similar to flow charts, except they have the capability to model parallel as well as sequential processes.

Activity diagrams can be used to examine workflow logic related to many scenarios, for example:

Activity diagrams are the perfect UML tool for depicting the flow of activities within workflow type scenarios in your system. However, they do not provide details about how objects behave or collaborate with each other, which is an important aspect of any design process. For this reason, Activity diagrams should be used in conjunction with Statechart or Interaction diagrams.

The Features of an Activity Diagram

Activity diagrams are read from top to bottom and typically consist of the following elements:

• Activities or activity states, which represent the invocation of an operation, a step in a business process, or an entire business process.

• Transitions or threads, which represent the flow of control from one activity to another through a link between the activities. A transition that involves an object is known as an object flow.

• Branches, where a transition splits into two or more mutually exclusive alternatives.

• Merger, where two or more transitions resulting from a branch combine.

• Forks, a point where a transition splits into two or more other transitions, all of which are taken. A fork is a mechanism to represent concurrent processing. This is in contrast to a branch where only one of the transitions is taken as the path to the next activity.

• Join, a point where two or more forked transitions re-join.

• Swimlanes, which represent a mechanism to group activities performed by the same organizational units.

Note

If an Activity diagram is used to model the flow of activities in a Use Case scenario, the swimlanes would identify which actor is performing the activity.

A sample Activity diagram is illustrated in Figure 3.32.

Figure 3.32. A example of an Activity diagram showcasing its elements.

UML provides two types of diagrams that provide insight into how the final software solution will be implemented. These diagrams are the Component and Deployment diagrams.

Component Diagrams

The Component diagrams are extremely useful for architects and developers as they provide a static implementation model of the software components and their respective dependencies that will eventually constitute the solution system, which from a development perspective is the light at the end of the tunnel.

The components modeled in the Component diagram are primarily derived from the UML Class diagrams and can be represented as source code, binary code components, and executable components. Components are connected by dependencies, which implies that one component uses the services of the other.

The elements of a Component diagram are illustrated in Figure 3.33:

• A component represents a software module.

• A subsystem is used to package components that are related to a specific business task.

• An interface describes a group of operations used or created by components.

• Dependencies represent communication (services rendered) between components.

Figure 3.33. The elements of a Component diagram.

Deployment Diagrams

One of the key tasks that a software architect has to perform is to decide the application and hardware infrastructure that is required to support the final solution. Deployment diagrams are the appropriate UML diagrams to capture infrastructure decisions because they graphically represent processing resources (nodes), and the runtime instances of software components that can reside on them. If your application is distributed, a Deployment diagram is essential. By visually mapping software components to their respective executable environments (Nodes), you can examine such deployment issues as fault-tolerance and single-points of failure, and identify possible performance problems.

Note

The Deployment diagram is related to the Component diagram because the components typically exist in the context of a node.

The elements of a Deployment diagram are illustrated in Figure 3.34:

• Nodes represent a physical processing resource, for example a J2EE server that participates in the deployment effort of a system.

• Associations represent the connection protocol between nodes, for example TCP/IP and HTTP.

• Components represent the runtime software modules of the software solution, for example Servlets, JavaServer Pages, and Enterprise JavaBeans.

Figure 3.34. The elements of a Deployment diagram.

An example of a simple J2EE application Deployment diagram is illustrated in Figure 3.35.

Figure 3.35. An example of a J2EE application deployment diagram.

This section will describe a simple requirement for a Book Store system and explain how you can derive a use case from the requirements specification and the Activity, Class, and Interaction diagrams from the use case.

The requirements for the Book Store system are as follows:

Deriving the Book Store Use Case Diagram

An analysis of the requirements will provide you with a list of Actors and how they will use the Book Store system; these are your use cases. The idea is to create as many use cases as necessary to fully describe the system requirements.

Note

There is not a one-to-one relationship between system requirements and use cases.

The derived actors for the Book Store use case are as follows:

• Customer

• Catalog

The derived use case scenarios for the Book Store are as follows:

• Use Case 1: The customer browses the catalog.

  The Book Store enables customers to browse all entries in the catalog. The only error condition is that the customer does not find any books of interest. The alternative flow requests the customer to fill out a survey.

• Use Case 2: The book store enables customers to search the catalog by title and author.

  This use case has the same alternative flow as Use Case 1. In fact, browsing the catalog can be thought of as searching for every book by every author. Use Case 2 is actually a specialization of Use Case 1. The Use Case diagram, as illustrated in Figure 3.36, visualizes this relationship as a generalization.

Figure 3.36. Use Case diagram: Browse the book store catalog.

Most likely your projects will have multiple use cases from which to derive the design. The objective is to realize each use case into a system design in a methodical manner using UML. Trying to design all of the classes for the entire application at the same time would be an overwhelming and discouraging undertaking. Also, in the real world, you will be working with a group of developers, where each developer can concurrently design different parts of the application from individual use cases.

Deriving the Book Store Activity Diagram

From the use case, the next step is to create an Activity diagram. This will give you a more complete understanding of the use case before creating Class diagrams. The Activity diagram maps very well to the scenario and alternatives given by a use case. The Book Store Activity diagram is illustrated in Figure 3.37.

Figure 3.37. The Book Store Activity diagram.

The swimlanes in the Activity diagram show who is performing the actions. The Customer performs “search catalog” which causes a transition to Catalog to “perform query.” A decision is used to indicate the alternative flow requiring “fill out form” to be performed by the Customer.

Deriving the Book Store Class Diagram

To derive a Class diagram, you must refer to the Use Case and Activity diagrams. The Activity diagram in Figure 3.37 indicates the Customer has an association with the Catalog. The Use Case specification indicates that a customer must provide an operation to search the catalog. This requirement, in turn, shows the need for a Book object that is returned from the search. Now that you have reviewed and evaluated the Activity diagram, you can create your Class diagram. Figure 3.38 illustrates the realization of the Book Store Use Case in the form of a Class diagram.

Figure 3.38. The Book Store Class diagram.

From Figure 3.38, you can identify the following:

• Customer has an association with Catalog.

• Catalog has a composition of multiplicity 0..* to the Book class.

Deriving the Book Store Interaction Diagrams

As you may have guessed, the Book Store Sequence diagram, Figure 3.39, was completely generated by the Together ControlCenter. This tool enables you to generate a Sequence diagram from selected methods in a Class diagram. This is an extremely powerful capability of the design tool. The generated Sequence diagram is also shown as a Collaboration diagram in Figure 3.40, which was also auto-generated by the Together ControlCenter.

Figure 3.39. The Book Store Sequence diagram.

Figure 3.40. The Book Store Collaboration diagram.