1. 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. 2  Objects  UML Notation for Objects  Classes  UML Notation for Classes  UP Activity: Analyze Use Cases  Analysis Classes  Finding Analysis Classes

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

5. 5  Figure 7.3 [Arlow & Neustadt, 2005]

6. 6  Figure 7.4 [Arlow & Neustadt, 2005]

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

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

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

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

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

14. 14

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

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

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

18. 18  Figure 8.2 [Arlow & Neustadt, 2005]

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

20. 20  Figure 8.4 [Jim Arlow and Ila Neustadt, 2005] Brainstorming, part of CRC analysis technique

21. 21  Finding analysis classes by using RUP stereotypes:

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

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