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

More Related Content

What's hot (20)

Similar to Object oriented software engineering (20)

Recently uploaded (20)

Object oriented software engineering