Object-oriented methods

Object-oriented methods

29.1 Purpose

This chapter describes object-oriented analysis. The purpose of object-oriented analysis is to find and describe the business objects and to identify the relationships between the objects via a conceptual model.

29.2 Strengths, weaknesses, and limitations

Presently, the dominant mode of analysis and design is the structured analysis and design technique. Despite its dominance, this approach has limitations in that it is not able to deliver robust systems on time or within budget and is often not able to meet the complete needs of new client/server and distributed systems. Increasingly, the industry is looking to object-oriented analysis and design.

The architectures of object-oriented systems consist of networks of interconnected subsystems, with each subsystem encapsulating data and providing methods. Because the subsystems reflect natural classifications, they tend to be independent and stable. The subsystems communicate via messages and object-oriented analysis and design encourages platform independent designs, leading to more reliable distributed systems.

Developer productivity is enhanced because objects and code can be reused. Developers have a library of reusable classes and can create specialized subclasses from them by using inheritance. This reduces coding and maintenance costs because the library of classes has been debugged prior to inclusion in the system.

Object-oriented analysis and design leads to quicker development because of the increased use of prototyping. Prototyping and reuse go together because it is easier to prototype if there is a library of reusable classes.

In addition, there is a closer association between the real world object and the system object. Business users tend to see the world in terms of objects, so a program developed to reflect those objects is easier to communicate to the user. The object models lead to a more natural representation because data and programs are stored together. In addition, a hierarchical model structure is possible, with each layer showing greater levels of detail. All these lead to object models that are easier to understand and use.

Programmer training is a problem. Most practicing programmers were trained on structured programming techniques and on languages such as COBOL. Writing object-oriented programs or designing object-oriented systems requires learning new languages and new ways to conceptualize logic. This is a challenge.

Reuse is also difficult to achieve. Significant management, cultural, and organizational issues must be tackled prior to achieving reuse. Management commitment must be obtained before object technology provides any benefits. In addition, a sizeable number of employees must be trained in object-oriented techniques and technologies. Control issues also need to be handled such as: Should everyone be forced to use the standard version? Should adaptations be allowed? Who decides? Should designs, specifications, and architectures also be reused? Akin to the capability maturity model, reuse maturity models exist that can guide organizations in their implementations of the reuse process.

While objects are easier to communicate with users, it is naive to expect that system objects that mirror real world objects will result in software that is easily maintainable, reusable and makes efficient use of resources.1 A study of design patterns and modifying the system design to effectively utilize true and tried methods in object-oriented design would, in general, improve the quality of software that is developed, however.

In addition, the message passing mechanism used for communication between objects does not always accurately reflect the way events occur in the real world. For example, when two cars bump into each other, it cannot be assumed that one car sent a bump ( ) message. Instead, an event has taken place in which each car is a reluctant participant. Because of this, object-oriented analysis and design approaches introduce messages late in the design process.

29.3 Inputs and related ideas

Structured analysis and design pictures a software system as a collection of data that are processed by functions (processes) external to the data. Analysts and designers use data flow diagrams (Chapter 24), data dictionaries (Chapter 25), and structure charts (Chapter 63) to develop systems. Entity relationship diagrams (Chapter 26) stress the data and show how a system’s primary data entities are related. These tools are appropriate for data-rich systems (for example, systems that incorporate relational databases).

An object is a concept or thing about which information is stored. An object consists of a set of related methods and attributes. Object-oriented concepts are covered in Chapter 6. Object-oriented design is covered in Chapter 66.

29.4 Concepts

In general, divide and conquer is the strategy used to deal with software project complexity in both structured analysis and design and object-oriented analysis and design (OOAD). In structured analysis and design, the decomposition is performed via function or process, resulting in a hierarchical breakdown of processes made up of other subprocesses. In OOAD, the decomposition is by objects rather than by processes or functions. OOAD emphasizes considering the problem and its logical solution from the perspective of objects (things, concepts, entities).

The object-oriented life cycle can be broadly thought of as including analysis, design, and a construction phase. Analysis is the investigation of a problem rather than a solution. Design emphasizes a logical solution and the design of a system that fulfills the requirements. Construction is developing code, debugging, and testing the application.

In object-oriented analysis, the analyst finds and describes the objects. For example, if we consider a student registration system at an university or college, some objects of interest would be students, courses, and faculty. During the design phase, the analyst defines software objects that ultimately will be implemented in an object-oriented language. These objects have properties (attributes) and methods. For example, a course may have number, title, time, instructor and a print class rollsmethod. During construction the design objects are implemented in an object-oriented language such as C++, Java, or Visual Basic.

