CS 426 Senior Projects in Computer Science Chapter 7: Classes and Objects Chapter 8: Finding Analysis Classes [Arlow and Neustadt, 2005] University of Nevada, Reno Department of Computer Science & Engineering
Outline • Objects • UML Notation for Objects • Classes • UML Notation for Classes • UP Activity: Analyze Use Cases • Analysis Classes • Finding Analysis Classes
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
Objects: Encapsulation • Fig. 7.2 [Arlow & Neustadt, 2005]
Objects: Messaging • Figure 7.3 [Arlow & Neustadt, 2005]
Objects: UML Notation • Figure 7.4 [Arlow & Neustadt, 2005]
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
Classes: Classification of Objects • Figure 7.5 [Arlow & Neustadt, 2005] Classifying objects determining classes
Classes: Relationship with Objects. • Figure 7.6 [Arlow & Neustadt, 2005] <<instantiate>> relationship
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)”.
Classes: UML Notation…… • Figure 7.7 [Arlow & Neustadt, 2005]
Classes: .UML Notation….. • Figure 7.8 [Arlow & Neustadt, 2005] The attribute compartment
Classes: ..UML Notation…. • Table 7.3 [Arlow & Neustadt, 2005]. Visibility types
Classes: …UML Notation…
Classes: ….UML Notation.. • Figure 7.10 [Arlow & Neustadt, 2005] Operations
Classes: …..UML Notation. • Figure 7.14 [Arlow & Neustadt, 2005] Class stereotypes
Classes: ……UML Notation • Figure 7.16 [Arlow & Neustadt, 2005] Constructors • Figure 7.15 [Arlow & Neustadt, 2005] Class Scope
Analysis Classes • Figure 8.2 [Arlow & Neustadt, 2005]
Analysis Classes [continued] • Figure 8.3 [Arlow and Neustadt, 2005] Example of Analysis Class
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
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
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.)
Finding Analysis Classes [continued] • Finding classes by using CRC analysis • Phase 1 – Brainstorming • Phase 2: Analysis Figure 8.4 [Jim Arlow and IlaNeustadt, 2005]: Brainstorming, part of CRC analysis
Finding Analysis Classes [continued] • Finding analysis classes by using RUP stereotypes:
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]
Control Classes • Used to encapsulate control related to a specific use case • Represent coordination, sequencing, transactions, and control of other objects [Kendall V. Scott]
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
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 LoyaltyProgramor RewardsCard • Archetype patterns, for example: • Inventory • Money • Order • Party • Product
