Chapter 7: Classes and Objects Chapter 8: Finding Analysis Classes [Arlow and Neustadt, 2005] CS 426/CPE 426 Senior Projects 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  Figure 8.4 [Jim Arlow and Ila Neustadt, 2005] Brainstorming, part of CRC analysis technique

21  Finding analysis classes by using RUP stereotypes:

22  Used to model interactions between system and its actors and collect requirements on system’s boundaries  Often represent windows, screens, APIs [Kendall V. Scott]

23  Used to encapsulate control related to a specific use case  Represent coordination, sequencing, transactions, and control of other objects [Kendall V. Scott]

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