Object-oriented software design

Object-oriented software design

66.1 Purpose

This chapter describes object-oriented design. The purpose of object-oriented design is to transform the object-oriented analysis model into a design class diagram that specifies a software solution.

66.2 Strengths, weaknesses, and limitations

Object-oriented analysis and design is primarily use case driven. The major benefit of the use case approach is traceability. If there is a change in one use case, its ripple effect can be traced into the design. This lessens the impact and risk of changes to the project.

A weakness of use case-driven design is that the use cases may be considered in isolation and the global picture may be missed. Testing the solution across the different use cases helps to ensure that the global picture is not missed. In addition, a use case-driven design may be significantly affected by small changes in user requirements. This problem can be mitigated by selecting a good design architecture and designing for reuse.

Like use cases, object interaction diagrams are useful because they are intuitive and express well the dynamic interaction between objects. Using object interaction diagrams leads to a complete solution and brings to the surface issues that must be resolved at design time. However, like use cases, interaction diagrams depict only one scenario at a time, and a system can consist of hundreds of scenarios under different assumptions. To counter this problem, the designer should start with the interaction diagrams that have the greatest impact on system architecture or that perform key system functions.

Using design patterns means incorporating proven robust design decisions in a system design. Well-chosen and applied design patterns tend to provide clean designs, and patterns also enable designers to communicate their ideas effectively with each other. However, patterns can be misused, particularly if designers strive to force fit a pattern to a problem. Also, if only one designer in a team uses patterns, the result can be miscommunication. In addition, patterns are not a solution to designer incompetence. A designer must be well versed in the standard principles of system design.

66.3 Inputs and related ideas

Object-oriented concepts are covered in Chapter 6. Object-oriented analysis (Chapter 29) focuses on the domain objects and results in use cases and the development of a conceptual model using class diagrams (static modeling). Object-oriented design focuses on defining a solution based on classes. Object interaction diagrams capture the communicational aspect of the objects, but do not provide a convenient picture of its complete behavior.

State transition diagrams (Chapter 30) provide an overview of an object’s total behavior.

66.4 Concepts

This chapter concentrates on developing a logical object-oriented design. Logical design is free from implementation considerations and is portable across various interfaces, languages, and computers.

66.4.1 Boundary, control and entity objects

A widely used approach to object-oriented design is to separate the boundary (interface) and control objects from the entity (domain) objects.1 The main purpose is to develop maintainable systems. Entity objects are objects in the business domain. Boundary objects communicate with the user or with other systems.

Boundary objects are responsible for translating user input into a form that can be used by the system to process the business event and to translate the data from the entity object back to the user. Boundary objects make up the presentation dependent part of the system and isolate the behavior related to user and mechanical interfaces from the entity objects. This ensures that changes in the boundary objects are less likely to affect the core entity objects.

A control object performs use case-specific behavior and contains the application logic or business rules for managing the interaction among multiple entity objects. For example, in an appliance store inventory system,Store and BuyAppliance are possible control objects. Using control objects leads to a more robust and maintainable system.

Note that boundary, control, and entity objects equate well with the three-tier client server model. Presentation is the responsibility of the client (boundary object). Business logic is the second tier and is the responsibility of the control object. The data layer is the responsibility of the server (entity object).

Typically, one boundary object is allocated for each use case actor or major peripheral device. For example, in an appliance store, the sales representative uses a point-of-sale terminal to enter the details of a sale and a card reader to read the customer’s credit card number. Aggregation can sometimes be used for interface objects; for example, a point-of-sale terminal consists of a display unit and a printer (for printing the receipt and the credit card statement). Once the boundary object has been identified, the attributes and operations for that object must be identified. Operations that present information to the external system or request information from external systems (such as requesting credit card approval from a central bank or approval station) are allocated to the boundary object.

Control objects often act as buffers between boundary and entity objects. Initially, define one control object for each use case. After the appropriate responsibilities have been assigned to each entity or boundary object, any remaining behaviors are assigned to the control object. The types of behaviors typically allocated to control objects include behaviors that are unchanged if the surrounding objects change, behaviors that affect multiple entity objects, and state dependent or control logic for a use case. Since control objects are typically used to carry methods that do not fit elsewhere, they generally do not have many attributes.

