OOP, OOA

2.  OO Design is a process of invention, where developers create
the abstractions necessary to meet the system’s requirements
 OO Design is independent of the programming language used to
implement the design. However, using OO Language helps
 Objects are independent and encapsulate state and
representation information
 System functionality is expressed in terms of object services
 Shared data areas are eliminated. Objects communicate via
message passing

3.  OOD does not reduce development time. In fact it may increase
it!
 However, there is empirical evidence that OOD facilitates the
following activities:
 Reuse
 Maintenance
 Verification

4.  OOD is a set of principles and methods for designing systems based on
combining data and function into entities called objects
 OOD Principles include
 Encapsulation
 Decomposition
 Design Patterns
 Hierarchical Relationships
 Defined decision making

5.  OO systems are designed using a three phase iterative process
- Analysis
- Design
- Implementation
 Successful software systems evolve over time, leading to
iterative process, by evolving and refining each time through the
process.

6.  Definition ( Booch ):
OOA is a method of analysis that examines the requirements of
the system from the perspective of classes and objects that are
found in the vocabulary of the problem domain
 Transform programming problem into a precise description of
the tasks to be performed. Prior to analysis problem is usually
vaguely understood.
 OOA focuses on What needs to be done, not How it needs to be
done.

7.  OOA is the input to Object Oriented Design (OOD)
 Quality of OOD is based on quality of OOA
 When defining OOA need to work with problem domain expert.
 OOA provides a description of the problem
 The description must be complete, consistent, readable,
reviewable by diverse parties, and testable against the reality.
 You should not pursue issues of class design or representation
in the analysis phase

8.  Identify functional and non-functional points of the system
 Identify classes and objects( their roles and responsibilities)
from the vocabulary of problem domain
 Functional points are observable and testable behaviors of a
system
 End use perspective: function points represent the activity of
the system in response to an event
 Analyst perspective: function points represent a behavior. The
more function points, the greater system’s complexity

9.  When you have formal requirements analysis document
describing behavioral requirements
 Described non-functional requirements: reliability, security,
portability, and performance
 Capture descriptions of behavior by using scenarios
 Risk assessment: Identify known risks that may impact the
design process. Better to document risks early than discover
them latter.

10.  Identify objects that are common to a particular system
 Study similar existing systems (REUSE), benefiting from
other projects that had to make similar design decisions.
Do not reinvent the wheels!
 A domain model is a representation of real-world
conceptual classes
 A domain model is a visual representation of conceptual
classes or real-world objects in a domain of interest

11.  Identify the function points of the system and cluster them
by the related behaviors.
 If an object life cycle is essential to a scenario document
using a finite state machine
 Look for patterns in among developed scenarios

12.  Goal of OOA is to discover the objects in the system
specification
 We discover objects and classes that form the vocabulary of
system domain.
 Classical Approach
 Behavior Analysis
 Domain Analysis
 Use case Analysis
 CRC cards
 Structural Analysis

13.  Derive classes from the requirements of problem domain
 Derive candidate classes and objects from the following
sources:
 Tangible things
 Roles
 Events
 Interactions
 Structure
 Devices/Locations
 Organizational Units / Grouping

14.  Focus on dynamic behavior as the primary
source of classes and objects
 Emphasize responsibilities:
 Actions object can perform
 Group things that have common responsibilities.
 Create hierarchies that embody general responsibilities
and subclasses that specialize their behavior.

15.  Focuses on single specific application
 Seeks to identify the classes and objects that are
common to all applications within a specific domain
 Examples: Patient record tracking, stock and bond
trading, Compilers and etc.
 Addresses the fact that there are very few unique kinds
of software systems

16.  Goal: Derive process of analysis in a meaningful way
 Develop series of important scenarios and identify
objects, their responsibilities and how objects collaborate
with other objects

17.  A model is an abstraction describing a subset of a system
 A view depicts selected aspects of a model
 A notation is a set of graphical or textual rules for depicting
views
 Views and models of a single system may overlap each
other

19.  Introduced in 1989 by Kent Beck and Ward
Cunningham
 designed to teach object oriented programming at
Tektronix
 a CRC card is an index card in a group setting used
to represent:
 a class of objects
 their behavior
 their interactions

20.  Help to analyze scenarios
 CRC cards are 3x5 cards capturing:
 Name of the class
 Class responsibilities
 Collaboration with other classes
 Software team walks through scenarios and and
assigns new responsibilities, updates existing,
discovers new classes and etc

22.  responsibility: knowledge class maintains or service
class provides
 collaborator: a class whose knowledge or services are
needed to fulfill a responsibility
Class Name:
Responsibilities:
(what class does or knows)
Collaborators:
(which classes help it
perform each
responsibility)

23.  Responsibilities are concerned with:
 the maintenance of knowledge
 the actions the object can perform
 Technique:
 1. Highlight verbs/phrases in requirements
 2. Do walkthroughs
 3. Spread intelligence
 4. Keep behaviour and knowledge close

24.  A collaboration is where one class (a client) needs another
one (a server) in order to perform its own responsibilities.
 NB this is a one-way relationship
 Each responsibility may have:
 no collaborations
 one collaboration
 many collaborations

26. It involves a creative exchange:
 physical simulation of the workings of the system
 participants “become” one or more objects during walk-
throughs of typical scenarios
 classes are discovered and converted into cards
 responsibilities are assigned
 collaborators for each responsibility are identified

27.  portable: cards can be used anywhere, even away from the
computer or office
 anthropomorphic: no computer program can capture the
essence of the interactions forced by passing the cards
 level of involvement felt by each team member increases
 useful throughout the life cycle
 provides a basis for more formal analysis and design
methodologies.
 ease the transition from process orientation to object
orientation.

28.  UML is a multi-diagrammatic language
 Each diagram is a view into a model

29. COM6030 Systems Analysis and Design © University of Sheffield 2005
Systems analysis:
•user-oriented: actors and use cases;
•object-oriented: classes and relationships between them.
Clock
time: Time
reportTime(): Time
resetTimeTO(newTime: Time)
Class name
Attribute
Operations
Type
Value returned
Formal
parameter
(argument)Class identification:
•noun identification;
•responsibility driven approach (CRC cards).

30. THANK YOU