10 Analysis Modeling M MAJOR A J O R T TOPICSO P I C S Objectives... 144 Pre-Test Questions...144 Introduction... 145 Collaboration Diagrams... 145 Flow of Events and Special Requirements... 151 Class-Responsibility-Collaboration Cards...152 Class Analysis...153 When Is This Useful... 154 Summary... 155 Post-Test Questions... 156
144 Chapter 10 Analysis Modeling OBJECTIVES At the completion of this chapter, you will be able to: Interpret collaboration diagrams. Create collaboration diagrams to illustrate a rough vision of system design. Create flow-of-events descriptions to accompany collaboration diagrams. Use CRC cards to aid in developing collaboration diagrams. Identify attributes. Identify aggregation and generalization relationships. PRE-TEST QUESTIONS The answers to these questions are in Appendix A at the end of this manual. 1. What do collaboration diagrams illustrate? 2. What is a sequence diagram? 3. What are CRC cards?
Introduction 145 INTRODUCTION In the preceding chapter, you were introduced to the three UML class stereotypes: boundary, entity, and control. Boundary classes form the interface between a system and its users. Entity classes represent data and real-life objects, and control classes represent the actions and processes not represented in boundary or entity classes. In this chapter, you will learn to combine these class types into collaboration diagrams. UML collaboration diagrams describe, in a precise manner, the dynamics of a software s function and represent this information using automated processes. As a programmer, collaboration diagrams provide simplified access to the functionality of a program, therefore, providing timely and robust error analysis with improved options for system upgrades. COLLABORATION DIAGRAMS Collaboration diagrams are a form of an interaction diagram that are used within the analysis workflow to provide an overview of a system's design. They describe the interaction between users and boundary classes and between classes themselves. Figure 10-1 is a portion of a collaboration diagram for the Check Out Asset use case. In this example, a Librarian actor interacts with a boundary class, Check Out UI. 1: Select patron(patronid) : Librarian : Check Out UI Figure 10-1: Collaboration diagram example
146 Chapter 10 Analysis Modeling The labels associated with each of the actors and classes comprising a collaboration diagram use the object : class notation, in which the class name appears after a colon. In the preceding figure, the single boundary class is labeled Check Out UI. This notation indicates that this class is of type Check Out UI. If you intend to specify an instance of a class, you can use the object field to specify the name of the instance. For example, if the activity depicted in the preceding figure could only be initiated by a librarian named Mark, you could specify Mark by labeling the actor Mark : Librarian. Notice that at this stage you need not be concerned with creating class names that conform to program syntax or coding standards. Check Out UI is not a valid class name. The Check Out UI boundary class actually represents a collection of classes representing windows, scroll bars, and all the elements that form the user interface. For now, you are developing an overview of the system, and details can be addressed later. The line between the Librarian actor and the Check Out UI boundary class associates the two. It provides a pathway for communication, which is in the form of messages. In this case, a single message is passed from the Librarian to the boundary class. An arrow illustrates the direction of this message. Sequence numbers and parameter passing Figure 10-2 expands on the preceding collaboration diagram. Notice that a control class, Check Out Controller, has been added to the system. The control class is the center of the Check Out Asset use case. It will act as a dispatcher, transmitting messages to other classes that will perform the work of checking out an asset. The Check Out UI class sends a message to the Check Out Controller class. Notice that both messages are labeled with a sequence number. This numbering indicates the order in which messages are passed. The first message is sent from the librarian to the Check Out UI class, which responds by dispatching a message to the Check Out Controller class. 1: Select patron(patronid) 2: Select patron(patronid) : Librarian : Check Out UI : Check Out Controller Figure 10-2: Sequence numbers and parameter passing
Collaboration Diagrams 147 The message to the Check Out Controller class is to select a patron. In order to perform this action, the Check Out Controller class will need information about the patron being selected. The patron's identification number (which is scanned or entered from the library card) is passed as an argument to the Check Out Controller class. This notation is intentionally formatted to the syntax of most programming languages. In most cases, the messages sent between classes take the form of method calls. Return values Figure 10-3 expands on the preceding collaboration diagram. A third class, Patron Account, has been added and is an entity class. A third message, Get Account Balance, has been added between the Check Out Controller class and the Patron Account class. This message takes no arguments because, in the final system, this message will be sent to a specific instance of the Patron Account class. As noted previously, the Get Account Balance can be thought of as a message call. The diagram can capture the return value for use by the calling object. In this case, the return value is stored in a variable balance. 1: Select patron(patronid) 2: Select patron(patronid) : Librarian :CheckOutUI : Check Out Controller 3: balance := Get Account Balance : Patron Account Figure 10-3: Return value example
148 Chapter 10 Analysis Modeling Message conditions Figure 10-4 adds a second control class, the Pay Overdue Fine class. If the patron owes an overdue fine, that fine must be paid before any library assets can be checked out. Thus a condition is placed on message 4. The condition indicated by brackets indicates that the Pay Overdue Fine message will only be sent if the account balance is greater than zero, or balance > 0. 1: Select patron(patronid) 2: Select patron(patronid) 4: [balance > 0] Pay overdue fine : Librarian :CheckOutUI :CheckOut Controller : Pay Overdue Fine Controller 3: balance := Get Account Balance : Patron Account Figure 10-4: Message condition example
Collaboration Diagrams 149 Multiplicity Once a patron has been selected and any outstanding overdue fines have been paid, the librarian enters a cycle of adding assets to the list of assets to be checked out. This cycle continues until all the assets being checked out have been added to the list. Figure 10-5 adds the Asset List class and the messages required to add assets to the list. The asterisk next to message 5 indicates multiplicity; this message may be executed multiple times as assets continue to be added. 1: Select patron(patronid) 2: Select patron(patronid) 5*: Add asset(assetid) 6: Add asset(assetid) 4: [balance > 0] Pay overdue fine : Librarian :CheckOutUI :CheckOut Controller : Pay Overdue Fine Controller 7: Add asset(assetid) 3: balance := Get Account Balance :AssetList : Patron Account Figure 10-5: Multiplicity example
150 Chapter 10 Analysis Modeling Figure 10-6 is the complete collaboration diagram for the Check Out Asset use case. 1: Select patron(patronid) 2: Select patron(patronid) 5*: Add asset(assetid) 6: Add asset(assetid) 8: Complete transaction 9: Complete transaction 4: [balance > 0] Pay overdue fine : Librarian :CheckOutUI :CheckOut Controller : Pay Overdue Fine Controller 7: Add asset(assetid) 11: Mark assets as checked out 3: balance := Get Account Balance 10: Add assets to account :AssetList : Patron Account 12: Mark assets as checked out : Asset Database Figure 10-6: Check Out Asset collaboration diagram The collaboration diagrams created within the analysis workflow provide a rough overview of how each use case will be implemented. Using an expanded notation, collaboration diagrams can provide a more complete view of system design. Collaboration diagrams during the design phase will be revisited.
Flow of Events and Special Requirements 151 FLOW OF EVENTS AND SPECIAL REQUIREMENTS Collaboration diagrams efficiently express the relationship between the classes in a use case. However, it is difficult to fully comprehend the sequence of events. Collaboration diagrams employ sequence numbering to assist in deciphering the order of events, but tracing the path of messages can be time consuming. Analysts can employ two methods to better communicate the sequence of message passing within a collaboration diagram. One method is to create a second type of interaction diagram called a sequence diagram. It contains all the same information contained in a collaboration diagram, yet in a form that places greater emphasis on the sequence of events than on specific object relationships. Creating sequence diagrams will be discussed in a later chapter. A second method is to supplement the collaboration diagram with a textual description of the sequence of events called a flow-of-events description. The following is an example of a flow-of-events description for the Check Out Asset collaboration diagram: A librarian uses a bar code scanner or the keyboard to input a patron identification number (1). The user interface dispatches the patron identification number to the Check Out Controller (2). The Check Out Controller queries the Patron Account for the patron's account balance (3). If the balance > 0, control is transferred to the Pay Overdue Fine Controller (4). Once the patron's account balance is resolved, the librarian may begin entering asset identification numbers, using a bar code scanner or the keyboard. The asset identification number is dispatched from the Check Out UI to the Check Out Controller, which adds the asset to a list of assets being checked out. This process continues until all assets being checked out have been added to the list (5, 6, 7). When the librarian has completed the process of entering assets, he indicates to the Check Out UI that he wants to complete the transaction (8). This message is relayed to the Check Out Controller (9). The Check Out Controller adds the assets to the patron's account information and marks the assets as checked out (10, 11, 12). In addition to the flow-of-events description, each collaboration diagram may also be accompanied by a special-requirements description. The special-requirements description is a brief list of any non-functional requirements that should be considered.
152 Chapter 10 Analysis Modeling CLASS-RESPONSIBILITY-COLLABORATION CARDS Creating collaboration diagrams can be difficult, and the first design is rarely the final design. Class-Responsibility-Collaboration (CRC) cards are a tool used to simplify the analysis and design process. Analysts use index cards to represent each prospective class. Each card is labeled with the name of the class. A group of analysts and designers meet to discuss how the classes might interact, and a list of fundamental responsibilities is created for each class. These responsibilities are listed on the card. Next to each responsibility is the name of a second class with which the class must collaborate to fulfill the responsibility. Figure 10-7 illustrates a sample CRC card for the Check Out Controller class. Responsibilities are listed in the left column, and the collaborating classes are listed in the right column. Check Out Controller Allow user to pay overdue fine Check patron's account balance Add assets to patron's account Add assets to the list of assets being checked out Mark assets as checked out Pay Overdue Fine Controller Patron Account Asset List Figure 10-7: Example CRC card Rather than continually redrawing collaboration diagrams, CRC cards can be shuffled around a table as new scenarios are discussed. When analysts come to a consensus for a particular use-case realization analysis, they can begin translating the CRC cards into a collaboration diagram. The resulting diagrams are then re-evaluated, perhaps several times, until the team is satisfied with the design of the class interaction.
Class Analysis 153 CLASS ANALYSIS After completing collaboration diagrams, analysts take a closer look at individual analysis classes. CRC cards and collaboration diagrams provide information about the classes in a use-case realization analysis, their responsibilities, and the classes with which they collaborate. During class analysis, each class is analyzed more closely to identify class attributes, aggregations, and generalizations. Attributes Class attributes are properties of a class. In Chapter 2, class member variables were introduced. Think about member variables in terms of their data types. Within the analysis workflow, analysis classes are assigned properties. Unlike programmers, analysts are not concerned with specifics of implementation such as data type. Analysis class attributes can be defined in more general terms. For example, a book has an ISBN; the specifics of whether the ISBN will be stored as a string or as a set of integers can be addressed in design. Aggregation and generalization One type of analysis relationship, the association, has already been introduced. Collaboration diagrams depict associations between analysis classes. In Chapter 2, you were introduced to the "uses a" relationship. Associations are "uses a" relationships; the Check Out Controller uses a Patron Account. Two other relationships, the "has a" relationship and the "is a" relationship, were also introduced. These relationships translate to aggregation and generalization, which should be identified between classes as within the analysis workflow. Aggregation is the "has a" relationship. A patron's account information includes a list of assets currently checked out. Within the system, a patron's account and the list of assets are both represented by classes. The patron's account "has an" asset list. This relationship is called an aggregation because an asset list is part of a patron's account. In many ways, this relationship is identical to attributes.
154 Chapter 10 Analysis Modeling Generalization is the "is a" relationship. You will recall from Chapter 3 that the "is a" relationship denotes inheritance. A book "is a" lendable asset. In that way, a book inherits all the attributes and functionality of a lendable asset. WHEN IS THIS USEFUL Many ways of describing processes include collaboration, sequence, and activity diagrams. However, collaboration diagrams are most useful when providing information on the specific relationships between all the classes that will be used throughout a process. As shown above, relationships can be either very simple or extremely complex. A few disadvantages of the way collaboration diagrams work include a lack of a clear sequence of the process, or description of what happens when operations occur in parallel. Thus, collaboration diagrams should be used only when a description of the classes interacting is needed. When combined with the use of CRC cards, collaboration diagrams provide a easy and efficient way to test class interactions as well as providing a clear view of who will be involved with a process and how they will be involved.
Summary 155 Exercise 10-1: Creating analysis models In this exercise, you will conduct analysis modeling. Follow all the steps for each use case you identified for the grocery store inventory system. SUMMARY 1. Identify high-level classes and create CRC cards for each class. 2. Using the CRC cards you created in Step 1, consider how the various classes might interact. Determine responsibilities and collaborations for each class and write them on the CRC cards. 3. Create a collaboration diagram to depict the relationships between classes. 4. Create a flow-of-events description. 5. If any special requirements exist, consider creating a special-requirements description. 6. Identify attributes of the analysis classes you identified in Step 1. 7. Identify associations, aggregations, and generalizations of the analysis classes you identified in Step 1. Collaboration diagrams are a form of interaction diagram used to describe the interaction between classes in a use-case realization analysis. A second type of interaction diagram, called a sequence diagram, conveys the same information as a collaboration diagram, with an emphasis on the sequence of events. A flow-of-events description can accompany a collaboration diagram to better communicate the sequence of message passing. A specialrequirements description listing any nonfunctional requirements may also accompany a collaboration diagram. CRC cards are a tool used to simplify the analysis and design process.
156 Chapter 10 Analysis Modeling POST-TEST QUESTIONS The answers to these questions are in Appendix A at the end of this manual. 1. How are CRC cards used in analysis modeling? 2. What is the purpose of a flow-of-events description?