66.4.2 Identifying operations

An operation provides a service. Whenever a service exists, the object has a responsibility to provide that service to other objects that request it. A method is the implementation of an operation for a specific object class.

66.4.2.1 The CRC technique

One way to find operations is to use the Class, Responsibilities, and Collaborations (CRC) technique.2 In CRC, a class is a generic specification for an arbitrary number of similar objects. Responsibilities include the knowledge (data) an object maintains and the actions (services) an object can perform. Whenever a service or data is provided by one object to another, there is a client-server relationship. The client object requests a service from the server object, which performs the service or returns data. A given object can be a client at times and a server at other times.

A collaboration is the embodiment of a contract between a client and a server and takes place when a class has a responsibility it cannot fulfill alone and thus requests the necessary service from a server. The pattern of collaboration within the application reveals the flow of information and control during execution. These collaborations represent interaction paths or communication between classes.

To identify responsibilities, start with a class’s responsibility and determine if it can fulfill the responsibility itself or must collaborate with another class to acquire what it needs. If collaboration is necessary, start with the class and trace the flow of collaborations until the responsibility is completely fulfilled. Similarly for each class, ask what the class does or knows and identify the other classes that need the result or information. If a class has no interactions with other classes, discard it.

Like use cases, CRC is a responsibility driven technique. Start by identifying the classes, responsibilities, and collaborations that are necessary to support each use case. For each new class, write the class name (singular nouns) on an index card (Figure 66.1). Then partition the index card, writing the responsibilities of the class on the left side and the collaborating classes required to fulfill the responsibility (the servers) on the right side.

The CRC development process is interactive among the analysts and designers. Each individual is assigned a set of index cards and is asked to think like the object he or she is assigned. The individual then acts out the roles the class fulfills when applied to different use cases. The information on the index card is kept to a minimum. Quick iterations encourage searching for classes and the interactions between classes. This is a cheap and highly object-oriented way of identifying the classes and their interactions. It is particularly suited for brainstorming.

Figure 66.1 Two CRC cards.

An application of this technique to the use case provided in Table 66.1 (a copy of Table 29.2) may yield (among others) the classes SalesInvoice and SalesLineItem (Figure 66.1). For the SalesInvoice class, the operations are PrintSale and CalculateTotal, and for SalesLineItem the operations are CalculateExtendedPrice andPrintLineItem.

Table 66.1 An Expanded Level Use Case

Use case
Buy Appliance

Actors Purpose Description
Customer (initiator), Sales Representative Record the sale of an appliance to a customer A customer, talks to a sales representative about appliances that he/she is interested in buying, and picks the item in consultation with the sales representative. The sales representative then prepares the bill, and the customer makes the payment.

Type
Primary

Normal Course
1. Customer walks up to a sales representative and discusses items to buy.
2. In consultation, customer decides on item to buy.
3. Sales representative enters the appliance identifier and the quantity desired into the system.
4. System responds with the price, and verifies that the appliance is in stock. (Not in stock is not a normal course of events.)
5. If additional items are to be entered, sales representative does so, and steps 3 and 4 are repeated.
6. System adds the amounts, calculates tax, and presents the total.
7. Sales representative informs the customer of the total.
^*Assumption: The normal event is a credit card purchase. Cash purchases are described separately.^*
8. Customer runs his/her credit card through the verification system.
9. System receives credit approval, and presents credit card transaction form.
10. Customer signs the credit card transaction form.
11. System logs the details of the transaction, including sales representative, customer, and item information.
12. System updates the inventory and closes the transaction.
13. System generates the receipt.
14. Receipt is handed by sales representative to customer.
15. Customer leaves the premises with appliance. Alternative courses: Note errors that can occur and how they are handled can be described here.

66.4.2.2 Use case object interactions

A second technique used to identify operations is to look at the object interaction required to support each use case scenario and to prepare an object interaction diagram for each use case. Typically, the developer starts with a normal scenario and then expands the interaction to include alternative courses of events.

