Chapter 7: Classes and Objects Chapter 8: Finding Analysis Classes [Arlow and Neustadt, 2005] CS 426 Senior Projects in Computer Science University of Nevada, Reno Department of Computer Science & Engineering

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

3  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  Fig. 7.2 [Arlow & Neustadt, 2005]

5  Figure 7.3 [Arlow & Neustadt, 2005]

6  Figure 7.4 [Arlow & Neustadt, 2005]

7  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  Figure 7.5 [Arlow & Neustadt, 2005] Classifying objects  determining classes

9  Figure 7.6 [Arlow & Neustadt, 2005] > relationship

10  The > 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  Figure 7.7 [Arlow & Neustadt, 2005]

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

13  Table 7.3 [Arlow & Neustadt, 2005]. Visibility types

14

15  Figure 7.10 [Arlow & Neustadt, 2005] Operations

16  Figure 7.14 [Arlow & Neustadt, 2005] Class stereotypes

17  Figure 7.16 [Arlow & Neustadt, 2005] Constructors  Figure 7.15 [Arlow & Neustadt, 2005] Class Scope

18  Figure 8.2 [Arlow & Neustadt, 2005]

19  Figure 8.3 [Arlow and Neustadt, 2005] Example of Analysis Class

20  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  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  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 classes by using CRC analysis  Phase 1 – Brainstorming  Phase 2: Analysis Figure 8.4 [Jim Arlow and Ila Neustadt, 2005]: Brainstorming, part of CRC analysis

24  Finding analysis classes by using RUP stereotypes:

25  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  Used to encapsulate control related to a specific use case  Represent coordination, sequencing, transactions, and control of other objects [Kendall V. Scott]

27  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  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