During the object-oriented analysis stage, the analyst defines the problem statement (the requirements), defines use cases both at a high level and an expanded level, develops a conceptual model, and records the terms in a glossary.

29.4.1 Requirements

Requirements are used to specify the overall goals, system functions, and attributes. For example, imagine that the goals for an appliance store inventory system are to reduce inventory by providing accurate, daily inventory status data to support reorder and sale item decisions and to maintain the new inventory levels into the future.

System functions identify what the system is supposed to do. Some system functions implied by the inventory system goals include recording all transactions, maintaining inventory of all items in some persistent storage, reporting items to reorder, updating inventory when items are received, and identifying items with excess stock.

System attributes are non-functional qualities such as operating system and platform, response time, and interface (windows, GUI, etc.). Requirements also include evaluating project feasibility (Chapter 13), recording a list of key contacts, and documenting any constraints (such as the maximum cost of the project).

29.4.2 Use case modeling

Use case modeling is a technique used to identify and define the business objects. The objectives of use case modeling include identifying user requirements in a manner that can be clearly communicated to the user and developers, enabling the finding of objects in the real world, enabling the discovery of properties and methods for each object, and establishing a basis for developing a test plan and user manuals.

A use case corresponds to a specific kind of system use. Use cases describe the behavior of a system from a user’s point of view. A use case begins with an actor (a person or entity external to the system) initiating some business task. The system responds with a dialogue to which the user responds and so on. The use case describes this sequence of events. Use cases are not functional requirements per se but imply the requirements. Use case modeling breaks down the entire scope of system functionalities by specifying all the relevant ways of using the system.

29.4.2.1 High level use case

High-level use cases tersely describe the functionality required and are useful to obtain a quick understanding of the overall processes in the system. Table 29.1 describes a typical high level use case. It contains a title, the actors involved in the use case (including the one who initiates), a brief description of the case, and whether the use case represents a fairly important (primary) business process or is of secondary importance.

29.4.2.2 Expanded use case

Expanded use cases are used to obtain an in-depth understanding of the processes and requirements. In an expanded use case, in addition to the high-level description, the purpose, and a typical or normal sequence of actions are recorded. For example, Table 29.2 is an expanded description for the high-level use case in Table 29.1.

Alternative courses (a cash payment, a disapproved credit card transaction) are generally not included in the use case because the objective is understanding the basic requirements, not the details. It is easier to read the standard use case without being distracted by unusual cases, and the developer should focus more on the most common case. The alternate courses are delineated and described later.

An assumptions section can also be added to the use case to deal with important issues such as security and performance that do not fit the use case scenario. For example, assumptions might state that no manufacturer’s rebate coupons will be accepted, or no security or password is required for the sales representative to enter the information into the system.

Normal course of events

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.^*

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.

---

---

^*Assumption: the normal event is a credit card purchase. Cash purchases are described separately.

---

29.4.2.3 Identifying use cases

One method for identifying use cases is to start by identifying the actors and then identifying the business processes each actor initiates or participates in. Actors are generally external to the system, so the system context diagram (Chapter 24) may be a good place to start. Defining everything each actor is able to do enables the analyst to document the complete functionality of the system. Jacobson² recommends that the analyst consider:

1.  The main tasks of the actor,

2.  The type of access to system information (read or update) the actor requires,

3.  The information about changes in the world outside the system the actor is to send to the system,

4.  The information the system is to send to the actor about changes of which the system is aware.

Note that the use cases should describe real processes (such as processing a sale) and not trivial events (such as printing the receipt for the customer). In this example, the real process is the sale.

29.4.2.4 Use case diagrams

Use case diagrams depict:

1.  A set of use cases for a system,

2.  The actors,

3.  The relations between the actors and the use cases.

The purpose of the use case diagram is to present a context diagram. By understanding the use case diagram, one can understand the actors external to the system and the many ways in which the system is used by the actors. In the unified modeling language (UML) notation,³ ovals represent use cases and stick figures represent actors. For example, Figure 29.1 shows a sample use case diagram for the appliance store.

29.4.2.5 Developing use cases

Use cases can be categorized as primary and secondary. Primary use cases depict processes commonly seen in the business. Secondary use cases depict processes used less often (such as deciding to order a new category of appliance).

