Object oriented software engineering

 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

 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

 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

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

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

 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

 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

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

 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

 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

 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

 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

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

 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

 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

 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

 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

 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

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

 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

 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

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

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

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

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

Object oriented software engineering

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Object oriented software engineering

Similar to Object oriented software engineering (20)

Recently uploaded

Recently uploaded (20)

Object oriented software engineering