Chapter 6: The Analysis Workflow 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  The Analysis Workflow  Objects  UML Notation for Objects  Classes  UML Notation for Classes  UP Activity: Analyze Use Cases  Analysis Classes  Finding Analysis Classes

3 Chapter 6 roadmap

4 Analysis emphasized in Inception and Elaboration phases

5 Analysis meta-model

6 Analysis workflow detail

7 The Analysis Model: Is always in the language of business Captures the big picture Contains artifacts that model the problem domain Tells a story about the desired system Should be useful to many stakeholders

8 Rules of thumb – Analysis Model: Only include classes from problem domain Do not make implementation decisions Focus on classes and associations Minimize coupling Use inheritance only when it comes naturally Keep it simple

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

10

11

12

13 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

14 Classifying objects  determining classes

15 > relationship

16  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)”.

17

18 The attribute compartment

19 Visibility types

20

21 Operations

22 Class stereotypes

23  Constructors  Class Scope

24 Analysis process

25 Example of analysis class

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

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

28  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.)

29  Finding classes by using CRC analysis Phase 1 – Brainstorming Phase 2 – Analysis Figure 8.4 : Brainstorming, part of CRC analysis

30  Finding analysis classes by using RUP stereotypes:

31  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]

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

33  Used to model long-lived/persistent information [Kendall V. Scott]  Cut across many use cases, are manipulated by control classes, provide info to and accept info from boundary classes

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

35  Finding classes by from other sources: ▪ Archetype patterns, for example: Inventory Money Order Party Product