DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

Subject Name: OBJECT ORIENTED ANALYSIS AND DESIGN

Subject Code: U20CSE403

Prepared By:
Mr. S.Santhosh Rajan Asst.Prof / CSE

Verified by: Approved by:

SYLLABUS

UNIT I AN OVERVIEW OF OBJECT ORIENTED SYSTEM DEVELOPMENT (9 Hrs)

Introduction – Object Oriented System Development Methodology – Why object orientation – Overview of
Unified Approach – Object Basics: Object oriented philosophy – Objects – Classes – Attributes – Object
behavior and methods – Encapsulation and Information Hiding – Class hierarchy – Polymorphism – Object
Relationships and Associations – Aggregations and Object Containment – Object Identity – Static and
Dynamic Binding – Persistence. Object oriented systems development life cycle: Software development
process – Building high quality software – Use case driven approach - Reusability.

UNIT II OBJECT ORIENTED METHODOLOGIES (9 Hrs)

Rumbaugh et al.’s Object modeling technique – g – Jacobson et al. Methodologies – Patterns – Framework –
Unified approach – Unified modeling language: Static and Dynamic Model – UML Diagrams – UML class
diagram – UML use case diagram - UML dynamic modeling – UML extensibility – UML meta model.

UNIT III OBJECT ORIENTED ANALYSIS (9 Hrs)

Business object analysis – Use case driven object oriented analysis – Business process modeling – Use Case
model - Developing Effective Documentation – Object Analysis Classification: Classification Theory – Noun
Phrase Approach – Common Class Patterns Approach – Use Case Driven Approach – Classes Responsibilities
and Collaborators – Naming Classes – Identifying Object Relationships – Attributes and Methods: Association
– Super-Subclass Relationship – IS - A Relationship.

UNIT IV OBJECT ORIENTED DESIGN (9 Hrs)

Object Oriented Design Process – Object Oriented Design Axioms – Corollaries – Designing Classes: Object
constraint language – Process of designing class – Class visibility – Refining attributes – Access Layer: Object
1
store and Persistence – Database management system – Logical and Physical database- Organization and
Access Control – Distributed Databases and Client Server Computing – Object Oriented Database
Management System – Object Relational Systems – Designing Access Layer Classes – View Layer: Designing
View Layer Classes – Macro Level Process – Micro Level Process – Purpose of View Layer Interface –
Prototyping the user interface.

UNIT V SOFTWARE QUALITY (9 Hrs)

Software Quality Assurance: Quality Assurance Test – Testing strategies – Impact of object oriented testing
– Test cases – Test Plan – Myers debugging principle. System usability and measuring user satisfaction:
Usability testing – User satisfaction testing.

UNIT – I
INTRODUCTION

1. Overview of object-oriented language systems development

- System development refers to all activities that produce an information systems solution.
- System development activities are,
• Analysis
• Modelling
• Design
• Implementation
• Testing
• Maintenance
- A software development methodology is a series of processes that can lead to the
development of an application.
- Two orthogonal views of the software,
o Algorithms + Data structures = Programs
- Program: A software system is a mechanism for performing certain action on certain
data.
1.1 The two orthogonal views of the software
o Traditional system development methodology
▪ This approach focuses on the “Functions”
o Object oriented system development
▪ This approach focuses on the “Object” which combines “Data and
Functionality”
1.2 Object oriented system development methodology
o OOSD methodology is based on functions and procedures.
o OOSD is the way to develop software by building self- contained modules or
objects that can be easily,
▪ Replaced
▪ Modified
▪ Reused.
2
 o In an object-oriented system, everything is an object: numbers, arrays, records,
fields, files, forms, an invoice, etc.
o An Object is anything, real or abstract, about which we store data and those
methods that manipulate the data.
o Conceptually, each object is responsible for itself.
▪ E.g., 1. A chart object is responsible for things like maintaining its data
andlabels, and even for drawing itself.
▪ E.g., 2. A window object is responsible for things like opening, sizing,
andclosing itself.
1.3 Why an object orientation?
o To create sets of objects that work together with to produce software the problem.
o The systems are easier to adapt to changing requirements, easier to maintain,
more robust and promote greater design and code reuse.
o Object oriented development allows us to create modules of functionality.
o Once objects are defined, they will perform their desired functions.
o Here are some reasons,
▪ Higher level of abstraction
▪ Seamless transition among different phases of software development.
▪ Encouragement of good programming techniques
▪ Promotion of reusability
o Higher level of abstraction
▪ The top-down approach supports abstraction at the function level
▪ The object-oriented approach supports abstraction at the object level.Since
“objects encapsulate both data and functions they work at a higher
level of abstraction.”
o Seamless transition among different phases of software development.
▪ The object-oriented approach essentially uses the same language to talk
about analysis, design, programming, database design.
▪ This seamless approach reduces the level of complexity and redundancy
and makes for clear, more robust system development.
o Encouragement of good programming techniques
▪ Object oriented languages produce more modular and reusable code via the
concepts of class and inheritance.
▪ The object-oriented languages are C++, Smalltalk or Java.
o Promotion of reusability
▪ Objects are reusable because they are modelled directly out of a real-world
problem domain.
▪ The object orientation adds inheritance which is a powerful technique that
allows classes to be built from each other.