From the conceptual model (Chapter 29) for the domain objects, identify the domain objects used in the use case and the control and interface objects (Section 29.4.1) applicable to the use case. Then consider the object interactions required to provide the functionality in each use case by viewing the system as a black box and, for each actor, identifying the events the actor generates in the use case. These object interactions are events, and each use case is started by an event.

For example, the use case description in Table 66.1 suggests that the salesperson generates eventsenterSalesItem, enterPayment, and endSale, and the customer generates the event scanCard. Also, it is reasonable to assume that the sales representative interacts with the boundary object point-of sale terminal and the customer interacts with the boundary object card reader.

For each initial external event, identify the internal events needed to communicate between the objects that support the normal sequence in the use case. Internal events are messages sent from one object to another in order to invoke the operation. For example, the SalesInvoice object would raise a calculateExtendedPrice on the SalesLineItem object.

For each event, identify the operations, the required parameters, the preconditions, and the post conditions. A parameter is information that must be passed so the receiving object can perform the operation. The type of parameters (mandatory or optional) and the possible range of values must be identified. For example, theenterSalesItem operation’s parameters would include the UPC number and the quantity required. Both parameters are mandatory.

Post conditions include objects that were created, associations that were formed or broken, and any attributes that were modified during an operation. Preconditions include objects that must exist for an event to take place. The enterSalesItem operation’s post conditions would include the SalesLineItem that was created, theSalesLineItem that was associated with the SalesInvoice, the SalesLineItem that was associated with aProductSpecification based on the match on UPC code, the SalesLineItem quantity that was set to the quantity required (attribute modification), the SalesLineItem that was associated with the Inventory based on a match on UPC code, and the reduced quantity on hand (by the quantity purchased). The precondition is that the UPC code must exist in ProductSpecification.

66.4.3 Object interaction diagrams

Once the operations are identified, an object interaction diagram is drawn. Object interaction is concerned with identifying how objects work within the system to satisfy the requirements. Interaction diagrams represent objects and show how they communicate with each other in an interaction.

66.4.3.1 Collaboration diagrams

In a collaboration diagram, objects are represented as rectangles with links between objects that interact. Links are instances of associations that are present in the conceptual model. Arrows represent messages, and are labeled with their names and arguments. The message function being sent must exist as an operation (method) of the receiving object. The order of the messages is shown in by a number placed at the head of the the message.

For example, Figure 66.2 shows the representation of a simple collaboration diagram. An object instance A sends a message (M1) to the object instance B. Subsequently, B sends a message (M2) to itself (representing an activity within itself). Finally, B sends a message M3 to object instance C. The colon (inside the box) represents an anonymous object of the specified type (e.g., Faculty as opposed to Rajkumar). An object is an instance of a class, and underlining differentiates an object from a class. For example, :A indicates a generic class and :Aindicates a generic object.

Figure 66.2 The UML notation for a collaboration diagram.

Figure 66.3 The UML notation for a sequence diagram.

66.4.3.2 Sequence diagrams

Figure 66.3 shows an equivalent sequence diagram. Note that the message time line is explicitly represented. A vertical bar represents each object and time elapses from top to bottom, so numbering the messages is optional. Both collaboration diagrams and sequence diagrams show the same information; the choice is a matter of preference.

66.4.3.3 Drawing interaction diagrams

Collaboration (or sequence) diagrams should be drawn for each interaction in the use case. The diagrams for each of the interactions are subsequently merged to create a single collaboration diagram.

For example, Figure 66.4 is a collaboration diagram for enterSalesItem. The boundary object is the POSTobject, and other interacting domain objects include SalesInvoice, SalesLineItem, ProductSpecification, andInventory. The POST boundary object is used by the salesperson to interact with the system and to enter the sale information. The post conditions specify that enterSalesItem, is sent to a SalesInvoice object, which creates a SalesLineItem. The SalesLineItem matches the product specification to retrieve the product information, and also reduces the inventory by the quantity purchased.

