Chapter 7: Classes and Objects Chapter 8: Finding Analysis Classes
description
Transcript of Chapter 7: Classes and Objects Chapter 8: Finding Analysis Classes
Chapter 7: Classes and ObjectsChapter 8: Finding Analysis Classes
[Arlow and Neustadt, 2005]
CS 426 Senior Projects in Computer Science
University of Nevada, RenoDepartment of Computer Science & Engineering
2 / 15
Outline
Objects UML Notation for Objects Classes UML Notation for Classes UP Activity: Analyze Use Cases Analysis Classes Finding Analysis Classes
3 / 15
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
4
Objects: Encapsulation
Fig. 7.2 [Arlow & Neustadt, 2005]
5
Objects: Messaging
Figure 7.3 [Arlow & Neustadt, 2005]
6
Objects: UML Notation Figure 7.4 [Arlow & Neustadt, 2005]
7 / 15
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
8
Classes: Classification of Objects
Figure 7.5 [Arlow & Neustadt, 2005]Classifying objects determining classes
9
Classes: Relationship with Objects. Figure 7.6 [Arlow & Neustadt, 2005]
<<instantiate>> relationship
10
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)”.
11
Classes: UML Notation…… Figure 7.7 [Arlow & Neustadt, 2005]
12
Classes: .UML Notation…..
Figure 7.8 [Arlow & Neustadt, 2005]The attribute compartment
13
Classes: ..UML Notation…. Table 7.3 [Arlow & Neustadt, 2005]. Visibility types
14
Classes: …UML Notation…
15
Classes: ….UML Notation..
Figure 7.10 [Arlow & Neustadt, 2005] Operations
16
Classes: …..UML Notation. Figure 7.14 [Arlow & Neustadt, 2005]
Class stereotypes
17
Classes: ……UML Notation Figure 7.16 [Arlow &
Neustadt, 2005]Constructors
Figure 7.15 [Arlow & Neustadt, 2005]Class Scope
18
Analysis Classes Figure 8.2 [Arlow & Neustadt, 2005]
19
Analysis Classes [continued]
Figure 8.3 [Arlow and Neustadt, 2005]
Example of Analysis Class
20 / 15
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
21 / 15
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
22 / 15
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.)
23
Finding Analysis Classes [continued]
Finding classes by using CRC analysis Phase 1 – Brainstorming Phase 2: AnalysisFigure 8.4 [Jim Arlow and Ila Neustadt, 2005]: Brainstorming, part of CRC analysis
24
Finding Analysis Classes [continued]
Finding analysis classes by using RUP stereotypes:
25 / 15
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]
26 / 15
Control Classes
Used to encapsulate control related to a specific use case
Represent coordination, sequencing, transactions, and control of other objects[Kendall V. Scott]
27 / 15
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
28 / 15
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 LoyaltyProgram or RewardsCard
▪ Archetype patterns, for example:▪ Inventory▪ Money▪ Order▪ Party▪ Product