Lecture 6b

Objects in CRC Diagrams

Revision (Sequence Diagrams)
 Modelling Interaction among objects using
CRC cards
• An alternative for identifying interactions among objects are CRC cards.
• CRC cards (CRC stands for class, responsibilities, and collaborators) were
initially introduced as a tool for teaching object-oriented concepts.
• The name of the class is depicted on the top,
• its responsibilities in the left column,
• and the names of the classes it needs to accomplish its responsibilities are
depicted in the right column.
CRC Cards
• CRC cards can be used during modeling sessions with teams. Participants,
typically a mix of developers and application domain experts, go through a
scenario and identify the classes that are involved in realizing the scenario.
• One card per instance is put on the table. Responsibilities are then assigned to
each class as the scenario unfolds and participants negotiate the
responsibilities of each object.
• The collaborators column is filled as the dependencies with other cards are
identified.
 CRC cards v/s Sequence Diagrams
• CRC cards and sequence diagrams are two different representations for supporting
the same type of activity.
• Sequence diagrams are a better tool for a single modeler or for documenting a
sequence of interactions, because they are more precise and compact.
• CRC cards are a better tool for a group of developers refining and iterating over an
object structure during a brainstorming session, because they are easier to create
and to modify.
• sequence diagrams allow developers to represent interactions among objects over
time, class diagrams allow developers to describe the interdependencies of objects.
 Identifying Associations
• An association shows a relationship between two or more classes. For example, a
FieldOfficer writes an EmergencyReport (see Figure 5-13). Identifying associations has two
advantages. First, it clarifies the analysis model by making relationships between objects explicit
(e.g., an EmergencyReport can be created by a FieldOfficer or a Dispatcher). Second, it
enables the developer to discover boundary cases associated with links. Boundary cases are
exceptions that must be clarified in the model. For example, it is intuitive to assume that most
EmergencyReports are written by one FieldOfficer. However, should the system support
EmergencyReports written by more than one? Should the system allow for anonymous
EmergencyReports?
Eliminating redundant association. The receipt of an EmergencyReport triggers the creation
of an Incident by a Dispatcher. Given that the EmergencyReport has an association with the
FieldOfficer that wrote it, it is not necessary to keep an association between FieldOfficer and
Incident.
 Identifying Aggregation
• Aggregations are special types of associations denoting a whole–part relationship.
For example, a FireStation consists of a number of FireFighters, FireEngines,
Ambulances, and a LeadCar.
• There are two types of aggregation, composition and shared.
• A composition aggregation indicates that the existence of the parts depends on
the whole. For example, a County is always part of exactly one State,
• a shared aggregation relationship, indicating the whole and the part can exist
independently. For example, although a FireEngine is part of at most one
FireStation at the time, it can be reassigned to a different FireStation during its life
time.
Modelling Aggregation and Composition
 Identifying Attributes
• Attributes are properties of individual objects.

• Properties that are represented by objects are not attributes.

• In the case of entity objects, any property that must be stored by the system
is a candidate attribute.
 Modeling State-Dependent Behavior of
Individual Objects
• Lab Activity.
 Modelling Inheritance between Objects
• Generalization is used to eliminate redundancy from the analysis model. If two or
more classes share attributes or behavior, the similarities are consolidated into a
superclass.
• For example,
Dispatchers and FieldOfficers both have a badgeNumber attribute that serves to
identify them within a city. FieldOfficers and Dispatchers are both PoliceOfficers who
are assigned different functions.
• To model explicitly this similarity, we introduce an abstract PoliceOfficer class from
which the FieldOfficer and Dispatcher classes inherit
Modelling Inheritance
 Reviewing Analysis Model
• The analysis model is built incrementally and iteratively. The analysis model is
seldom correct or even complete on the first pass. Several iterations with the
client and the user are necessary before the analysis model converges toward a
correct specification usable by the developers for design and implementation.
• When is Analysis Model considered stable?
Once the number of changes to the model are minimal and the scope of the
changes localized, the analysis model becomes stable.
Because it is said
End of Lecture