1. Analysis, Actually, Object-Oriented Analysis
For Milestone #4
2/21/2019
Analysis

2. Analysis
is the separation of a whole into its component parts; an examination of a problem, its elements, and its relationships (Book)
Understand the problem from a modeling/logic point of view
Preparing for design
2/21/2019
Analysis

3. Object-Oriented Analysis
is the process of identifying objects that are relevant to the problem to be solved and their relationships.
the process includes classifying the objects and finding relationships among the classes.
2/21/2019
Analysis

4. Object-Oriented Analysis
Basically we need to answer the following questions:
What are my objects
What do they do
How do they interact with each other?
2/21/2019
Analysis

5. Avoiding Analysis Paralysis
Referring to situations when a team cannot determine if the process is completed
Rules of Thumb of rescuing yourselves PP Read
2/21/2019
Analysis

6. Analysis Work Products
Guidelines
Subject Areas
Object Models
Scenarios
Object Interaction Diagrams
State Models
Class Descriptions
2/21/2019
Analysis

7. Analysis Guidelines
The set of rules intended to document the way in which analysis is to be preformed on a particular project
There are, in general, two kinds of Analysis Guidelines
work product guidelines
see the example on page 523, copy it if you really want to use it!
process guidelines
More useful, again, copy existing one to start
2/21/2019
Analysis

8. Analysis Work Products
Guidelines
Subject Areas
Object Models
Scenarios
Object Interaction Diagrams
State Models
Class Descriptions
2/21/2019
Analysis

9. Subject Area Description
When dealing with a large system, you may want to break the system into a set of sub-systems
For example, AAA
membership subsystem
material subsystem
travel package subsystem
… ...
2/21/2019
Analysis

10. Subject Areas in Object-Oriented Analysis
clusters of analysis classes that are closely related to each other by
inheritance (“is-a”),
aggregation (“has-a”),
and other (“uses”) associations.
2/21/2019
Analysis

11. Subject Area Purpose
permits a large system to be partitioned very early in its development cycle.
encourages a separation of analysis concerns,
provides a means of organizing work products.
2/21/2019
Analysis

12. Subject Area Notation A simple table is sufficient.
For each Subject Area, the following is relevant
Name of Subject Area
Brief Description
Key Classes
Dependencies (Other subject areas used by this one)
Workbook
2/21/2019
Analysis

13. Your Subject Area
If you have more than three subject areas, something is wrong with your project
Too large
Un-necessarily detailed
I can see you have one or two subject areas
One: Everything – consider this first
Two: Student and Professor
Need to have two workbooks
2/21/2019
Analysis

14. Analysis Work Products
Guidelines
Subject Areas
Object Models
Scenarios
Object Interaction Diagrams
State Models
Class Descriptions
2/21/2019
Analysis

15. Analysis Object Model It is static.
It consists of classes and relationships among classes.
One of the most important work products, if not the most important work product!!!
2/21/2019
Analysis

16. Analysis Object Model Purpose
The fundamental way to document the static aspects of objects in the problem domain
What makes object-oriented development different from traditional development
Basic idea is to decompose a system down into classes of objects that cooperate by passing messages to get the job done
2/21/2019
Analysis

17. How To Identify Classes
Example, from the user cases
1. Customers rent tapes from the store.
2. Customers return tapes to the store.
We can identify three objects
Customer, Tape, and Store
Which object needs to be implemented is project dependent
Nouns represent Classes
Verbs represent services/actions, etc.
2/21/2019
Analysis

18. Object-Oriented Notation
Classes
Relationships
Generalization/specialization (Is A)
Association (Knows About)
Aggregation (Has A)
Attributes (members)
Behavior (methods)
2/21/2019
Analysis

19. Classes Always have three parts: Name Attributes Methods
Drawn as a three part box (Fig 11-2, pp. 194)
Name
Tape
Attributes
Code
Name
Methods
GetName
GetPrice
2/21/2019
Analysis

20. Generalization/Specialization
Shown as a hierarchy of super/subtype relationships where the sub types inherit the properties (both attributes and services) of the super-types.
Figure 11-3 (pp ) shows class inheritance hierarchy:
Car, Truck, and Van all are Vehicle
2/21/2019
Analysis

21. Generalization/Specialization
Vehicle
SUV
Truck
2/21/2019
Analysis

22. Association Association is the simplest form of relationship
It represents knowledge of the existence of other objects.
The association can be thought of as a class in its own right.
2/21/2019
Analysis

23. Association Customer Tape Account Transaction Review 2/21/2019
Analysis

24. Associations have cardinality
0 or 1
hollow ball 1
no marker
0 or many
solid ball
2/21/2019
Analysis

25. Aggregation
Shows the part-whole hierarchy relating object classes in the model
For example, a car is decomposed into body and engine.
Thought to “contain” the components, i.e. body and engine; they are its parts.
Most often means ownership.
If uncertainty exists between association or aggregation, leave an association.
2/21/2019
Analysis

26. Aggregation
Car
Body
Engine
2/21/2019
Analysis

27. Attributes represent the structural properties of a class. For a car,
make
model
year
2/21/2019
Analysis

28. Behavior
The behavior of a class, also documented as a service or operation, is a statement of the responsibilities of the class.
2/21/2019
Analysis

29. Advice and Guidance The simpler the better No design decisions
Kiss rule – keep it simple, stupid!
No design decisions
Objects should relate to the end user. Your client should recognize them from their domain.
2/21/2019
Analysis

30. Naming Guidelines
Name object classes with common noun phrases (for example, Customer)
Name services that modify objects with active verbs (for example, rent or return)
Name services that query objects with verbs indicating queries (for example, gettingPrice)
2/21/2019
Analysis

31. Analysis Work Products
Guidelines
Subject Areas
Object Models
Scenarios
Object Interaction Diagrams
State Models
Class Descriptions
2/21/2019
Analysis

32. Analysis Scenarios A Scenario is an elaboration of a Use Case
Use Cases are statements of high-level functional requirements
Scenarios add more detail and describe factors that may result in behavioral variations of a given Use Case.
Scenario = Use Case + Assumptions (initial conditions) + Outcomes.
2/21/2019
Analysis

33. Analysis Scenario Purpose
Scenarios are refinements of Use Cases and are used to develop Object Interaction diagrams.
A single Use Case can generate multiple Scenarios, and Scenarios derived from the same Use Case can involve the interplay of different classes.
2/21/2019
Analysis

34. Analysis Scenario Technique
Scenarios can be generated directly from Use Cases.
Constructed by identifying
possible different outcomes for a Use Case.
Different conditions that might result in different kinds of collaborations.
2/21/2019
Analysis

35. Scenario Example User Case 1: Customer Rents a Video
Scenario 1.1 Member rents a video (successfully)
Assumption:
Member is in good standing
A video copy of requested movie is available
Outcome:
Member rents successfully
Movie available count is decrease by 1
A rental record is created
The rental count for the movie is incremented
2/21/2019
Analysis

36. Scenario Example User Case 1: Customer Rents a Video
Scenario 1.2 Member rents a video (successfully)
Assumption:
Member is has fine outstanding
Member pays the fine
A video copy of requested movie is available
Outcome:
Member rents successfully
Member is in good standing
Movie available count is decrease by 1
A rental record is created
The rental count for the movie is incremented
2/21/2019
Analysis

37. Format of Analysis Scenarios
Use Case 1.
Scenario 1.1
Assumption:
Outcomes:
Scenario 1.2
2/21/2019
Analysis

38. Iterative & Incremental
You may need to
Add new user cases
Re-think your user cases for modification
2/21/2019
Analysis

39. Analysis Work Products
Guidelines
Subject Areas
Object Models
Scenarios
Object Interaction Diagrams
State Models
Class Descriptions
2/21/2019
Analysis

40. Object Interaction Diagrams
An Object Interaction Diagram (OID) is a graphical representation of an Analysis Scenario.
OID shows collaboration necessary to achieve the desired outcomes on one thread of action
2/21/2019
Analysis

41. Analysis Interaction Diagram Purpose
Provides a high-level view of how objects interact
Presents a trace of action, in the form of objects interaction, in a simple and graphical way.
Can be used to discover responsibilities that are needed to carry out Scenarios, and to assign those responsibilities to classes.
2/21/2019
Analysis

42. Techniques for Object Interaction Diagrams
Tracing the scenario on the classes it interacts to carried out the scenario
Deciding which objects need to participate
Deciding the participating class
Asking the question,
“what happens now?”, is asked repeatedly.
2/21/2019
Analysis

43. Notation Object and its class Time Line Message Message Parameter
Synchronous message (sender wait)
Asynchronous message (sender does not wait)
Message Parameter
Condition
Loop
Internal Activity
2/21/2019
Analysis

44. Object Interaction Diagrams
Acustomer:Member
aClerk:Clerk
aRental:Rental
aTape:Video
getIDPhome(PhoneNo)
return(userID)
getFineAmount(userID)
return(fineAmount)
[fineAmount <> 0]
zeroFine(userID, fineAmount)
createRental(userID,dateTime)
addTape(RentalID,tapeCode)
return(RentalID, price, returnDate)
2/21/2019
Analysis

45. Analysis Work Products
Guidelines
Subject Areas
Object Models
Scenarios
Object Interaction Diagrams
State Models
Class Descriptions
2/21/2019
Analysis

46. Analysis State Models
A state model describes the life cycle of an object in a class.
It describes states that an object may attain and transitions that cause a change of states.
The state transitions, representing external stimuli or events, showing an object that changes.
It is represented by a state diagram or transition table.
2/21/2019
Analysis

47. Analysis State Model Purpose
A state model represents an object’s life cycle in graphical notation or in tabular form.
It gives an overview of how an object reacts to external events without getting into code detail
2/21/2019
Analysis

48. State Diagram Notation
State are shown in circles/boxes
Transitions are shown ad directed arcs
The arcs need to be labeled
2/21/2019
Analysis

49. State Diagram Example Filed Clerk files Clerk shelves Customer rents
Ready
Rented
Customer returns
Clerk marks for sale
ForSale
Customer buys
Sold
2/21/2019
Analysis

50. Analysis Work Products
Guidelines
Subject Areas
Object Models
Scenarios
Object Interaction Diagrams
State Models
Class Descriptions
2/21/2019
Analysis

51. Analysis Class Descriptions
Analysis Class Descriptions are summaries of all the information known about a class at the analysis level
Class-related information exists in several places, in the analysis chapter of the project workbook,
in scenarios
in state models
2/21/2019
Analysis

52. Class Description Purpose
Three reasons for Analysis Class Descriptions
to provide a place to put class-specific information that might otherwise slip down cracks between the other analysis work products.
to provide a single point of contact for analysis information regarding a particular class.
a place to record information that won’t fit on other diagrams.
2/21/2019
Analysis

53. Notation of Class description
1. Name
2. Definition
3. Operations
4. Key attributes
5. Relations
6. States
7. Documentation
2/21/2019
Analysis

54. Analysis Class Description Example
See book 232
2/21/2019
Analysis