Analysis: Class Identification

Section 0: Module Objectives or Competencies

Section 1: Overview

Different approaches have been suggested to aid the analyst in identifying a set of candidate classes for the structural model.

• Textual Analysis
• Brainstorming
• Patterns
• CRC Cards

Section 2: Textual Analysis

Note that while the textbook refers to this as "Object Identification", that name is inaccurate.

Although it was featured in an earlier set of notes, here again is the video on Finding Classes:

Textual analysis

The analyst performs textual analysis by reviewing the use case diagrams and examining the text in the use-case descriptions to identify potential classes, attributes, operations, and relationships.

• Nouns suggest classes.
• Verbs suggest operations.
• Creates a rough first cut to provide an object list.

Textual Analysis Guidelines

Example of Textual Analysis

Given the following use case description:

Textual analysis helps to identify potential classes for an old patient, doctor, appointment, patient, office, receptionist, name, address, patient information, payment, date, and time.

It also helps to identify potential operations that can be associated with the identified classes: patient contacts office, makes a new appointment, cancels an existing appointment, changes an existing appointment, matches requested appointment times and dates with requested times and dates, and finds current appointment.

Section 3: Brainstorming

Brainstorming is a group creativity technique by which efforts are made to find a solution for a specific problem by gathering a list of ideas spontaneously contributed by its participants.

• Participants are asked to identify the objects with which they have interacted.
• Initial list of classes (objects) is developed.
• Attributes, operations and relationships to other classes can be discussed in a second round.

Section 4: Patterns

A pattern is a useful group of collaborating classes that provide a solution to a commonly occurring problem.

• Developed patterns provide a starting point for work in similar domains.
• It is possible to put together commonly found object-oriented patterns to form elegant object-oriented information systems.
  • For example, many business transactions involve the same types of objects and interactions.
  • Virtually all transactions would require a transaction class, a transaction line item class, an item class, a location class, and a participant class.
  • By reusing these existing patterns of classes, we can more quickly and more completely define the system than if we start with a blank piece of paper.

Sample Patterns

Example with Patterns

The following image portrays a class diagram created by merging the patterns contained in the figure above into a single reusable pattern.

• In this case, we merged the Transaction–Entry–Account pattern (located at the bottom left of the Sample Patterns figure) with the Place–Transaction–Participant–Transaction Line Item–Item pattern (located at the top left of the Sample Patterns figure) on the common Transaction class.
• Next, we merged the Party–Person–Organization (located at the top right of Sample Patterns figure) by merging the Participant and Party classes.
• Finally, we extended the Item class by merging the Item class with the Product class of the Product–Good–Service pattern (located at the bottom right of Sample Patterns figure).

In this manner, using patterns from different sources in enables the development team to leverage knowledge beyond that of the immediate team members and allows the team to develop more complete and robust models of the problem domain.

Appointment may be considered to be a type of transaction in which a doctor’s office participates.

• By looking at an appointment as a type of transaction, we can apply the pattern we created in the example above and discover a set of previously unidentified objects, such as Place, Patient as a type of Participant, and Transaction Line Items that are associated with different types of Items (Goods and/or Services).
• Discovering these specific additional objects could be useful in developing the billing side of the appointment system.
• Even though these additional objects could be applicable, they may not be uncovered using other class identification techniques.

Useful Patterns

The following table lists some common business domains for which patterns have been developed and their source. These can serve as a useful starting point in identifying needed classes and their attributes, operations, and relationships.

Section 5: CRC Cards

Class-Responsibility-Collaboration cards are index cards used to document the responsibilities and collaborations of a class.

• Sometimes used instead of use cases and class diagrams.

Responsibilities

• Knowing—what a class must know manifested as attributes
  • a class typically knows the values of its attributes
• Doing—what a class must do manifested later as operations
  • a class can execute its operation

Collaboration

• Objects working together to service a request:
  • Requestor (client)
  • Responder (server)
• Bound by a contract

CRC Approach

• An exercise to help discover additional objects, attributes, relationships and operations.
• Team members perform roles associated with the actors and objects previously identified.
• Utilize activity diagrams to run through the steps in a scenario.
  • Identify an important use case.
  • Assign roles based on actors and objects.
  • Team members perform each step in the scenario.
  • Discover and fix problems until a successful conclusion is reached.
  • Repeat for remaining use cases.

Video Overview

Here is a video on using CRC cards:

Video Overview

Here is a video on Software Engineering Chapter 5 CRC Cards: