Object Oriented Analysis

1. Analysis
Preeti Mishra
Course Instructor

2. System Development

3. Introduction
• System development is model building
• Starts when a requirement of system identified
• Specification can be used for contract and to plan and
control the development process
• As Complex process handle poorly so any systematic
method like structured or OOAM can used from start to
end of system life cycle

4. Introduction
• Selecting a methodology is not simple, as no one
methodology is always best.
• Many organizations have their own standards.
• Systems nature, constraints, and rules playing a major
rule in deciding which methodology to use
• Your experience as analyst is important to compare
and decide which methodology to use

5. Structured Analysis and Design Vs
OO Analysis and Design
• Structured analysis is a traditional systems development
technique that is time-tested and easy to understand.
• Structured analysis uses a set of process models to
describe a system graphically.
• Because it focuses on processes that transform data into
information, structured analysis is called a process-
centered technique
• Whereas structured analysis treats processes and data as
separate components, object-oriented analysis combines
data and the processes that act on the data into things
called objects.
• System analysts use O-O to model real world business
processes and operation.
• The result is a set of software objects that represent
actual people, things, transactions and events

6. Traditional Software Development

7. Structured analysis and design
– Advantages of Structured analysis and design
• visual, so it is easier for users/programmers to
understand
• Makes good use of graphical tools
• A mature technique
• Process-oriented approach is a natural way of thinking
• simple and easy to understand and impalement

8. Disadvantages of Structured
analysis and design
• Not enough user-analyst interaction
• It depends on dividing system to sub systems but
it is to decide when to stop decomposing

9. Object Orientation
Encapsulation
Abstraction
Hierarchy
Modularity
Basic Principles of Object
Orientation

10. Basic Concepts of Object Orientation
(Few of them Already Studied)
• Object
• Class
• Attribute
• Operation
• Interface (Polymorphism)
• Component
• Package
• Subsystem
• Relationships

11. Systems Development Methodologies
Object-Oriented analysis and design
– Object-Oriented analysis and design becoming
popular because of its ability to thoroughly:
• represent complex relationships,
• as well as represent data and data processing with a
consistent notation
– Object-Oriented analysis and design blend
analysis and design in evolutionary process
– It allows you to deal with the complexity inherent
in a real-world problem by focusing on the
essential and interesting features of an
application

12. Systems Development Methodologies
Object-Oriented analysis and design
– Process of progressively developing representation
of a system component (or object) through the
phases of:
• analysis,
• design and
• implementation
– The model is abstract in the early stages
– As the model evolves, it becomes more and more
detailed

13. Object-Oriented systems development life cycle
• Object-Oriented analysis and design
• object representation through three phases
– analysis,
– design, and
– implementation

15. Analysis,
Design, and
Implementation

16. Analysis Phase
– Object-oriented analysis is a popular approach
that sees a system from the viewpoint of the
objects themselves as they function and interact
– Model of the real-world application is developed showing its
important properties
– Model specifies the functional behavior of the system independent
of implementation details

17. Design Phase
– Design Phase
• Analysis model is refined and adapted to the
environment
• Can be separated into two stages
– System design
» Concerned with overall system architecture
– Object design
» Implementation details are added to system design

18. Implementation Phase
– Implementation Phase
• Design is implemented using a programming language
and/ or database management system

19. Testing Phase follows..
• Testing Process
– Unit
– Integration
– System

21. Analysis
In Detail

22. Introduction
• The analysis phase defines the requirements of the system,
independent of how these requirements will be accomplished.
• This phase defines the problem that the customer is trying to
solve.
• The deliverable result at the end of this phase is a
requirement document. Ideally, this document states in a clear
and precise fashion what is to be built.
• This analysis represents the ``what'' phase.
• The requirement document tries to capture the requirements
from the customer's perspective by defining goals and
interactions at a level removed from the implementation
details.

23. Object Oriented
Analysis
• We use UML (Unified Modeling Language) to
represent the analysis details.
• Following models are used to model the Object
Oriented Analysis using UML
– Use Case Diagram
– Class diagram

25. Domain Model

26. What is a domain model?
• “A domain model captures the most important
types of objects in the context of the business.
The domain model represents the ‘things’ that exist
or events that transpire in the business
environment.” – I. Jacobsen

27. What is a Domain Model?
• Illustrates meaningful conceptual classes in
problem domain
• Represents real-world concepts, not software
components

28. Why do a domain model?
• Gives a conceptual framework of the things in the problem
space
• Helps you think – focus on semantics
• Provides a glossary of terms – noun based
• It is a static view - meaning it allows us convey time
invariant business rules
• Foundation for use case/workflow modelling
• Based on the defined structure, we can describe the state
of the problem domain at any time.

29. Features of a domain model
• The following features enable us to express
time invariant static business rules for a
domain:-
o Domain classes – each domain class denotes a type of object.
o Attributes – an attribute is the description of a named slot of a
specified type in a domain class; each instance of the class separately
holds a value.
o Associations – an association is a relationship between two (or more)
domain classes that describes links between their object instances.
Associations can have roles, describing the multiplicity and
participation of a class in the relationship.
o Additional rules – complex rules that cannot be shown with symbology
can be shown with attached notes.

31. Identifying Domain
Classes from Problem
Statement

32. How to Draw Domain Model
• Reuse an existing domain model
– There are many published, well-crafted domain models.
• •Use a conceptual class category list
– Make a list of all candidate conceptual classes
• •Identify noun phrases
– Identify nouns and phrases in textual descriptions of a
domain ( use cases, or other documents)

33. Domain classes?
• Each domain class denotes a type of object. It is a
descriptor for a set of things that share common features.
Classes can be:-
o Business objects - represent things that are manipulated in the
business e.g. Order.
o Real world objects – things that the business keeps track of e.g.
Contact, Site.
o Events that transpire - e.g. sale and payment.
• A domain class has attributes and associations with other
classes
• It is important that a domain class is given a good
description

34. There are different
types of Objects
• Entity Objects
– Represent the persistent information tracked
by the system (Application domain objects, also
called “Business objects”)
• Boundary Objects
– Represent the interaction between the user
and the system
• Control Objects
– Represent the control tasks performed by the
system.

35. Year
Month
Day
ChangeDate
Button
LCDDisplay
Entity Objects Control Object Boundary Objects
To distinguish different object types
in a model we can use the
UML Stereotype mechanism

36. Class Identification
Class identification is crucial to object-
oriented modeling
– Helps to identify the important entities of a
system
• Basic assumptions:
1. We can find the classes for a new software
system (Forward Engineering)
2. We can identify the classes in an existing
system (Reverse Engineering)
• Why can we do this?
– Philosophy, science, experimental evidence.

37. Class Identification
• Approaches
– Application domain approach
• Ask application domain experts to identify relevant
abstractions
– Syntactic approach
• Start with use cases
• Analyze the text to identify the objects
• Extract participating objects from flow of events
– Design patterns approach
• Use reusable design patterns
– Component-based approach
• Identify existing solution classes.

38. Ways to find Objects
• Syntactical investigation with Abbot‘s technique:
– Flow of events in use cases
– Problem statement
• Use other knowledge sources:
– Application knowledge: End users and experts know the
abstractions of the application domain
– Solution knowledge: Abstractions in the solution domain
– General world knowledge: Your generic knowledge and
intution

39. Class identification is a
Hard Problem
• One problem: Definition of the system boundary:
– Which abstractions are outside, which abstractions are
inside the system boundary?
• Actors are outside the system
• Classes/Objects are inside the system.
• An other problem: Classes/Objects are not just
found by taking a picture of a scene or domain
– The application domain has to be analyzed
– Depending on the purpose of the system different objects
might be found
• How can we identify the purpose of a system?
• Scenarios and use cases => Functional model