Use cases are typically ranked using some sort of priority. For example, the analyst might give priority to use cases that represent the primary functions of the business, those that impact the design, those that enable easy identification of objects, those that impact the architecture of the system (database requirements, network requirements), those that implement complex functions, and so on.

Once they are ranked, the more critical use cases are developed iteratively using a time boxed approach. For example, the Buy appliance use case may first be written with just the typical course of events. In the second iteration, the use case may be developed for handling credit refusals and cash payments. In the third iteration, handling check payments may be added to the use case, and so on. Each assumption or simplification of the scenario must be noted in the use case model at each stage.

Figure 29.1  A use case diagram for an appliance store.

Use cases are not object oriented. The objective is to create a first-cut model from a business process or system perspective. The completed use case diagram gives the analyst a view of the system and provides the tools to identify the objects and build a conceptual model.

29.4.3 The conceptual model

In the conceptual model, the real world concepts (i.e., the objects) are explicitly identified, their attributes are documented, and the associations among the objects are specified. Creating a conceptual model is the most important object-oriented analysis activity.

In the unified modeling language, conceptual models are shown using static diagrams. Static diagrams describe the different kinds of objects that can exist in the system and the possible ways in which the objects can be linked to each other. Typically, no methods or responsibilities are shown, as static models do not contain information about how a system behaves. The most important type of static diagram is the class-structure diagram. The class-structure diagram defines the groups or classes the objects fall into and defines the structural relationships between the groups.

It should be emphasized that during the analysis phase, the conceptual model represents the real-world entities, not the software components. It shows information on objects (concepts) in the application, how the objects are associated with each other, and the attributes of each object.Figure 29.2 shows the UML notation for an object.

Figure 29.2  Object representation in UML.

29.4.3.1 Identifying objects

Objects are identified by extracting nouns (candidate classes/objects) from a problem statement or from the expanded use case. A few of these noun phrases may be candidate concepts; others may be attributes.

For example, the use case statements for an inventory application might suggest such concepts (objects) as customer, sales representative, appliance item, stock, payment, credit card, verification system, inventory, price, quantity, total, transaction, receipt, and so on. A similar analysis is done for all use cases, and a candidate list of objects is drawn up. Once this is done, the candidate list is cleaned up by looking for synonyms (inventory and stock), concepts outside the scope of the system (the verification system), nouns that are attributes (price), and so on. The reasons for keeping some nouns and removing others from the list must be documented.

Once the key objects are identified, the next step is to group them to form object classes. Certain objects, for example, objects that share attributes, seem to naturally fit together. For example, the object appliance item clearly belongs to a more general concept called inventory, and the data associated with a receipt have a great deal in common with a sale.

29.4.3.2 Identifying associations

An association is a relationship between concepts that indicates some meaningful and interesting connection. Much as objects correspond to nouns, associations correspond to verbs.

For each association, the analyst must decide if the association is useful by checking if information about the association must be stored. For example, consider the association between the sales representative and the actual sale. If the store pays its sales representatives on a commission basis, then the system must keep track of this association. However, if the appliance store pays its sales representatives an hourly wage, the association may not be needed. All necessary associations are assigned a name that clearly reflects the purpose of the association.

Once the association (relationship) has been identified, the multiplicity that governs the relationship must also be defined. Multiplicity defines the minimum and maximum number of occurrences of one conceptual object for a single occurrence of the other; the concept is similar to cardinality (Chapter 26.) Since associations are bidirectional, multiplicity must be defined in both directions for the association.

An example of an association and its multiplicities is shown in Figure 29.3. The association iscustomer purchases from inventory. The relationship is many to many because a customer is associated with (may purchase) many items in inventory and a given item in inventory may be purchased by many different customers. Figure 29.4 summarizes several unified modeling language multiplicity notations.

Figure 29.3  Association in UML.

Figure 29.4  Representing multiplicity in UML.

Two objects can have more than one association. When several associations exist between two objects, then role names specified on either side of the association are used to clarify the relationship. Role names are typically nouns. For example, in Figure 29.5, the graduate student has two roles, one as a student taking a course from the faculty member and the second as a research assistant working for the faculty member.

29.4.3.3 Aggregation