Before an object can send a message to another object, it must be visible to the object. (In other words, it must be able to see or have a reference to the other object.) Figure 66.4 assumes that the SalesInvoice has already been created (and thus is visible) and shows the messages for any additional items purchased. To enable visibility (Figure 66.5), show the creation of the SalesInvoice itself via a second message (2.1: createSalesInvoice) that is sent to the SalesInvoice object and by modifying the existing message 2 to 2.2: enterSalesItem.

Figure 66.4 A collaboration diagram forenterSalesItem interaction.

Figure 66.5 A modified collaboration diagram that resolves visibility conditions for enterSalesIteminteraction.

Similarly, Figure 66.5 assumes that the ProductSpecification and Inventory objects have been created by some other initial process. A complete collaboration diagram would establish the visibility of all objects.

66.4.4 Design patterns

Design patterns codify the solutions expert designers use to solve commonly recurring object-oriented design problems and provide guidelines on how to customize the solution. In its simplest sense a pattern describes a problem and (at an abstract level) a solution. Since the solution is a template, using a pattern means tailoring and adapting the solution to the unique needs of the problem. Patterns provide a solution to a problem, are applicable in a variety of domains, are a literary form designed to convey proven solutions based on the wisdom of expert designers, and enable skilled designers to effectively communicate design decisions.

For example, Larman³ identifies five patterns for assigning responsibilities to classes. The expert pattern suggests that responsibility should be assigned to the class that contains the necessary information. The creator class suggests that the responsibility for creating an instance of A be assigned to the class that contains, has the initializing data for, uses, aggregates, or records A. The controller pattern suggests that a responsibility be assigned to the class responsible for handling a related system event. As the names imply, the objective of the low coupling pattern is to keep coupling low, and the objective of the high cohesion pattern is to keep cohesion high.

These patterns can be used to verify the responsibilities of the object in the collaboration diagram. For example, consider Figure 66.5. Should the POST object or some other object create a SalesInvoice? The creator pattern states that the object that uses or records the other object is a good choice. Because the POST object records a sales invoice, POST is the right object to create the SalesInvoice instance, and the choice shown in the collaboration diagram is a good one.

The next step might be to evaluate the design and check how the ProductSpecification object is created, because it must be visible for the collaboration diagram to work. Using the creator pattern and the controller pattern, it becomes clear that a Store object is necessary to create this object. In addition, if the POST object is viewed as one instance of a point-of-sale terminal, the Store object must create the POST object. Taking these modifications into account results in the collaboration diagram shown in Figure 66.6.

In a similar fashion collaboration diagrams should be drawn for each use case and the design refined using the patterns. These steps lead to a robust, and maintainable logical design.

Figure 66.6 A modified collaboration diagram that reflects the application of design patterns forenterSalesItem interaction.

66.4.5 Design class diagrams

Design class diagrams specify the software classes and interfaces in an application.³ In general, they include classes, attributes, their operations or methods, and the associations between the classes. Note that the design class diagram represents software entities rather than the conceptual model’s conceptual entities.

A design class diagram is drawn by first identifying all the software classes from the interactions (the collaboration diagrams) that participate in the solution. Start with the conceptual model (Figure 66.7, from Chapter 29, Section 29.4.3). Add the attributes to the objects that are similar to the conceptual model. Add the method names by analyzing the interaction diagram. Add associations represented in the conceptual model and shown as links in the collaboration diagrams. Add any other association necessary to maintain visibility. A design class diagram for the appliance store is shown in Figure 66.8; note both the similarities to and the differences from the conceptual model.

Once a design class diagram has been drawn, it must be documented with all information that an implementation team would require to implement the system.

Figure 66.7 The conceptual model (from Chapter 29, Section 29.4.3).

66.5 Key terms