1.4 Overview of Unified approach

o Unified approach is a methodology for software development.
o The UA is based on methodologies by BOOCH, RUMBAUGH & JACOBSON
3
 tries to combine the best practices, processes and guidelines along with the object
management group’s unified modelling language.
o The unified modelling language (UML) is a set of notations and conventions used
to describe and model an application.
o Applying past development efforts to future projects will improve the quality of the
product and reduce the cost and development time.
o Steps to be followed in unified approach are
1. Identify the users/actors
2. Develop a simple business process model
3. Develop the use case
4. Interaction diagrams
5. Classification
6. Apply design axioms to design classes
7. Design the access layer
8. Design the view layer
9. Iterate and refine the design/analysis.
2. Object basics
- Object: It is a real-world entity that has properties and methods.
o E.g., Car.
- Properties (or Attributes): It describes the state (or data) of an object, refer Fig.1
o E.g., Color, manufacturer, cost, model and owner etc.

Fig. 1.1. Car Attributes

- Methods (or Procedures): It defines its behavior (or operations), refer Fig.2
o E.g., Go, stop, turn left, turn right and etc.…

4
Fig. 1.2. Car Methods

5
 - When developing an object-oriented application, two basic questions always arise,
o What objects does the application needs?
o What functionality should those objects have?
2.1 Object-Oriented Philosophy
o Object oriented programming is that it allows the base concepts of the language
to be extended to include ideas and terms closer to those of its applications.
o The traditional development methodologies are either algorithm centric or data
centric
1. Algorithm-centric methodology: An algorithm that can accomplish the
task, and then build data structures for that algorithm to use.
2. Data-centric methodology: To structure the data, and then build the
algorithm around that structure.
o Object-oriented methodology is the algorithm and the data structures are
packaged together as an object, which has a set of attributes or properties.
2.2 Objects are grouped into classes
o Classes are used to distinguish one type of objects from another
o A class is a set of objects that share a common structure and a common behavior
o Each object is an instance of a class, refer Fig. 3 and 4
o A class is a specification of,
1. Structure (instance variable)
2. Behaviour (methods)
3. Inheritance for objects

Fig. 1.3. Ada, Riche, James and Writh are Fig. 1.4. Employee
objectsof the class Employee class

6
2.3 Attributes or properties
o It represented by data type.
o It describe the state of an object
o Eg. Car attributes, see Fig. 5.

2.4 Behavior or methods

Fig. 1.5. Attributes

7
 o An object behaviour is described in methods or procedures
o A method implements the behaviour of an object.
o Behaviour denotes the collection of methods that abstractly describes what an
object is capable of doing.
o Eg. Drive a car – Methods, refer Fig.6.

Fig. 1.6. Methods

2.5 Objects Respond to Messages

o A message is much more general than function call.

o E.g., Problem is to make French onion soup. Sol: Your instruction is the message,
the way the French onion soup prepared is the method, and the French onion soup
is the object.
o Objects perform operations in response to messages.
o Objects respond to messages according to methods defined in its class.
o E.g., See the Fig. 7
1. Send a Brake message to a Car object
2. Send a multiplication *7 message to 5 objects
3. Send a Compute payroll message to Employee object

8
 Fig. 1.7. Object responds to message
2.6 Encapsulation and information hiding
o Information hiding is the principle of hiding internal data and procedures of an
object, refer Fig.8

Fig. 1.8. Access specifiers

o Encapsulation protects the data from corruption

o Providing an interface to each object in such a way as to reveal as little as possible
about inner workings.
o Encapsulation means in general, protection mechanism by using access specifiers
such as public, protected and private.
o Data are abstracted when they are shielded or hided by a full set of methods and
only those methods can access the data portion of an object.
o E.g., A car engine.
3. Class Hierarchy
- An object-oriented system organized classes into a “Subclass-Super class hierarchy”.
- At the top of the hierarchy are the most general (base) classes and at the bottom are the
most specific classes (sub-classes).
- The parent class also is known as the bases class or super class.
- A subclass inherits all of the properties and methods (procedures) defined in its super
class, refer Fig. 9 and 10.

9
 Fig. 1.9. Super class / Sub class Hierarchy

Fig. 1.10. Class hierarchy for Ford class