40. Steps for Domain Classes
1. Make a list of potential objects by finding out the nouns and noun
phrases from narrative problem statement
2. Apply subject matter expertise (or domain knowledge) to identify
additional classes
3. Filter out the redundant or irrelevant classes
4. Classify all potential objects based on categories.
5. Group the objects based on similar attributes. While grouping we
should remember that Different nouns (or noun phrases) can actually
refer to the same thing (examples: house, home, abode)
6. Same nouns (or noun phrases) could refer to different things or
concepts (example: I go to school every day / This school of thought
agrees with the theory)
7. Give related names to each group to generate the final list of top level
classes Iterate over to refine the list of classes

41. Listing Noun Phrases
• An obvious way to identify domain classes is to identify
nouns and phrases in textual descriptions of a domain.
• Consider a use case description as follows:-
1. Customer arrives at a checkout with goods and/or services to
purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records the sale line item and presents the item
description, price and running total.

42. Where to identify conceptual
classes from noun phrases
• Vision and Scope, Glossary and Use Cases are
good for this type of linguistic analysis
• However:
– •Words may be ambiguous or synonymous
– •Noun phrases may also be attributes or parameters
rather than classes:
• If it stores state information or it has multiple behaviors, then it’s
a class
• If it’s just a number or a string, then it’s probably an attribute

43. Few Hints..
Categories Explanation
People
Humans who carry out some
function
Places
Areas set aside for people or
things
Things Physical objects
Organizations
Collection of people, resources,
facilities and capabilities having a
defined mission
Concepts Principles or Ideas not tangible
Events
Things that happen (usually at a
given date and time), or as a steps
in an ordered sequence

44. Identifying attributes ?
• A domain class sounds like an attribute if: -
o It relies on an associated class for it’s
identity – e.g. ‘order number’ class
associated to an ‘order’ class. The ‘order
number’ sounds suspiciously like an
attribute of ‘order’.
o It is a simple data type – e.g. ‘order
number’ is a simple integer. Now it really
sounds like an attribute!

46. Combining the learning
Perform the following in very short iterations:
o Make a list of candidate domain classes.
o Draw these classes in a UML class diagram.
o If possible, add brief descriptions for the classes.
o Identify any associations that are necessary.
o Decide if some domain classes are really just attributes.
o Where helpful, identify role names and multiplicity for associations.
o Add any additional static rules as UML notes that cannot be conveyed
with UML symbols.
o Group diagrams/domain classes by category into packages.
Concentrate more on just identifying domain classes
in early iterations !

47. Steps in Generating Class
Diagrams
1. Class identification (textual analysis, domain expert)
2. Identification of attributes and operations
(sometimes before the classes are found!)
3. Identification of associations between classes
4. Identification of multiplicities
5. Identification of roles
6. Identification of inheritance

48. Work it out…
• example

49. Who uses Class
Diagrams?
• Purpose of class diagrams
– The description of the static properties of a
system
• The main users of class diagrams:
– The application domain expert
• uses class diagrams to model the application domain
(including taxonomies)
– during requirements elicitation and analysis
– The developer
• uses class diagrams during the development of a
system
– during analysis, system design, object design and
implementation.

50. Who does not use Class Diagrams?
• The client and the end user are usually not
interested in class diagrams
– Clients focus more on project management
issues
– End users are more interested in the
functionality of the system.

51. Developers have different
Views on Class Diagrams
• According to the development activity, a
developer plays different roles:
– Analyst
– System Designer
– Object Designer
– Implementor
• Each of these roles has a different view about
the class diagram (the object model).

53. An overview of OOSE development
activities and their products
Requirements
elicitation
Analysis
System design
problem statement
functional
model
nonfunctional
requirements
analysis
object model
dynamic
model
class diagram
use case
diagram
statechart
diagram
sequence diagram