Chapter 7: Classes and ObjectsChapter 8: Finding Analysis Classes

[Arlow and Neustadt, 2005]

CS 426 Senior Projects in Computer Science

University of Nevada, RenoDepartment of Computer Science & Engineering

2 / 15

Outline

Objects UML Notation for Objects Classes UML Notation for Classes UP Activity: Analyze Use Cases Analysis Classes Finding Analysis Classes

3 / 15

Objects

Object = “A discrete entity with well-defined boundary that encapsulates state and behavior, an instance of a class” [J. Rumbaugh]

Properties of objects: Identity State Behavior

4

Objects: Encapsulation

Fig. 7.2 [Arlow & Neustadt, 2005]

5

Objects: Messaging

Figure 7.3 [Arlow & Neustadt, 2005]

6

Objects: UML Notation Figure 7.4 [Arlow & Neustadt, 2005]

7 / 15

Classes

Class = “The descriptor for a set of objects that share the same attributes, operations, methods, relationships, and behavior” [J. Rumbaugh]

Every object is an instance of exactly one class Choosing the right classification scheme is a key factor

in object-oriented analysis and design

8

Classes: Classification of Objects

Figure 7.5 [Arlow & Neustadt, 2005]Classifying objects determining classes

9

Classes: Relationship with Objects. Figure 7.6 [Arlow & Neustadt, 2005]

<<instantiate>> relationship

10

Classes: .Relationship with Objects

The <<instantiate>> relationship is a stereotype of the dependency relationship

Dependency: “A relationship between two elements in which a change to one element (the supplier) may affect or supply information needed by the other element (the client)”.

11

Classes: UML Notation…… Figure 7.7 [Arlow & Neustadt, 2005]

12

Classes: .UML Notation…..

Figure 7.8 [Arlow & Neustadt, 2005]The attribute compartment

13

Classes: ..UML Notation…. Table 7.3 [Arlow & Neustadt, 2005]. Visibility types

14

Classes: …UML Notation…

15

Classes: ….UML Notation..

Figure 7.10 [Arlow & Neustadt, 2005] Operations

16

Classes: …..UML Notation. Figure 7.14 [Arlow & Neustadt, 2005]

Class stereotypes

17

Classes: ……UML Notation Figure 7.16 [Arlow &

Neustadt, 2005]Constructors

Figure 7.15 [Arlow & Neustadt, 2005]Class Scope

18

Analysis Classes Figure 8.2 [Arlow & Neustadt, 2005]

19

Analysis Classes [continued]

Figure 8.3 [Arlow and Neustadt, 2005]

Example of Analysis Class

20 / 15

Analysis Classes [continued]

What makes a good analysis class? Its name reflects its intent It is a crisp abstraction that models a specific

aspect of the problem domain It maps to a clearly identifiable feature of the

problem domain It has a small, well-defined set of responsibilities It has high cohesion It has low cohesion

21 / 15

Analysis Classes [continued]

Analysis classes rules of thumb: About 3-5 responsibilities per class No class stands alone Avoid:

▪ Many very small classes▪ Very large classes▪ Functoids (procedural functions disguised as classes)▪ Omnipotent classes▪ Deep inheritance trees

22 / 15

Finding Analysis Classes

Finding classes by using noun/verb analysis: Nouns: candidates for classes or attributes Verbs and verb phrases: candidates for operations

or responsibilities Beware of spurious and hidden classes Sources of information

▪ Requirements model▪ Use case model▪ Project glossary▪ Anything else (architecture, concept documents, etc.)

23

Finding Analysis Classes [continued]

Finding classes by using CRC analysis Phase 1 – Brainstorming Phase 2: AnalysisFigure 8.4 [Jim Arlow and Ila Neustadt, 2005]: Brainstorming, part of CRC analysis

24

Finding Analysis Classes [continued]

Finding analysis classes by using RUP stereotypes:

25 / 15

Boundary Classes

Used to model interactions between system and its actors and collect requirements on system’s boundaries

Look at user, system, and device interfaces Often represent windows, screens, APIs

[Kendall V. Scott]

26 / 15

Control Classes

Used to encapsulate control related to a specific use case

Represent coordination, sequencing, transactions, and control of other objects[Kendall V. Scott]

27 / 15

Entity Classes

Used to model long-lived/persistent information [Kendall V. Scott]

Cut across many use cases, are manipulated by control claasses, provide info to and accept info from boundary classes

28 / 15

Finding Analysis Classes [continued]

Finding classes by from other sources:▪ Real world entities:

▪ Physical objects (e.g., aircraft, people, hotel)▪ Paperwork (e.g., invoice, fill-in-form, bankbook)▪ Known interfaces such as screens, keyboards, peripherals▪ Conceptual entities such as LoyaltyProgram or RewardsCard

▪ Archetype patterns, for example:▪ Inventory▪ Money▪ Order▪ Party▪ Product