3.1 Inheritance
o Inheritance is a relationship between classes where one class is the parent class of
another (derived) class, refer Fig. 11.
o Inheritance allows classes to share and reuse behaviours and attributes.
o The real advantage of inheritance is that we can build and reuse what we already
have.

10
 Fig. 1.11. Inheritance allows reusability

o Dynamic Inheritance
1. It allows objects to change and evolve over time.
2. Dynamic inheritance refers to the ability to add, delete or change parents
from objects at run time.
3.2 Multiple Inheritance
o Object oriented systems permit a class to inherit its state (attributes) and behaviors
from more than one super class. This kind of inheritance is referred to as “Multiple
Inheritance”. Refer Fig. 12.

Fig. 1.12. Utility vehicle inherits from both the car and truck class

11
3.3 Polymorphism
o Poly means “Many” and morph means “Form”
o Polymorphism means that the same operation may behave differently on different
classes. Refer Fig. 13 and 14

Fig. 1.13. Car object represents polymorphism

Fig. 1.14. Compute Payroll represents polymorphism

3.4 Object relationship and Association
o The concept of association represents relationships between objects and class.
o Associations are bidirectional by which they can be traversed in both directions
o E.g., A pilot can fly planes, refer Fig.15.

Fig. 1.15. Association represents the relationship among objects which is bidirectional
12
 o Cardinality: it is an important issue in associations which specifies how
manyinstances of one class may relate to a single instance of a associated class.
o E.g., Client account relationship, refer Fig. 16.

Fig. 1.16. Cardinality in association

o Consumer - producer association, also known client-server association or use

relationship.
o A special form of association is a client-server relationship.
o This relationship can be viewed as one-way interaction: one object (client)
requests the service of another object (server). Refer Fig. 17.

5. Fig. 1.17. One-way direction association

4.Object and Identity

- A special future of object-oriented system is that every object has its own unique and
immutable identity.
- The identity name never changes even it all the properties of the object change, i.e., it
is independent of the object’s state.

13
 - The identity does not depend on the objects name, or its key or its location.
- In an object system, object identity often is implemented through some kind of “OBJECT
IDENTIFIER” (OID) or “UNIQUE IDENTIFIER” (UID). An OID is dispersed by a part
of object-oriented programming system that is responsible for guaranteeing the uniqueness
of every identifier.
- OID’s are never reused.
- E.g., The car may have an owner property, which refer the class person. A person has an
owns property that contains a reference to the car instance. The relationship between the
car and person can be implemented and maintained by a reference, refer Fig. 18.

Fig. 1.18. The owner property of the car contains the reference to the personinstance named Hal

4.1 Static and Dynamic Binding

o The process of determining, which function to invoke at run time is called as
“Dynamic binding”.
o E.g., Polymorphism function calls
o Making this determination earlier, at compile time is called as “Static binding”.
o E.g., Normal function calls
4.2 Object Persistence
o Objects have a life time. They are explicitly created and can exist for a period of
time.
o An object can persist beyond application session boundaries, during which the
object is stored in a database or a file.
4.3 Meta Classes
o Class is an object. If it is an object it must belong to a class, such a class belongs
to a class called a “Meta Class” or a class of classes.
o Meta-classes are used by a compiler.
1. E.g. The meta-classes handle messages to classes, such as constructors, new
and class variables, which are variables shared between all instance of a
class.

14
6. Object Oriented – SDLC
- The essence of the software development process that consists of
• Analysis
• Design
• Implementation
• Testing
• Refinement
- To transform users’ needs into a software solution that satisfies those needs.

5.1 Software Development Process

o “System or software development can be viewed as a process”
o The process can be divided into small, interacting phases called sub-processes.
o Each sub-processes must have the following
• A description in terms of how it works.
• Specification of the input required for the process.
• Specification of the output to be produced.
o The “Software development process” can be viewed as a series of transformations,
where the output of one transformation becomes the input of the subsequent
transformation. Refer Fig.19.

Fig. 1.19. Software process reflecting transformation from needs to a software product that
satisfiesthose needs.

15
 o Transformation 1 (Analysis): Translates the users’ needs into system
requirementsand responsibilities.
o Transformation 2 (Design): Begins with a problem statement and ends with
adetailed design that can be transformed into an operational system.
o Transformation 3 (Implementation): Refines the detailed design into the
systemdeployment that will satisfy the user’s needs.

“An Example (see Fig. 20) of the software development process is Waterfall
approach”

Fig. 1.20. The waterfall software development process

“Waterfall Approach” starts with deciding what is to be done. Once the

requirements have been determined, we must decide how to accomplish them. This is
followed by a step in which we do it, whatever it has required us to do. We then musttest
the result to see if we have satisfied the user’s requirements, finally we use what we have
done.

5.2 Building high quality Software