An aggregation association depicts a complex object that is composed of other objects. In general it models a whole-part relationship between objects. An aggregation is used to express “part-of” associations between objects. For example, a sale is composed of multiple sales line items, so a sale can be modeled as an aggregation of sales line items. Figure 29.6 (top) depicts this aggregation which is actually a composition. A composition is a stronger form of aggregation, with the multiplicity at the composite end being at most one (signified by a filled diamond).

A hollow diamond indicates a shared aggregation, and the composite end may be more than one. For example, the second association in Figure 29.6 depicts an asymmetrical relationship where the parent takes care of the children as a shared aggregation. An asymmetrical relationship is one in which one end plays a more significant role. Here, the parent object plays a more significant role than the children. Note that a child can have at most two (0 . . . 2) parents.

Figure 29.5  Roles in UML.

Figure 29.6  Composition and shared aggregation.

Booch⁴ suggests the following tests to determine whether a relationship is an aggregation:

1.  Is a part-of phrase used to describe it?

2.  Are some operations of the whole applied automatically to the parts?

3.  Are some attribute values propagated from the whole to the parts?

4.  Is one object class subordinate to the other?

29.4.3.4 Generalization and specialization

Class hierarchies enable us to manage complexity by ordering objects within trees of classes with increasing levels of abstraction. Generalization and specialization are points of view that are based on class hierarchies. Generalization consists of factoring out the common elements (attributes and methods) from a set of classes into a more general class called a parent class. The most general level is at the top, with the more specific object types shown as children. The parent’s attributes and methods are then inherited by the children. Generalization and specialization hierarchies describe systems that should be implemented using inheritance in an object-oriented language.

Figure 29.7 depicts a common occurrence of a generalization/specialization in the real world. An employee can be either a salaried worker or an hourly worker. A salaried worker may be a manager or a non-manager. In the appliance sales example, payment has a hierarchy with sub-types credit payment and cash payment.

Figure 29.7  Generalization/specialization.

Figure 29.8  A conceptual model for the appliance inventory system.

A conceptual model for the appliance store inventory project that integrates the various objects is shown in Figure 29.8.

29.4.4 Glossary

A glossary is a document that defines terms. Conceptually, it resembles a data dictionary (Chapter 25). The glossary lists and defines all the terms that must be clarified. The objective is to reduce misinterpretation of the terms by various analysts and to enhance communication by providing consistent meanings for the various terms.

29.5 Key terms

Actor —

A person or entity external to the system.

Aggregation —

A description of part-of relationships among objects; the higher-level objects are completely described by all of their components.

Association —

A relationship between objects that indicates some meaningful and interesting connection.

Capability maturity model —

A comprehensive framework for describing and evaluating the software development capability of an organization.

Class structure diagram —

A diagram that defines the groups or classes the objects fall into and defines the structural relationships between the groups.

Composition —

A stronger form of aggregation, with the multiplicity at the composite end being at most one.

Concept —

An object.

Conceptual model —

A model in which the real-world concepts (i.e., the objects) are explicitly identified, their attributes are documented, and the associations among the objects are specified.

Expanded use case —

A description of the step-by-step events in a process; an expanded use case is more detailed than a high-level use case.

Generalization —

A technique wherein commonality among concepts is identified and a general concept or super-type is defined. Subtypes depict “type-of” relationships.

High-level use case —

A brief, two, or three sentence description of a process.

Multiplicity —

The minimum and maximum number of occurrences of one conceptual object for a single occurrence.

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.

Reuse maturity model

A comprehensive model that measures the extent of reuse of software components, architecture, and processes in an organization.

Specialization —

The creation of a subtype from a super-type by refining the super-type; the opposite of generalization.

Static diagram —

A model that describes the different kinds of objects that can exist in the system and the possible ways in which the objects can be linked to each other; no methods or responsibilities are shown because static models do not contain information about how a system behaves.

Timed box approach —

A project management approach that divides the set of all requirements for a system into subsets, each of which is implemented as a version of the system; the delivery of each new version of the system in a regular and timely fashion is guaranteed by this approach.

Unified modeling language —

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.

29.6 Software

CASE (Chapter 5) tools exist to help the analyst develop use cases, draw class diagrams and enter terms in a data dictionary.

29.7 References

29.7.1 Citations

1.  Priestley, M., Practical Object Oriented Design, McGraw-Hill, London, 1997.

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

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

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

29.7.2 Suggestions for additional reading

1.  Brown, D., An Introduction to Object Oriented Analysis: Objects in Plain English,John Wiley & Sons, New York, 1997.

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

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

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

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

6.  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.