Actor —: A person or entity external to the system.
Association —: A relationship between objects that indicates some meaningful and interesting connection.
Boundary object (interface object) —: An object that communicates with the user or with other systems.
Class (object type) —: A group of similar objects.
Class, responsibilities, and collaborations (CRC) technique —: A technique for identifying operations.
Collaboration —: The embodiment of a contract between a client and a server; the interaction that takes place when a class has a responsibility it cannot fulfill alone and thus requests the necessary service from a server.
Collaboration diagram —: A diagram that shows the basic message flow between objects and implies the associations between them.
Control object —: An object that performs use case-specific behavior and contains the application logic or business rules for managing the interaction among multiple entity objects.
Design class diagram —: A diagram that specifies the software classes and interfaces in an application.
Entity object (domain object) —: An object in the business domain.
Event —: An occurrence that generates a signal.
Method —: The implementation of an operation for a specific object class.

Figure 66.8 A design class diagram.

Object —: A thing about which data are stored and manipulated.
Object interaction diagram —: A graphical depiction of the way objects interact and collaborate to realize a use case.
Object-oriented analysis —: The investigation of a problem by identifying and describing the objects.
Object-oriented design —: The logical solution of a problem through a set of interacting objects.
Object type (class) —: A group of similar objects.
Operation —: A service provided by an object.
Parameter —: Information that must be passed so the receiving object can perform the operation.
Pattern —: A named problem/solution pair that can be applied in new contexts, along with advice on how to apply it.
Post conditions —: Objects that were created, associations that were formed or broken, and any attributes that were modified during an operation.
Preconditions —: Objects that must exist for an event to take place.
Responsibility —: A contract or obligation of a type or class, including both responsibilities of knowing and responsibilities of doing.
Sequence diagram —: A type of interaction diagram, drawn using the UML notation, that depicts the interaction between objects and shows the detailed message flow between objects in a use case; the time axis is directed downwards and the objects are represented in a vertical column.
Signal —: A message that allows objects to interact with other objects.
Unified modeling language (UML) —: The universal language for object-oriented modeling; its notation forms an object-oriented modeling language and can replace the notation of various object-oriented analysis methods.
Use case —: The behaviorally related sequence of transactions that a user performs in a dialogue with the system when he or she uses the system.
Use case diagram —: A diagram that depicts the set of use cases for a system, the actors, and the relation between the actors and the use cases.
Visibility —: An object has visibility to a second object if it has a reference to the second object.

66.6 Software

CASE (Chapter 5) tools exist to help the designer develop CRC cards, collaboration diagrams, sequence diagrams, and design class diagrams.

66.7 References

66.7.1 Citations

1. Jacobson, I., Christerson, M., Jonsson, P., and Overgaard, G., Object Oriented Software Engineering: A Use Case Driven Approach, ACM Press, Reading, MA, 1992.

2. Wirfs-Brock, R., Wilkerson, B., and Weiner, L., Designing Object Oriented Software, Prentice-Hall, Englewood Cliffs, NJ, 1990.

3. Larman, C., Applying UML and Patterns: An Introduction to Object Oriented Analysis and Design, Prentice-Hall, Upper Saddle River, NJ, 1997.

66.7.2 Suggestions for additional reading

1. Booch, G., Object Oriented Design with Applications, Benjamin/Cummings, Redwood City, CA, 1991.

2. Fowler, M., Analysis Patterns: Reusable Object Models, Addison-Wesley, Reading, MA, 1997.

3. Gamma, E., Helm, R., Johnson, R., and Vlissides, J., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Reading, MA, 1994.

4. IBM Object Oriented Technology Center, Developing Object Oriented Software: An Experience-Based Approach, Prentice-Hall, Upper Saddle River, NJ, 1997.

5. Muller, P.-A., Instant UML, Wrox Press, Olton, Canada, 1997.

6. Priestley, M., Practical Object Oriented Design, McGraw-Hill, London, 1996.

7. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorenson, W., Object Oriented Modeling and Design, Prentice-Hall, Englewood Cliffs, NJ, 1991.

8. UML 1.1 Specification (Rational Software): http://www.rational.com/uml/.

9. Yourdon, E., Whitehead, K., Thomann, J., Oppel, K., and Nevermann, P., Mainstream Objects: An Analysis and Design Approach for Business, Yourdon Press, Upper Saddle River, NJ, 1995.

Search This Blog

information systems course