o The ultimate goal of building high quality software is user satisfaction.
o To achieve high quality in software we need to be able to answer the following
questions.
1. How do we determine when the system is ready for delivery?
2. Is it now an operational system that satisfies user’s needs?
3. Is it correct and operating as we thought it should?
4. Does it pass an evaluation process?
o Four Quality measures for software evaluation (see Fig. 21)
1. Correspondence: It measures how well the delivery system matches the
needsof the operational environment
2. Validation: It is the task of predicting correspondence

16
 3. Correctness: It measures the consistency of the product requirements
withrespect to the design specification
4. Verification: It is the exercise of determining correctness
o Verification: Am, I building the product, right?
o Validation: Am, I building the right product?

Fig. 1.21. Four quality measures for software evaluation

Validation begins as soon as the project starts, but verification can begin only after a
specification has been accepted. Validation & verification are independent of each other.

7. Object Oriented System Development Life Cycle (SDLC): A Use CaseDriven

Approach

- The object oriented SDLC (Software Development Life Cycle) consists of 3 macro
processes, refer Fig. 22.
i) Object Oriented Analysis (OOA)
ii) Object Oriented Design (OOD)
iii) Object Oriented Implementation (OOI)
- It includes the following activities
1. Object Oriented Analysis – Use case driven
2. Object Oriented Design
3. Prototyping
4. Component based development
5. Incremental testing

17
 Fig. 1.22. The object-oriented system development approach

1) Object Oriented Analysis (OOA) – Use case driven

o OOA phase of software development is concerned with

a) Determining the system requirements
b) Identifying classes & their relationship
c) To understand the system requirements, we need to identify the users or actors
d) “Use Case” – It is a typical interaction between user and a system that captures
users’ goals and needs
e) “Use Case Model” – The use case model represents the users view of the system
or the user needs
f) The process of developing the use cases, like other object-oriented activities are
iterative
g) The objects need to have meant only within the content of the application
domain.
e.g., The application domain might be a payroll system and the objects are
paycheck, employee, worker, supervisor, office administrator.
h) Documentation
a. It is another important activity which does not end with object-
o r i e n t e d analysis but should be carried out throughout the system
development.
b. 80-20 rule generally applies for documentation, i.e., 80% of the work
canbe done with 20% of the documentation.
18
2) Object Oriented Design (OOD)

a) The goal of OOD is to design the classes identified during the analysis phase
b) OOA and OOD are distinct disciplines, but they can be interconnected.
c) In OOD, design classes, define attributes and methods then build object and
dynamic model.
d) First build the object model based on objects and their relationship then iterate
and refine the model
a. Design and refine classes
b. Design and refine attributes
c. Design and refine the methods
d. Design and refine the structures
e. Design and refine the associations
e) Guidelines to use in your OOD
a. Reuse rather than build a new class know the existing classes
b. Design a large number of simple classes, rather than a small number of
complex classes
c. Design methods
d. A detailed analysis, what you have proposed. If possible, go-back and
refine the classes.
3) Prototyping
a) A prototype is a version of a software product developed in the early stages of the
products life cycle for specific, experimental purposes.
b) Prototyping can further define the use-cases, and actually makes use-case
modelling much easier.
c) Prototyping provides the developer a means to test and refine the user interface
and increase the usability of the system.
d) Prototypes have been categorized in various ways
a. Horizontal prototype:
a. It’s a simulation of the interface but contains no functionality.
b. An advantage is quick to implement.
b. Vertical prototype:
a. It is a subset of the system features with complete functionality.
b. An advantage is that the few implemented functions can be tested
in great depth.
c. Analysis prototype:
a. It is an aid for exploring the problem domain.
b. The final product will use the concepts exposed by the prototype,
not its code.
d. Domain prototype:

19
 a. It is an aid for the incremental development of the ultimate software
solution.
b. It demonstrates the feasibility of the implementation.
4) Implementation: Component Based Development
o Component Based Development (CBD) is an industrial approach to software
development.
o Software components are functional units, or building blocks offering a collectionof
reusable services.
o A CBD developer can assemble components to construct a completesoftware system.
o A component-based development is concerned with the implementation and system
integration aspects of software development.
o CASE: Computer Aided Software Engineering Tools allow their users to rapidly
develop information systems.
o Goal: The main goal of CASE technology is the automation of the entire systems
development life cycle process using a set of integrated software tools, such as
modelling, methodology and automatic code generation.
o RAD: Rapid Application Development
o RAD is to build a version of an application rapidly to see whether we actually
understood the problem.
o It builds the application quickly through tools such as Delphi, Visual Age, Visual
Basic.
5) Incremental Testing
o To test an application for bugs and performance.
o After development of applications are finally given to Quality Assurance group for
testing the process.

20