OODJ-MODULE 1.pptx

OBJECT ORIENTED DESIGN AND
PROGRAMMING WITH JAVA(OODJ)
Date: 03-03-2022(Thursday)
Time:12.00-1.00
COURSE CODE:20CS3503
LECTURE 1:INTRODUCTION TO THE COURSE

SYLLABUS
MODULE 1: 9 hrs.
An Overview of Object-Oriented Systems Development: Introduction; Two Orthogonal Views of the Software; Object-
Oriented Systems Development Methodology; Why an Object-Oriented? Overview of the Unified Approach.
Object Basics: Introduction; An Object-Oriented Philosophy; Objects; Objects are Grouped in Classes; Attributes: Object
State and Properties; Object Behavior and Methods; Object Respond to Messages; Encapsulation and Information Hiding;
Class Hierarchy: Inheritance; Multiple Inheritance; Polymorphism; Object Relationships and Associations: Consumer-
Producer Association; Aggregation and Object Containment; Case Study - A Payroll Program.
Object-Oriented Systems Development Life Cycle: Introduction; Software Development Process; Building High-Quality
Software; Object-Oriented Systems Development: A Use Case Driven Approach; Reusability.

SYLLABUS
MODULE 2: 8 hrs
Unified Modelling Language: Introduction; Static and Dynamic models; Why Modelling? Introduction to the UML; UML
Diagrams; UML Class Diagram; Use-Case Diagram.
Introduction to Java: Java’s Magic: The Bytecode; JVM; Object-Oriented Programming; Simple Java programs; Two
Control Statements; Lexical Issues;
Data Types; Variables, Arrays and String constructors; Operators; Control Statements;
Introducing Classes: Class Fundamentals; objects; methods; constructors; this Keyword; Garbage Collection; finalize()
method; Parameter Passing; Overloading; Access Control Keywords. Inheritance basics; method overriding; abstract classes;
Packages and interfaces. Exception handling fundamentals; multiple catch; nested try statements.

SYLLABUS
MODULE 3: 9 hrs.
Multi-Threaded Programming: Multi-Threaded Programming: Java Thread Model; The main Thread; Creating a thread and
multiple threads; Extending threads; Implementing Runnable; Synchronization; Inter Thread Communication; producer
consumer problem.
Input/Output: I/O Basic; Reading console input Writing Console output.
Module 4: 8 hrs.
Event and GUI Programming: Introducing Swing; The Origins of Swing; Swing Is Built on the AWT; Two Key Swing
Features; The MVC Connection; Components and Containers; The Swing Packages; A Simple Swing Application; Event
Handling; JLabel; JTextField; JButton.
•

SYLLABUS
MODULE 5: 8 hrs
Database Access: The Concept of JDBC; JDBC Driver Types; JDBC Packages; A Brief Overview of the JDBC
process; Database Connection; Associating the JDBC/ODBC Bridge with the Database; Statement Objects;
Result Set.

SOFWARES TO BE INSTALLED
1.JDK-Java Development Kit(latest version)
https://www.oracle.com/in/java/technologies/javase-downloads.html
http://www.digitizedpost.com/how-to-install-jdk-jre-on-windows-10/
2. Any of the Integrated Development Environment(IDE)
1.Eclipse
2.IntelliJ
3.BlueJ
4.Netbeans
5.VisualStudio

TEXT BOOKS
1. Bahrami A.; Object Oriented Systems Development using the Unified Modeling Language; McGraw Hill; 1999.
2. Schildt; Herbert. Java The Complete Reference; 8th Edition. US: McGraw-Hill Osborne Media; 2011.
3. Jim Keogh; J2EE: The Complete Reference; McGraw Hill Education in 2002.
Reference Books:
1. Barclay K., J. Savage, Object Oriented Design with UML and Java, Elsevier, 2004.
2. Sierra K., Head First Java, 2nd edition, O’Reilly, 2005.
3. Y. Daniel Liang, Introduction to Java Programming, 7th edition, Pearson, 2013.

LEVELS OF PROGRAMMING LANGUAGES
A programming language defines a set of instructions that are compiled together to perform a specific task by the CPU
(Central Processing Unit).
1.Machine Level Language
 The machine-level language is a language that consists of a set of instructions that are in the binary form 0 or 1.
2.Assembly Level Language
 The assembly language contains some human-readable commands such as mov, add, sub, etc.
3.High level language
 The high-level language is a programming language that allows a programmer to write the programs which are independent
of a particular type of computer. The high-level languages are considered as high-level because they are closer to human
languages than machine-level languages.

PROGRAMMING PARADIGM
It is classification of programming languages based on their
characteristics/ features. There are number of programming paradigms
like procedure oriented, object oriented, logical programming,
declarative programming etc.

PROCEDURAL ORIENTED PROGRAMMING(POP)
 Procedural programming is a programming paradigm, based on the concept of the procedures/Functions .
 Procedures/routine/subroutine/Functions simply contain a series of computational steps to be carried out. Any given
procedure might be called at any point during a program's execution, including by other procedures or itself.

CHARACTERISTICS OF PROCEDURE-ORIENTED
PROGRAMMING LANGUAGE
1. It emphasis on algorithm (doing this ).
2. Large programs are divided into smaller programs known as functions-Modularity.
3. Function can communicate by global variable.
4. Data move freely from one function to another function.
5. Functions change the value of data at any time from any place. (Functions transform data from one form to another.)
6. It uses top-down programming approach.
7. Pre-defined functions
8. Scoping.
Examples: FORTRAN, ALGOL, COBOL, BASIC, Pascal and C.

DISADVANTAGES OF POP
1.The complexity increases as the code grows larger.
2.Difficult to relate with the real world objects.
3.Data is exposed to the whole programs so less security for data(Global variables).
4.Emphasis on operations performed on data rather than data.
5.Not recommended for data sensitive projects.
6.Code reuse in large development projects.

OBJECTED ORIENTED PROGRAMMING(OOP)
 Object oriented programming is a programming that is based on the idea of objects to represent data and methods . Objects
contain data in the form of attributes and code in the form of methods . OOP creates a neat and reusable code.
 Object oriented programming helps programmers create complex programs by grouping together related data and
functions.

CHARACTERISTICS OF OOP
1. It follows a bottom-up approach.
2. The program resulting from object-oriented programming is a collection of objects. Each object has its own data and a set
of operations.
3. OOP restricts the free movement of data and the functions that operate on it.
4. A properly defined class can be reused, giving way to code reusability.
5. The concept of object-oriented programming models real-world entities very well.
6. Due to its object-oriented approach, it is extremely useful in solving complex problems.
7. Data Hiding
Examples: C++,Java ,Python ,C# ,Ruby ,PHP ,R , Perl etc.

COMPARISION POP AND OOP
POP OOP
1.Follows Top down approach 1.Follows bottom up approach
2.The program is divided into functions 2.The program is divided into objects
3.No concept of access specifiers 3.There are three access specifiers namely public ,
private and protected
4. less data security 4.High data security
5.Data is shared between functions 5.Data is shared among objects(through inheritance)
6.Data hiding is not possible 6.Data hiding can be achieved through encapsulation
7.Code reusability –not much 7.Code reusability is high due to inheritance
8.Code Modification is not easy 8.Easy to modify and integrate new features
9.ALGOL,FORTRAN,C 9.C++,java , Python

1.Which feature of OOPS described the reusability of code?
(a)Encapsulation (b)Abstraction (c)Inheritance (d) Polymorphism
2.Which feature of OOPS provides data security?
(a)Encapsulation (b)Abstraction (c)Inheritance (d) Polymorphism
3. Which of the following approach is adapted by C++?
(a)Top down (b)Bottom up (c) Left Right (d)Right Left
4. BASIC, C, FORTRAN, and Pascal are example of
(a)POP (b)OOP (c)Machine level (d) None
5. Local Variables are..
(a) Declared outside function (b)Global variables (c)Accessible throughout the program (d) Accessible within the
function in which they are declared.
6. Modular systems are
(a) easy to debug (b)easy to change (c)systems built around different modules (d)All of the above
7. Variables declared outside a function and they can be accessed by any function in the program are..
(a) State Variables (b) Local Variables (c)Global Variables (d)Re-usable Variables

Time:9.45-10.45
LECTURE 2:MODULE 1
CHAPTER 1
AN OVERVIEW OF OBJECT-ORIENTED SYSTEMS DEVELOPMENT

MODULE 1:SYLLABUS
MODULE1: 9hrs.
An Overview of Object-Oriented Systems Development: Introduction; Two Orthogonal Views of the Software; Object-
Oriented Systems Development Methodology; Why an Object-Oriented? Overview of the Unified Approach.
Object Basics: Introduction; An Object-Oriented Philosophy; Objects; Objects are Grouped in Classes; Attributes: Object
State and Properties; Object Behavior and Methods; Object Respond to Messages; Encapsulation and Information Hiding;
Class Hierarchy: Inheritance; Multiple Inheritance; Polymorphism; Object Relationships and Associations: Consumer-
Producer Association; Aggregation and Object Containment; Case Study - A Payroll Program.
Object-Oriented Systems Development Life Cycle: Introduction; Software Development Process; Building High-Quality
Software; Object-Oriented Systems Development: A Use Case Driven Approach; Reusability.

INTRODUCTION
SYSTEM DEVELOPMENT:
 Software development is dynamic and always undergoing major change.
 System development refers to all activities that go into producing information system solution . Systems development is the
process of defining, designing, testing and implementing a new software application or program.
 A software development methodology is a series of processes that, if followed, can lead to the development of application.
The software processes describe how the work is to be carried out to achieve the original goal based on the system
requirements.
 Each process consists of a number of steps and rules that should be performed during development.
 The process by which software is conceptualized ,developed and maintained is known as Software Development
Lifecycle(SDLC).

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

SYSTEM DESIGN METHODOLOGIES
There are several system design methodologies that are being used depending on its usefulness pertaining to the situation and
application developed.
 SDLC/Waterfall model is the oldest System development methodology.
 Evolutionary/Spiral Model (used for mainly developing games-features are incorporated after user feedback-iterative
process)
 Agile Methodologies(iterative, requirements are unpredictable, used for software development, examples : SCRUM and
Extensive Programming(XP))
 Raid Application Development(RAD)
 Object Oriented Analysis and Design(OOAD)
 Rational Unified Process(RUP)
 Prototyping

Date: 04-03-2022(Friday)
Time:11.00-12.00
LECTURE 3:MODULE 1
CHAPTER 1

TWO ORTHOGONAL VIEWS OF A SOFTWARE
A software system is a set of mechanisms for performing certain action on certain data.
There are mainly two ways of software construction
1.Traditional Approach
2.Object Oriented Approach
TRADITIONAL DEVELOPMENT APPROACH
1.Views software as a collection of programs/functions and isolated data.
ALGORITHMS+DATASTRUCTURE=PROGRAM
2.It focuses on the functions of the system-what it is doing?
3.Primary focus is on functions rather than data.
4.Data flows freely.

TWO ORTHOGONAL VIEWS OF A SOFTWARE
OBJECT ORIENTED DEVELOPMENT APPROACH
 Views software as a collection of discrete objects that encapsulate their data as well as the functionality to model real world
entity.
 OO systems development is a way to develop software by building self-contained modules or objects that can be easily
replaced, modified, and reused.
 Each object has attributes (data) and methods (functions).
 Objects are grouped into classes and each object is responsible for itself.
 Example:
 Every Windows application needs Windows objects that can open themselves on screen and either display something or
accept input.
 A Windows object is responsible for things like opening, sizing, and closing itself.

COMPARISION OF TRADITIONAL AND OBJECT ORIENTED
APPROACH
TRADITIONALAPPROACH OBJECT-ORIENTED APPROACH
1.Collection of procedures/functions 1.Collection of objects
2.Focus is on operation 2.Focus on data
3.Moving from one phase to another is difficult 3.Moving from one phase to another is easier
4.Increase Duration of the project 4.Decreases Duration of project
5.Increases Complexity 5.Decreases complexity and redundancy

WHY AN OBJECT-ORIENTATION?
OO methods enables to create set of objects that work together to produce software that better model the problem
domains than similar systems produced by traditional techniques.
The systems are easier to adapt to:
 changing requirements,
 easier to maintain,
 more robust,
 promote greater design and,
 code reuse.
 OO development allows us to create modules of functionality
 Once objects are defined, it can be taken for granted that they will perform their desired functions.

REASONS FOR WHY OBJECT ORIENTATION WORKS?
1.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 (attributes) and functions (methods), they work at a higher level of
abstraction.
 The development can proceed at the object level and ignore the rest of the system for as long as necessary.
 This makes designing, coding, testing, and maintaining the system much simpler.

2. SEAMLESS TRANSITION AMONG DIFFERENT PHASES OF SOFTWARE DEVELOPMENT.
• The traditional approach to software development requires different styles and methodologies for each step of the
process.
• Moving from one phase to another requires complex transition of perspective between models that almost can be in
different worlds.
• The transition not only can slow the development process but also increases the size of the project and the chance for
errors introduced in moving from one phase to another.
• The object oriented approach essentially uses the same language to talk about analysis, design, programming, and
database design.
• This seamless approach reduces the level of complexity and redundancy and makes for clearer, more robust system
development.

3. ENCOURAGEMENT OF GOOD PROGRAMMING TECHNIQUES.
 A class in an OO system carefully delineates between its interface (specifications of what the class can do) and the
implementation of that interface (how the class does what it does).
 The routines and attributes within a class are held together tightly.
 In a properly designed system, the classes will be grouped into subsystems but remain independent; therefore, changing one
class has no impact on other classes and so the impact is minimized.
 By raising the level of abstraction from the function level to the object level and by focusing on the real-world aspects of
the system, the OO method tends to promote clearer designs; which are easier to implement, and provide for better overall
communication.

4. PROMOTION OF REUSABILITY.
• Objects are reusable because they are modeled directly out of a real-world problem domain.
• Each object stands by itself or within a small circle of peers (other objects).
• Within this framework, the class does not concern itself with the rest of the system or how it is going to be used within a
particular system.
• This means that classes are designed generically, with reuse as a constant background goal.
• The object orientation adds inheritance, which is a powerful technique that allows classes to be built from each other;
• Therefore, only differences and enhancements between the classes need to be designed and coded.
• All the previous functionality remains and can be reused without change.

Q&A
1. The process of defining, designing, testing and implementing a new software application or program is ----------------.
2. The full form of SDLC is-----------------------------.
3. There are ------------- phases in SDLC.
4. Name the phases in SDLC
5. SDLC is an ------------(one time/iterative)process.
6. Name the two orthogonal views of software construction.
7. Each object in OO methodology has --------------- and ------------------------.

Time:9.00-9.40(9.45-10.25)
LECTURE 4:MODULE 1

THE OVERVIEW OF UNIFIED APPROACH
 The Unified Approach (UA) is a methodology for software development that is proposed by the author Ali Bahrami (1999).
The UA, based on methodologies by Booch, Rumbaugh, and Jacobson, tries to combine the best practices, processes, and
guidelines along with the Object Management Group's unified modeling language.
 The Unified Approach uses the UML to describe and model the analysis and design phases of system development.
 The unified modeling language (UML) is a set of notations and conventions used to describe and model an application.
 UML does not specify a methodology or what steps to follow to develop an application; that would be the task of UA.
 The main aim of UML is to define a standard way to visualize the way a system has been designed. It is quite similar to
blueprints used in other fields of engineering. UML is not a programming language, it is rather a visual language. We
use UML diagrams to portray the behavior and structure of a system.

THE OVERVIEW OF UNIFIED APPROACH(Cont..)
 The heart of Unified Approach is Jacobson’s use case.
 In systems engineering as well as in software engineering, a “use case” is a list of event steps or actions, typically defining
the interactions between a “role” and a system in order to achieve a goal.
 The use case represents a typical interaction between the user and the computer system to capture the users goals and
needs.
 The UA establishes a unifying and unitary framework around their works by utilizing the UML to describe the model and
document the software development process.
 The idea behind the UA is not to introduce yet another methodology. The main motivation was to combine the best
practices, processes, methodologies, and guidelines along with UML notations and diagrams for better
understanding of object-oriented concepts and system development.

UNIFIED APPROACH FOR SOFTWARE DEVELOPMENT
 The unified approach to software development revolves around (but is not limited to) to the following processes and
concepts.
1. Use-case driven development
2. Object-oriented analysis
3. Object-oriented design
4. Incremental development and prototyping
5. Continuous testing
The UA allows iterative development allows to go back and forth between the design and the modeling or analysis phases. It
makes backtracking very easy and departs from the linear waterfall process, which allows no form of back tracking.

UNIFIED APPROACH-OBJECT ORIENTED ANALYSIS
 Analysis is the process of extracting the needs of a system and what the system must do to satisfy the users’ requirements.
The goal of object-oriented analysis is to first understand the domain of the problem and the system’s responsibilities by
understanding how the users use or will use the system.
 OOA process consists of the following steps:
1. Identify the Actors.- Who is or will be using the system.
2. Develop a simple business process model using UML Activity diagram.
The advantage of developing business process model is it familiarizes you with the system and therefore the user
requirements.

3.Develop the Use Case.
Use cases provide comprehensive documentation of the system under study. Use cases captures the goal of the users and the
responsibilities of the system to its users.
4.Develop interaction diagrams/collaboration diagram/sequence diagrams(iterate and redefine).
The process of creating sequence and collaboration diagrams is a systematic way to think about how the use case can take
place and thereby identifies the objects involved in the application.

5.Classification
 Identify classes.
 Identify relationships
 Identify attributes
 Identify methods

UNIFIED APPROACH-OBJECT ORIENTED DESIGN
OOD Process consists of:
1.Designing classes, their attributes, methods, associations, structures and protocols, apply design axioms.
2.Design the Access Layer
3.Design and prototype User interface
4. User Satisfaction and Usability Tests based on the Usage/Use Cases
5.Iterated and refine the design

THE LAYERED APPROACH TO SOFTWARE DEVELOPMENT
 Most systems developed with today’s CASE tools or client-server application development environments tend to lean
toward what is known as two-layered architecture: interface and data.
 In a two-layered system, user interface screens are tied to the data through routines that sit directly behind the screens.
 With every new interface, the business logic needed to run the screen must also be recreated . The data must exist within
the screen in order to be used by the routines.
 Any change to the business logic must be accomplished in every screen that deals with that portion of the business. This
approach results in objects that are very specialized and cannot be reused easily in other projects.
 A better approach to systems architecture is one that isolates the functions of the interface from the functions of the
business. This approach also isolates the business from the details of the data access.

• It is an approach to software development that allows us to create objects that represent tangible elements of
the business independent of how they are represented to the user through an interface or physically stored in a
database. This is the traditional method for designing most software and is meant to be self-independent. This
means that all the components are interconnected but do not depend on each other.

• The presentation layer : It contains all categories related to the presentation layer.
• The business layer : It contains business logic.
• The persistence layer/Access layer : It’s used for handling functions like object-relational mapping
• The database layer : This is where all the data is stored.
This approach reduces the interdependence of the user interface, database access, and business control.
It allows for a more robust and flexible system.

SUMMARY OF CHAPTER 1
 In an object-oriented environment, software is a collection of discrete objects that encapsulate their data and
the functionality to model real-world "objects."
 An object orientation produces systems that are easier to evolve, more flexible, more robust, and more
reusable than a top-down structure approach. An object orientation allows working at a higher level of
abstraction.
 Provides a seamless transition among different phases of software development.
 Encourages good development practices.
 Promotes reusability.
 The unified approach (UA) is the methodology for software development proposed. Based on the Booch,
Rumbaugh, and Jacobson methodologies, the UA consists of the following concepts:• Use-case driven
development.• Utilizing the unified modeling language for modeling. • Object-oriented analysis (utilizing use
cases and object modeling).Object-oriented design. • Repositories of reusable classes and maximum reuse.
 The layered approach. Incremental development and prototyping . Continuous testing.

Date: 08-03-2022(TUESDAY)
Time:11.00-12.00.
LECTURE 5: OBJECT BASICS

SYLLABUS
Introduction; An Object-Oriented Philosophy; Objects; Objects are Grouped in Classes; Attributes: Object State
and Properties; Object Behavior and Methods; Object Respond to Messages; Encapsulation and Information
Hiding; Class Hierarchy: Inheritance; Multiple Inheritance; Polymorphism; Object Relationships and
Associations: Consumer-Producer Association; Aggregation and Object Containment; Case Study - A Payroll
Program.

INTRODUCTION
The main motivation of object oriented system design is to make software development easier and more natural by raising the
level of abstraction.
The object oriented concepts are language independent.
WHAT IS AN OBJECT?
A real world entity, identifiably separate from the surroundings.
An entity that has state and behavior is known as an object
Example: chair, bike, marker, pen, table, car, etc.
An object has two characteristics:
 Attributes or properties describe object‘s state (data)
 Methods (properties or functions) define its behavior such as deposit, withdraw, etc.

OBJECTS
 Combination of data and logic that represents some real world entity.
 Simula is the first object oriented programming language.
 In the Car example the car’s attributes are: color, manufacturer, cost, owner, model, etc.
 In the Car example the car’s methods are: drive it, lock it, change mileage, stop, start, carry passenger in it.
 When developing an object oriented applications, two questions always arises
1. What object does the application need?
2. What functionality should those objects have?
 Programming in an object oriented system consist of adding new kinds of object to the system and defining how they
behave.

INTRODUCTION-OBJECT
Example 1:

INTRODUCTION-OBJECT
Example 2:

INTRODUCTION-OBJECT
Example 3:

INTRODUCTION-OBJECT
Example 4:
Class defines common characteristics or properties of an object. Class is a template or blue print to define object.
Object is an instance of a class having specific values of common properties.

INTRODUCTION-OBJECT
Example 5:

INTRODUCTION-OBJECT
 OBJECT’S ATTRIBUTES
Attributes are represented by data type. They describe objects states.
In the Car example the car’s attributes are: color, manufacturer, cost, owner, model, etc.
 OBJECT’S METHODS
Methods define objects behavior and specify the way in which an Object’s data are manipulated.
In the Car example the car’s methods are: drive it, lock it, tow it, carry passenger in it.

AN OBJECT ORIENTED PHILOSOPHY
 A language natural or programming, provides its users a base set of constructs.
 Many programing languages derive their base ideas from the underlying machine.
 The machine may “understand” or recognize data types such as integers, floating point numbers, and characters; and the
programming language will represent these types as structures.
 The machine may understand indirect addressing modes or base plus offset addressing: and the programming language
correspondingly will present the concept of pointers and vectors.
 In practical terms, it means that a user or programmer is implementing, say, a financial investment (risk, returns, growth,
and the various investment instruments) into the much lower-level primitives of the programming language. like vectors or
integers.
 It would be marvelous if we could build a machine whose underlying primitives were precisely those of an application. The
user who needs to develop a financial application could develop a financial investment machine directly in financial in
vestment machine language with no mental translation at all.
 Clearly, it is too expensive to design new hardware on a per-application basis.

 Programming languages can bridge the semantic gap between the concepts of the application and those of the underlying
machine.
 A fundamental characteristic of 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. New data types can be defined in terms of existing
data types until it appears that the language directly supports the primitives of application.
 Example: In financial investment example
A bond (data type) may be defined in such a way that has the same understanding within the language as a character data type.
A buy operation on a bond can be defined that has the same understanding as the familiar plus (+) operation on a number.
 Using this data abstraction mechanism, it is possible to create new, higher-level, and more specialized data abstractions.
User’s can work directly in the language, manipulating the kinds of "objects" required by their application, without having
to constantly struggle to bridge the gap between how to conceive of these objects and how to write the code to represent
them.

 The fundamental difference between the object-oriented systems and their traditional counterparts is the way in which the
problems are approached.
 Most traditional development methodologies are either algorithm centric or data centric.
 In an algorithm-centric methodology, first the algorithm that can accomplish the task is decided, then build data structures
for that algorithm to use is finalized.
 In a data-centric methodology, first how to structure the data is decided , then build the algorithm around that structure is
finalized.
 In an object-oriented system, however, the algorithm and the data structures are packaged together as an object, which has a
set of attributes or properties. The state of these attributes is reflected in the values stored in its data structures. In addition,
the object has a collection of procedures or methods-things it can do as reflected in its package of methods. The attributes
and methods are equal and in separable parts of the object; one cannot ignore one for the sake of the other.
 For example, a car has certain attributes, such as color, year, model, and price, and can perform a number of operations,
such as go, stop, turn left, and turn right.
 In summary, object-oriented programming languages bridge the semantic gap between the ideas of the application and
those of the underlying machine, and objects represent the application data in a way that is not forced by hardware
architecture.

OBJECTS ARE GROUPED INTO CLASSES
 Classes are used to distinguish one type of object from another.
 In the context of object oriented systems, a class is a set of objects that share a common structure and a common behavior.
 A single object is simply an instance(a single occurrence of something) of a class.
 A class is a specification of structure (instance variables), behavior (methods), and inheritance for objects.
 Classes are an important mechanism for classifying objects. The chief role of a class is to define the properties and
procedures (the state and behavior) and applicability of its instances.
 The class car , for example, defines the property color. Each individual car (formally, each instance of the class car ) will
have a value for this property, such as maroon, yellow, or white.
 In an object-oriented system, a method or behavior of an object is defined by its classes.

OBJECTS ARE GROUPED INTO CLASSES
 Class is a template/blueprint for objects . Every object of a given class has the same data format and responds to the
same instructions.
 Adam and Kesha are instances/objects of class Student.
 Any number of objects can be created for the class.
 The instructions responded to by each of those instances of student are managed by the class.
 The data associated with particular object is managed by the object itself.
 For example, there might be two employee objects, one called Varun and the other Kiran.
Each student object is responsible for is own data, such as name ,USN ,section , semester etc.

ATTRIBUTES: OBJECT STATE AND PROPERTIES
 Properties represents the state of an object
 In the car example the properties are cost, color, make, model etc.
 The property can be represented in several ways in a programming languages.
Example :
 For color we would choose to use a sequence of character such as red, or stock numbers for the red paint.
 Manufacturer would be denoted by a name, a reference to a manufacture object, or some complete identification number.
 Cost could be floating or fixed point number, or an integer
Question1:
Write the attributes for the object mobile phone.
Question 2:
Attributes for washing machine.

Date: 10-03-2022(THURSDAY)
Time:12.00-1.00
LECTURE 6: OBJECT BASICS

OBJECT BEHAVIOR AND METHODS
• In the object model, object behavior is described in methods or procedures.
• A method implements the behavior of an object. Basically, a method is a function or procedure that is defined for a class
and typically can access the internal state of an object of that class to perform some operation.
• Behavior denotes the collection of methods that abstractly describes what an object is capable of doing. Each procedure
defines and describes a particular behavior of an object.
• The object, called the receiver, is that on which the method operates.
• Methods encapsulate the behavior of the object, provide interfaces to the object and hide any of the internal structures
and states maintained by the object.
• Procedures provide us the means to communicate with an object and access its properties.
• The use of methods to exclusively access or update properties is considered good programming style, since it limits the
impact of any later changes to the representation of the properties.

OBJECT BEHAVIOR AND METHODS
Objects take responsibility their own behavior. In an object-oriented system, one does not have to write complicated
code to utilize extensive conditional checks through the use case statements deciding what function to call based on
data type class. For example, employee object knows how to compute its payroll. Therefore, inorder to compute an
employee salary, all that is required is to send the computePayroll "message" employee object.

OBJECT RESPONDS TO MESSAGES
 Objects capabilities are defined by the methods defined for it.
 Methods conceptually are equivalent to the function definitions used in procedural languages.
 For example, a draw method would tell a chart how to draw itself: How ever to-do an operation, a message is sent to
an object. Objects perform operations in response to messages.
 For example, when you press on the brake pedal of car, you send a stop message to the car object. The car object
knows how to respond to the stop message, since brakes have been designed with specialized parts such as brake
pads and drums precisely to respond to that message.
 Messages essentially are nonspecific function calls. We would send a draw message to a chart when we want the
chart to draw itself. A message is different from a subroutine call, since different objects can respond to the same
message in different ways.
 For example, cars, motorcycles, and bicycles will all respond to a stop message, but the actual operations performed
are object specific.

 In the Figure, we send a Brake message to the Car object. In the middle example, we send a multiplication message to 5
object followed by the number by which we want to multiply 5.
 In the bottom example, a Compute Payroll message is sent to the Employee object, where the employee object knows
how to respond to the Payroll message.
 The message makes no assumptions about the class of the receiver or the arguments; they are simply objects. It is the
receiver's responsibility to respond to a message in an appropriate manner. This gives you a great deal of flexibility,
since different objects can respond to the same message in different ways. This is known as polymorphism meaning
"many shapes (behaviors):”

 Polymorphism is the main difference between a message and a subroutine call. Methods are similar to functions,
procedures, or subroutines in more traditional programming languages.
 Methods and functions differ in a way in which they are invoked.
 In an object-oriented system, methods are invoked by sending a message to the object.
 A message is much more general than a function call. To draw a chart, you would send a draw message to the chart
object.
 Notice that draw is a more general instruction than, say, draw a chart. That is because the draw message can be sent
to many other objects, such as a line or circle, and each object could act differently.

DIFFERENCES BETWEEN MESSAGE AND METHODS
 A method is the code that actually gets executed by the receiving object, after the system has looked up the match
between the receiver and the message.. A message is an instruction, asking for something to be done by the
object.(Method-”how to do”, message-”what to do”)
 Example: You tell someone to make you soup. Your instruction is the message. The way the soup is prepared is the
method and the soup is the object.
 In other words, the message is the instruction and the method is the implementation.
 An object or an instance of a class understands messages, A message has name, just like a method, such as cost, set
cost. Cooking time.
 An object understands a message when it can match the message to a method that has a same name as the message,
To match up the message, an object first searches the methods defined by its class.

ENCAPSULATION AND INFORMATION HIDING
 Information hiding or data hiding in programming is about protecting data or information from any
inadvertent change throughout the program. Information hiding is a powerful OOP feature.
 Information hiding is the principle of concealing the internal data and procedures of an object and providing
an interface to each object in such a way as to reveal as little as possible about its inner workings.
 Information hiding definition: Information or data hiding is a programming concept which protects the data
from direct modification by other parts of the program.
 As in Conventional programming, some languages permits arbitrary access to objects and allow methods to
be defined outside the class.
 For example: Simula provides no protection, or information hiding for objects. (i.e., object’s data may be
accessed wherever visible).

 Information hiding is closely associated with encapsulation.
 Most Object Oriented languages provide a well defined interface to their objects through classes.
 For example: C++ has a very general encapsulation protection mechanism with public, private and
protected members.
 Public members (member data and member function) may be accessed from anywhere.
 The private methods and data can only be accessed by code that is a member of the class. Therefore, any
other code that is not a member of the class cannot access a private method or variable.
 Protected applies only when inheritance is involved.

 Often, an object is said to encapsulate the data and a program. This means that the user cannot see the inside of the
object “capsule,” but can use the object by calling the object's methods.
 Encapsulation or information hiding is a design goal of an object-oriented system. Rather than allowing an object
direct access to another object's data, a message is sent to the target object requesting information.
 This ensures not only that instructions are operating on the proper data but also that no object can operate directly on
another object's data.
 Using this technique , an object's internal format is insulated from other objects.
 A car engine is an example of encapsulation. Although engines may differ in implementation, the interface between
the driver and the car is through a common protocol. Step on the gas to increase power and let up on the gas to
decrease power. Since all drivers know this protocol, all drivers can use this method in all cars, no matter what
engine is in the car, That detail is insulated from the rest of the car and from the driver. This simplifies the
manipulation of car objects and the maintenance of code.
 Data abstraction is a benefit of the object-oriented concept that incorporates encapsulation and polymorphism. Data
are abstracted when they are shielded by full set of methods and only those methods can access the data portion of
an object.

DATA HIDING THROUGH ACCESS SPECIFIER
Access to the data defined in the class can be specified using three access specifiers.
 1.Public
 2.Private
 3.Protected
Access Specifier Own Class Derived Class Outside Class
Public yes yes yes
Private yes No No
Protected yes yes No

ENCAPSULATION EXAMPLE
Struct Student
{
char student_name[50];
int roll_no;
};
int main()
{
struct Student s1;
s1.student_name=“Alice”;
s1.roll_no=01
printf(“Student name is %s”,s1.student_name);
printf(“Student roll no is %d”,s1.roll_no);
}

ENCAPSULATION EXAMPLE
Class Student
{
private string student_name;
private int roll_no;
public void set_name(string newname)
{
student_name=newname;
}
public void set_roll_no(newrollno)
{
roll_no=newrollno;
}
public string get _name()
{
return student_name;
}
public int get_roll_no()
{
return roll_no;
}
}
public class RunEncap
{
public static void main(String args[])
{
Student s1 = new Student();
s1.set_Name("James");
s1.set_roll_no(20);
System.out.println(“Student Name: " + s1.get_name());
System.out.println(“Student roll_no: " + s1.get_roll_no());
}

ENCAPSULATION IN SUMMARY
 Encapsulation is a mechanism of wrapping the data(variables) and the code acting on the data(methods) together as a single
unit.
 How to implement encapsulation in java:
1) Make the instance variables private so that they cannot be accessed directly from outside the class. set and get values of
these variables can only be done through the methods of the class.
2) Have getter and setter methods in the class to set and get the values of the fields.
 Advantages of Encapsulation
1. It improves maintainability and flexibility and re-usability.
2. The fields can be made read-only (If we don’t define setter methods in the class) or write-only (If we don’t define the
getter methods in the class).
3. User would not be knowing what is going on behind the scene. They would only be knowing that to update a field call set
method and to read a field call get method but what these set and get methods are doing is purely hidden from them.

Date: 11-03-20222(FRIDAY)
Time:11.00-12.00.
LECTURE 6: INHERITANCE AND POLYMORPHISM

CLASS HIERARACHY
 An object-oriented system organizes classes into a subclass-super class hierarchy.
 At the top of the class hierarchy are the most general classes and at the bottom are the most specific.
 A subclass inherits all of the properties and methods (procedures) defined in its super class.
 Subclasses generally add new methods and properties specific to that class. Subclasses may refine or
constrain the state and behavior inherited from its super class.
 In some object oriented languages, the term super class and sub class are used interchangeably as base and
derived class.

INHERITANCE
 Inheritance is the property of object-oriented systems that allows objects to be built from other objects.
 The technique of constructing a new class by using an existing class functionality is called inheritance.
 It makes it possible to create a child class that inherits the fields and methods of the parent class.
 Inheritance is a relationship between classes where one class is the parent class of another (derived/child)
class. The parent class is also known as the base class or super class.
 Sub Class: The class that inherits properties from another class is called Sub class or Derived Class.
Super Class: The class whose properties are inherited by sub class is called Base Class or Super class.

INHERITANCE
 A class (child class) can extend another class (parent class) by inheriting its features.
 Implements the DRY (Don’t Repeat Yourself) programming principle.
 Improves code reusability.
 Inheritance represents the IS-A relationship, also knownas parent-child relationship.
 The real advantage of using this technique is that we can build on what we already have and, more important,
reuse what we already have. Inheritance allows classes to share and reuse behaviors and attributes , where the
behavior of a class instance is defined in that class's methods, a class also inherits the behaviors and attributes
of all of its super classes.

INHERITANCE EXAMPLE
 For example, the Car class defines the
general behavior of cars. The Ford class
inherits the general behavior from the Car
class and adds behavior specific to Fords. It
is not necessary to redefine the behavior of
the car class; this is inherited.
 Assume that all Fords use the same braking
system. In that case, the stop method would
be defined in class Ford (and not in Mustang
class), since it is a behavior shared by all
objects of class Ford. When you step on the
brake pedal of Mustang, you send a stop
message to the Mustang object. However,
the stop method is not defined in the
Mustang class, so the hierarchy is searched
until stop method is found. The stop method
is found in the Ford class, a super class the
Mustang class, and it is invoked (see Figure
2-6)

INHERITANCE EXAMPLE
 Suppose that most Ford cars use the same braking system, but the Thunder bird has its own antilock braking system. In this
case, the Thunderbird class would redefine the stop method. Therefore, the stop method of the Ford class would never be
invoked by a Thunderbird object. However, its existence higher up in the class hierarchy causes no conflict, and other Ford
cars will continue to use the standard braking system.
 Dynamic inheritance allows objects to change and evolve over time, Since base classes provide properties and attributes for
objects, changing base classes changes the properties and attributes of a class.
 More specifically, dynamic inheritance refers to the ability to add, delete, or change parents from objects (or classes)at Run
time.

MULTIPLE INHERITANCE
 Some 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.
 For example, a utility vehicle inherits attributes from both the Car and Truck
classes (see Figure 2-7)
 Multiple inheritance has been a controversial issue for many years, with
opponents pointing to its increased complexity and ambiguity in situations
such as the "diamond problem", where it may be ambiguous as to which
parent class a particular feature is inherited from if more than one parent
class implements same feature.
 Multiple inheritance can pose some difficulties. For example, several distinct
parent classes can declare a member within a multiple inheritance hierarchy.
 This can become an issue of choice, particularly when several super classes
define the same method.
 One way of achieving the benefits of multiple inheritance in a language with
single inheritance is to inherit from the most appropriate class and then add
an object of another class as an attribute.

Date: 15-03-2022(MONDAY)
Time:11.00-12.00.
LECTURE 7: POLMORPHISM,ABSTRACTION

POLYMORPHISM
 Poly means “many” and morph means “form.” In the context of object-oriented systems, it means objects that can take on
or assume many different forms.
 Polymorphism means that the same operation may behave differently on different cases.
 Polymorphism means having vivid or different forms. In the programming world, Polymorphism refers to the ability of the
function with the same name to carry different functionality altogether. It creates a structure that can use many forms of
objects.
 In other words, polymorphism allows you to define one interface and have multiple implementations.
 A person at the same time can have different characteristic. Like a man at the same time is a father, a husband, an
employee. So the same person posses different behavior in different situations. This is called polymorphism.
 A software engineer can perform different task at different instance of time depending on the task assigned to him . He can
do coding , testing , analysis and designing depending on the task assign and the requirement.

POLYMORPHISM
 For example, consider how driving an automobile with a manual transmission is different from driving a car with an
automatic transmission. The manual transmission requires you to operate the clutch and the shift, so in addition to all other
mechanical controls, you also need information on when to shift gears. Therefore, although driving is a behavior we
perform with all cars (and all motors vehicles), the specific behavior can be different, depending on the kind of car we are
driving.
 A car with an automatic transmission might implement its drive method to use information such as current speed, engine
RPM, and current gear. Another car might implement the drive method to use the same information but require additional
information, such as “the clutch is depressed. The method is the same for both cars, but the implementation invoked
depends on the type of car(or the class of object). This concept, termed polymorphism, is a fundamental concept of any
object-oriented system.
• Polymorphism allows us to write generic, reusable code more easily, because we can specify general instructions
and delegate the implementation details to the objects involved.
• Since no assumption is made about the class of an object that receives a message, fewer dependencies are needed in
the code and, therefore, maintenance is easier.
• For example, in a payroll system, manager, office worker, and production worker objects all will respond to the
compute payroll message, but the actual operations performed are object specific.

ABSTRACTION
 Abstraction is the concept of object-oriented programming that "shows" only essential
attributes and "hides" unnecessary information. The main purpose of abstraction is
hiding the unnecessary details from the users.
 A real time example of abstraction is “sending SMS”. When you need to send SMS from
your mobile, you only type the text and send the message. But you don’t know the
internal processing about the message delivery.
 Remote is a interface between user and tv which has buttons like 0 to 10 ,on /of etc. but
we don’t know circuits inside remote. User does not need to know. Just we use it.
 There are mainly two types of abstraction
1.Data Abstraction
2.Process Abstraction

ADVANTAGES OF ABSTRACTION
 Hides the underlying complexity of data.
 Helps avoid repetitive code.
 Presents only the signature of internal functionality.
 Gives flexibility to programmers to change the implementation of the abstract behavior.
 Partial abstraction (0-100%) can be achieved with abstract classes
 Total abstraction (100%) can be achieved with interfaces

DIFFERENCES BETWEEN ENCAPSULATION AND
ABSTRACTION
ABSTRACTION ENCAPSULATION
Abstraction is the method of hiding the unwanted
information.
Encapsulation is a method to hide the data in a single entity or
unit along with a method to protect information from outside.
Abstraction is implemented using abstract class and
interfaces.
Encapsulation is implemented by using access modifier i.e.
private, protected and public.
In abstraction, implementation complexities are hidden using
abstract classes and interfaces.
While in encapsulation, the data is hidden using methods of
getters and setters.
In abstraction, problems are solved at the design or interface
level.
While in encapsulation, problems are solved at the
implementation level.

TYPES OF RELATIONSHIPS IN OOP
 One of the advantages of Object-Oriented programming language is code reuse. This reusability is possible due to the
relationship b/w the classes.
Object oriented programming generally support 4 types of relationships that are:
1.Inheritance
2.Association,
3. Composition
4.Aggregation.
All these relationship is based on "is a" relationship, "has-a" relationship and "part-of" relationship.

TYPES OF RELATIONSHIPS IN OOP
1.A Manager(child class) “is a” type of employee(parent class)-
Inheritance
2.Manager “has a” swipe card to enter companies premises.(entities are
independent and have their own life span)-Association
3.HE has many workers under him.-(manager-owner/single owner)-
Aggregation
4.His salary depends on project success(project and manager are
dependent on each other)-Composition
5.Projects success depends on Manager.-Composition(The life cycle of
both the entities are same).

OBJECT RELATIONSHIPS AND ASSOCIATIONS
 Association represents the relationship between the objects and classes. In object-oriented programming, association defines a
relationship between classes of objects that allows one object instance to cause another to perform an action on its behalf.
 Association is a “has-a” type relationship. Association establish the relationship b/w two classes using through their objects.
 Essentially, an association relationship between two or more objects denotes a path of communication (also called a link)
between them so that one object can send a message to another. Objects of one class communicate with the objects of other
class to use the functionality/services provided by that object.
 For example, in the statement “a pilot can fly planes” can fly is the association between pilot and planes.
 Associations are bidirectional meaning they can be traversed in both the directions with different connotations.

ASSOCIATION
 An association may exist between objects of different types or between the objects of the same type means of the same
class.
 But the main point is, the lifetime of the instances of the two classes are independent of each other and there is no
ownership between two classes.
 The important issue with association is Cardinality which specifies how many instances of one class may relate to single
instance of associated class . It can be one-to-one, one-to-many, many-to many , many-to-one.
 Example:
 A person can have only one passport. That is a “one-to-one” relationship.
 The association between a Bank and Employee, a bank can have many employees, So it is a “one-to-many” relationship.
 Every city exists in exactly one state, but a state can have many cities, which is a “many-to-one” relationship.
 The association between a teacher and a student, multiple students can be associated with a single teacher and a single
student can also be associated with multiple teachers but both can be created or deleted independently. This is a “many-to-
many” relationship.

CONSUMER- PRODUCER ASSOCIATION
• A special form of association is a consumer-producer relationship, also known as a client-server association or a use
relationship.
• The consumer-producer relationship can be viewed as one-way interaction: One object requests the service of another
object.
• The object that makes the request is the consumer or client, and the object that receives the request and provides the service
is the producer or server.
• For example, we have a print object that prints the consumer object. The print producer provides the ability to print other
objects. Figure depicts the consumer-producer association.

AGGREGATION AND OBJECT CONTAINMENT
 Aggregation is a specialized form of association between two or more objects in which each object has its
own life cycle but there exists an ownership as well. An aggregate object is one which contains other objects.
 For example, an Airplane class would contain Engine, Wing, Tail, Crew objects. Sometimes the class
aggregation corresponds to physical containment in the model (like the airplane).
 Some objects may be composed of and may contain other objects. Since each object has an identity, one
object can refer to other objects. This is known as AGGREGATION, where an attribute can be an object
itself: A car object is an aggregation of engine, seat, wheels, and other objects.
 The relationships between objects participating in an aggregation cannot be reciprocal i.e., a department may
“own” an employee, but the employee does not own the department.

AGGREGATION AND OBJECT CONTAINMENT

OBJECT CONTAINMENT
 Objects that contain other objects are called complex or composite objects. There can be multiple levels of
containment, forming a containment hierarchy among objects.
Example: A bicycle design database
Fig: Containment hierarchy for bicycle-design database.
 Containment allows data to be viewed at different granularities by different users. E.g., wheel by wheel
designer , bicycle by a sales-person. The containment hierarchy is used to find all objects contained in
a bicycle object.
 In certain applications, an object may be contained in several objects. In such cases, the containment
relationship is represented by a DAG rather than by a hierarchy.

COMPOSITION
 Composition is a specialized form of aggregation. In composition, if the parent object is destroyed, then the
child objects also cease to exist.
 Composition is actually a strong type of aggregation and is sometimes referred to as a “death” relationship.
 Example :A house may be composed of one or more rooms. If the house is destroyed, then all of the rooms
that are part of the house are also destroyed.
 Like aggregation, composition is also a whole/part or parent/child relationship. However, in composition the
life cycle of the part or child is controlled by the whole or parent that owns it.

Time:09.45-10.25.
LECTURE 12:CASE STUDY

CASE STUDY- A PAYROLL PROGRAM
 Payroll program that processes employee records at a small manufacturing firm.
 The company has several classes of employees with particular payroll requirements and rules for processing
each.
 A company pays its employees on a weekly basis.
 The employees are of four types:
 Salaried employees are paid a fixed weekly salary regardless of the number of hours worked,
 hourly employees are paid by the hour and receive overtime pay for all hours worked in excess of 40 hours,
 commission employees are paid a percentage of their sales
 salaried-commission employees receive a base salary plus a percentage of their sales.

For the current pay period, the company has decided to reward salaried-commission employees by adding
10% to their base salaries. The company wants to implement a Java application that performs its payroll
calculations polymorphically.
•

STRUCTURED APPROACH
 The traditional structured analysis/structured design (SA/SD) approach relies on modeling the processes that
manipulate the given input data to produce the desired output.
 The first few steps in SA/SD involve creation of preliminary data flow diagrams and data modeling. Data
modeling is a systems development methodology concerned with the system's entities, their associations, and
their activities.
 Data modeling is accomplished through the use of entity-relationship diagrams.
 The SA/SD approach encourages the top-down design (also known as top-down decomposition or stepwise
refinement), characterized by moving from a general statement about the process involved in solving á
problem down toward more and more detailed statements about each specific task in the process.
 Top-down design works by continually refining a problem into simpler and simpler chunks. Each chunk is
analyzed and specified by itself, with little regard (if any) for the rest of the system. This, after all, is one
reason why top-down design is so effective at analyzing a problem. The method works well for the initial
design of a system and helps ensure that the specifications for the problem are met and solved. However, each
program element is designed with only a limited set of requirements in mind.

STRUCTURED APPROACH
 Once the system modelling and analysis is completed , then the design phase is initiated.
 In the design phase a number of issues has to be studied which includes
1. User interface design(input and output)
2. Hardware and Software(system platform ,operating system)
3. Data or database management issues
4. People and procedural issues(documentation and training)
5. Finally, implementing the system using the procedural programming language(C,FORTRAN,COBOL)

STRUCTURED APPROACH
In a procedural approach such as C or COBOL, the payroll program would include conditional logic to check
the employee code and compute the payroll accordingly:
FOR EVERY EMPLOYEE DO
BEGIN
IF employee= manager THEN
CALL computeManagerSalary
IF employee= office worker THEN
CALL computeOfficeWorkerSalaryemployee
IF employee= production worker THEN
CALL computeProduction Worker Salary
END

STRUCTURED APPROACH
If new classes of employees are added, such as temporary office workers ineligible for overtime or junior production
workers who receive an hourly wage plus a lower piece rate, then the main logic of the application must be modified to
accommodate these requirements.
FOR EVERY EMPLOYEE DO
BEGIN
IF employee= manager THEN
CALL computeManagerSalary
IF employee= office worker THEN
CALL computeOfficeWorkerSalaryemployee
IF employee= production worker THEN
CALL computeProduction Worker Salary
IF employee temporary office worker THEN
CALL compute Temporary Office Worker Salary
IF employee Junior production worker THEN
CALL compute Junior Production Worker Salary
END

LIMITATIONS OF STRUCTURED APPROACH
 The introduction of new classes of data with different needs requires changing the main logic of the program.
 It also may require the addition of new code in many different areas of the application.
 It limits a programmer's ability to reuse code, since each function or procedure is tied to the data on which it
operates.

Date: 18-08-2021(Wednesday)
Time:02.50-3.30.
LECTURE 13:CASE STUDY-OBJECT ORIENTED APPROACH

OBJECT ORIENTED APPROACH
 Object-oriented software development encourages to view the problem as a system of cooperative objects.
Object-oriented systems development consists of
 Object-oriented analysis.
 Object-oriented information modeling,
 Object-oriented design.
 Prototyping and implementation.
 Testing, iteration, and documentation.
 When developing an object-oriented ap plication, two basic questions always arise;
1.What objects does the application need?
2.What functionality should those objects have?

 The first task in object-oriented analysis is to find the class of objects that will compose the system. At the
first level of analysis, the physical entities in the system are identified. That is, who are the players and how
do they cooperate to do the work of the system.
 The following are the clues for finding the candidate classes and objects:
1.Persons: What role does a person play in the system?
For example, customers , employees of which the system needs to keep track
2.Places:These are physical locations, buildings, stores, sites or offices about which the system keeps
information.
3. Things or events : These are events, points in time that must be recorded.
For example, the system might need to remember when a customer makes an order; therefore, an order is an
object. Associated with things remembered are attributes such as who, what, when, where, how, or why.
For example, some of the data or attributes of order object are customer-ID (who), date-of-order (when), soup-
ID (what), and so on.

 Next step is to identify the hierarchical relation between super classes and subclasses. Another task in object-
oriented analysis is to identify the attributes (properties) of objects, such as color, cost, and manufacturer.
Identifying behavior (methods) is next.
 The main question to ask is What services must a class provide? The answer to the question allows us to
identify the methods a class must contain. Once the overall system's responsibilities and the information it
needs to remember is identified, each responsibility can be assigned to the class to which it logically belongs.
 The goal of object-oriented analysis is to identify objects and classes that support the problem domain and
system's requirements. Object-oriented design identifies and defines additional objects and classes that
support an implementation of the requirements.

The main program would be written
in a general way that looped through
all of the employees and sent a
message to each employee to calculate
its payroll:
FOR EVERY EMPLOYEE DOBEGIN
compute Payroll
END employee
If a new class of employee were added, a
class for that type of employee would have
to be created. This class would know how
to calculate its payroll. Unlike the
procedural approach, the main program
and other related parts of the program
would not have to be modified; changes
would be limited to the addition of a new
class.

CHAPTER-3
OBJECT ORIENTED SYSTEMS DEVELOPMENT
Object-Oriented Systems Development Life Cycle:
 Introduction;
 Software Development Process;
 Building High-Quality Software;
 Object-Oriented Systems Development: A Use Case Driven Approach;
 Reusability.

INTRODUCTION
 The essence of the software development process is that it consists of
 Analysis
 Design
 Implementation
 Testing
 Refinement to transform user’s needs into a software solution that satisfies those needs.
 Some people view software development process as interesting but feel it has little importance in
developing software.
 Dynamics of software development provides little room for such shortcuts, and bypasses have been less
than successful . The object oriented approach requires a more rigorous process to do things right.

THE SOFTWARE DEVELOPMENT PROCESS
 System development can be viewed as a process.
 Development itself, in essence, is a process of change, refinement, transformation, or addition to the existing
product.
 Within the process, it is possible to replace one subprocess with a new one, as long as the new subprocess has
the same interface as the old one, to allow it to fit into the process as a whole. With this method of change, it
is possible to adapt the new process.
 The process can be divided into small, interacting phases-subprocesses. The subprocesses must be defined
clearly so, allow each activity can be performed as independently of other subprocesses as possible.
 Each subprocess must have the following
1. A description in terms of how it works
2. Specification of the input required for the process
3. Specification of the output to be produced

Time:11.40-12.20.
LECTURE 14: SOFTWARE DEVELOPMENT LIFECYCLE

 The software development process can be divided into smaller, interacting sub processes.
 Generally software development can be seen as a series of transformations, where the output of one
transformation becomes the input of the subsequent transformation.

1.Transformation1(Analysis):
 Translates the user’s needs into system requirements and responsibilities.
 The way they use the system can provide insight into the user’s requirements.
 For example: one use of system might be analyzing an incentive payroll system, which will tell us that this
capacity will be included in the system requirements.
2.Transformation 2 (Design):
 Begins with a problem statement and ends with a detailed design that can be transformed into a operational
system.
 This transformation includes the bulk of the software development activity, including the definition of how
to build the software, its development, and its testing.
 It also includes design descriptions, the programs and the testing material.

3.Transformation 3(Implementation)
 refines the detailed design into the system deployment that will satisfy the user’s needs.
 This takes into account equipment, procedures, people, and the like.
 It represents embedding the software product within its operational environment.

WATERFALL MODEL
 An example of the software development process is the waterfall approach. The Waterfall Model was the first
Process Model to be introduced. It is also referred to as a linear-sequential life cycle model.
 It is very simple to understand and use. In a waterfall model, each phase must be completed before the next
phase can begin and there is no overlapping in the phases.
 The Waterfall model is the earliest SDLC approach that was used for software development.
 The waterfall Model illustrates the software development process in a linear sequential flow. This means that
any phase in the development process begins only if the previous phase is complete. In this waterfall model,
the phases do not overlap.
 In "The Waterfall" approach, the whole process of software development is divided into separate phases. In
this Waterfall model, typically, the outcome of one phase acts as the input for the next phase sequentially.

WATERFALL MODEL - APPLICATION
 Every software developed is different and requires a suitable SDLC approach to be followed based on
the internal and external factors. Some situations where the use of Waterfall model is most appropriate
are −
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.

WATERFALL MODEL - ADVANTAGES
 The advantages of waterfall development are that it allows for departmentalization and control. A schedule
can be set with deadlines for each stage of development and a product can proceed through the development
process model phases one by one.
 Development moves from concept, through design, implementation, testing, installation, troubleshooting, and
ends up at operation and maintenance. Each phase of development proceeds in strict order.
 Simple and easy to understand and use.
 Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented

WATERFALL MODEL -DISADVANTAGES
 The disadvantage of waterfall development is that it does not allow much reflection or revision. Once an
application is in the testing stage, it is very difficult to go back and change.
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and
uncertainty is high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.
 Integration is done as a "big-bang. at the very end, which doesn't allow identifying any technological or
business bottleneck or challenges early.

Time:11.40-12.20.

BUILDING HIGH-QUALITY SOFTWARE
 The software process transforms the users' needs via the application domain to a software solution that
satisfies those needs.
 High-quality products must meet users' needs and expectations.
 Furthermore, the products should attain this with minimal or no defects, the focus being on improving
products (or services) prior to delivery rather than correcting them after delivery.
 The ultimate goal of building high-quality software is user satisfaction.
 To achieve high quality in software we need to be to answer the following questions:
 How do we determine when the system is ready for delivery?
 Is it now an operational system that satisfies users' needs?
 Is it correct and operating as we thought it should?
 Does it pass an evaluation process?

 There are two basic approaches to systems testing.
 We can test a system according to how it has been built or, alternatively, what it should do.
 It describes a means of system evaluation in terms of four quality measures:
 Correspondence
 Correctness
 Verification
 Validation.

 Correspondence measures how well the delivered system matches the needs of the operational
environment, as described in the original requirements statement.
 Validation(the action of checking) is the task of predicting correspondence . True correspondence
cannot be determined until the system is in place.
 Correctness measures the consistency of the product requirements with respect to the design
specification.
 Verification(the process of establishing accuracy) is the exercise of determining correctness.
However, correctness always is objective.0
Example: Given the specification and the product , it should be possible to determine if the product
precisely satisfies the requirements of specifications.
 Validation, however, is always subjective, and it addresses a different issue— the appropriateness of
the specification.[uncovering the user needs , proper design]

Boehm observes that these quality measures, verification and validation, answer the following questions:
 Verification. Am I building the product right?
 Validation. Am I building the right product?
 Validation begins as soon as the project starts, but verification can begin only after a specification
has been accepted.
 Verification and validation are independent of each other.
 It is possible to have a product that corresponds to the specification, but if the specification proves to
be incorrect, we do not have the right product.

DIFFERENCE BETWEEN VERIFICATION AND VALIDATION
Verification Validation
It includes checking documents, design, codes
and programs.
It includes testing and validating the actual
product.
Verification is the static testing. Validation is the dynamic testing.
It does not include the execution of the code. It includes the execution of the code.
Methods used in verification are reviews,
walkthroughs, inspections and desk-checking.
Methods used in validation are Black Box
Testing, White Box Testing and non-functional
testing.
It checks whether the software conforms to
specifications or not.
It checks whether the software meets the
requirements and expectations of a customer or
not.
It can find the bugs in the early stage of the
development.
It can only find the bugs that could not be found
by the verification process.
The goal of verification is application and
software architecture and specification.
The goal of validation is an actual product.

DIFFERENCE BETWEEN VERIFICATION AND VALIDATION
It comes before validation. It comes after verification.
It consists of checking of documents/files and is
performed by human.
It consists of execution of program and is performed by
computer.

Time:09.45-10.25.

OBJECT-ORIENTED SYSTEMS DEVELOPMENT:A USE CASE
DRIVEN APPROACH
 The object oriented software development life cycle(SDLC) consists of three macro processes:
 Object-oriented analysis
 Object-oriented design
 Object-oriented implementation
 Use-case model can be employed throughout most activities of software development . By following
Jacobson and Ericson lifecycle model ,
 designs that are traceable across requirements, analysis, design, implementation & testing can be
produced
 all design decisions can be traced back directly to user requirements usage scenarios can be test
scenarios
 Usage Scenarios can become test scenarios.

OBJECT ORIENTED SYSTEMS DEVELOPMENT APPROACH

JACOBSON & ERICSON LIFE CYCLE MODEL

OBJECT ORIENTED SYSTEM DEVELOPMENT
Object-Oriented system development includes the following activities
 Object-oriented analysis - use case driven
 Object-oriented design
 Prototyping
 Component-based development
 • Incremental testing
Encourages
 viewing of system as a system of cooperative objects
 incremental development

OBJECT ORIENTED ANALYSIS- USE CASE DRIVEN
 Use Case, is a name for a scenario to describe the user-computer system interaction.
 The object oriented analysis phase of software development is concerned with determining the system
requirements and identifying classes and their relationship to other classes in the problem domain.
 To understand the system requirements, we need to identify the users or the actors.
 Who are the actors and how do they use the system?
 Scenarios can help (in traditional development, it is treated informally, not fully documented)
 Jacobson introduces concept of use case scenario to describe user-computer system interaction.
 This concept worked so well that it became the primary element in the system development.
 The object-oriented community has adopted use cases to a remarkable degree.

 Scenarios are a great way of examining who does what in the interactions among objects and what role
they play; i.e., their interrelationships.
 This intersection among object’s roles to achieve a given goal is called collaboration.
 A use case is a typical interaction between a user and system that captures user’s goals and needs.
 Expressing these high-level processes and interactions with customers in a scenario and analyzing it
is referred to as use case modeling.
 The use case model represents the user’s view of the system or user’s needs.

 Typical interaction between user & system that captures users' goal & needs
 In simple usage, capture use case by talking to typical users, discussing various things they might want
to do with system can be used to examine who does what in interactions among objects , what role they
play, intersection among objects' role to achieve given goal is called collaboration.
 several scenarios (usual & unusual behavior, exceptions) needed to understand all aspects of
collaboration & all potential actions.
 use cased modeling expressing high level processes & interactions with customers in a scenario &
analyzing it gives system uses, system responsibilities
 developing use case is iterative when use case model is better understood & developed, start identifying
classes & create their relationship

 Identifying objects
 What are physical objects in system?
 Individuals , organizations, machines, units of information, pictures, whatever makes up application/ make sense in context
of real world
 objects help establish workable system- work iteratively between use-case & object models
 incentive payroll - employee, supervisor, office administrator, paycheck, product made, process used to make product
 Documentation
 80-20 rule
 80% work can be done with 20% documentation
 20% easily accessible, 80% available to few who needs to know
 modeling & documentation in separatable
 good modeling implies good documentation

OBJECT-ORIENTED DESIGN
 The goal of object-oriented design (OOD) is to design the classes identified during the analysis phase
and the user interface.
 During this phase, additional objects and classes that support implementation of the requirements are
identified and defined.
 For example, during the design phase ,the need to add objects for the user interface to the system
may arise(e.g., data entry windows, browse windows).
 Object-oriented design and object- oriented analysis are distinct disciplines, but they can be
intertwined.
 Object-oriented development is highly incremental; in other words, one can start with object-oriented
analysis, model it, create an object-oriented design, then do some more of each, again and
again, gradually refining and completing models of the system.

OBJECT-ORIENTED DESIGN
 First, build the object model based on objects and their relationships, then iterate and refine the model:
 Design and refine classes.
 Design and refine attributes.
 Design and refine methods.
 Design and refine structures.
 Design and refine associations.

GUIDELINES FOR OBJECT-ORIENTED DESIGN
 Reuse, rather than build, a new class. Know the existing classes.
 Design a large number of simple classes, rather than a small number of complex classes.
 Design methods.
 Critique what you have proposed. If possible, go back and refine the classes.

Date: 25-08-2021(Wednesday)
Time:2.50.40-3.30.
LECTURE 17: PROTOTYPING AND REUSABILITY

PROTOTYPING
 Although the object-oriented analysis and design describe the system features, it is important to
construct a prototype of some of the key system components shortly after the products are selected.
 It has been said "a picture may be worth a thousand words, but a prototype is worth a thousand
pictures" [author unknown].
 Prototype is a version of a software product developed in the early stages of the product’s life cycle
for specific, experimental purposes.
 A prototype enables you understand how easy or difficult it will be to implement some of the features
of the system.
 It also can give users a chance to comment on the usability and usefulness of the user interface
design and lets you assess the fit between the software tools selected, the functional specification,
and the user needs.

PROTOTYPING
 Prototyping can further define the use cases, and it actually makes use-case modeling much easier.
 Traditionally, prototyping was used as a "quick and dirty" way to test the design, user interface, and so
forth, something to be thrown away when the "industrial strength" version was developed.
 However, the new trend, such as using Rapid Application Development(RAD), is to refine
the prototype into the final product.
 Prototyping provides the developer a means to test and refine the user interface and increase the
usability of the system. As the underlying prototype design begins to become more consistent with the
application requirements, more details can be added to the application, again with further testing,
evaluation, and rebuilding, until all the application components work properly within the prototype
framework.

PROTOTYPING-TYPES
 Prototypes have been categorized in various ways:
 A horizontal prototype is a simulation of the interface (that is, it has the entire user interface that
will be in the full-featured system) but contains no functionality.
 This has the advantages of being very quick to implement, providing a good overall feel of the system,
and allowing users to evaluate the interface on the basis of their normal, expected perception of the
system.
 A vertical prototype is a subset of the system features with complete functionality.
 The principal advantage of this method is that the few implemented functions can be tested in
great depth.
 In practice, prototypes are a hybrid between horizontal and vertical.
 The major portions of the interface are established so the user can get the feel of the system, and
features having a high degree of risk are prototyped with much more functionality

PROTOTYPING-TYPES
 An analysis prototype is an aid for exploring the problem domain.
 This class of prototype is used to inform, the user and demonstrate the proof of a concept.
 It is not used as the basis of development, however, and is discarded when it has served its purpose.
 The final product will use the concepts exposed by the prototype, not its code.
 A domain prototype is an aid for the incremental development of the ultimate software
solution.
 It often is used as a tool for the staged delivery of subsystems to the users or other members of the
development team.
 It demonstrates the feasibility of the implementation and eventually will evolve into a deliverable
product.

DEVELOPING PROTOTYPES
 typical time from few days to few weeks
 Should be done parallel with preparation of functional specification
 Can result in modification of spec (some problems/features only obvious after prototype built)
 Should involve representation from all user groups that will be affected by project - To ascertain all that
the general structure of the prototype meets requirements established for overall design.
 Purpose of review
 Demonstrate that prototype has been developed according to spec & that final spec is appropriate.
 Collect info about errors & problems in systems, e.g. user interface problems that needs to be addressed
in the intermediate prototype stage.
 Give management & everyone connected with project glimpse of what technology can provide
 Evaluation easier if supporting data readily available
 Testing considerations must be incorporated in design & implementation of systems

IMPLEMENTATION:COMPONENT BASED DEVELOPMENT
 Manufacturers learned that benefits of moving from custom development to assembly from
prefabricated components.
 Components based manufacturing makes many products available to the marketplace that otherwise
would be expensive.
 Modern manufacturing has evolved to exploit two crucial factors underlying today’s market
requirements: reduce cost and time to market by building from prebuilt, ready- tested components.
 No more custom development, now assemble from prefabricated components
 No more cars, computers, etc. custom designed & built for each customer
 Can produce large markets, low cost, high quality products
 Cost & time reduced by building from pre-built, ready tested components
 Value & differentiation gained by rapid customization to targeted customers.

IMPLEMENTATION:COMPONENT BASED DEVELOPMENT
 Today’ software components are built and tested in-house, using a wide range of technologies like
CASE TOOLS.
Example : Computer-aided software engineering (CASE) tools allow their users to rapidly develop
information systems. The main goal of CASE technology is the automation of the entire information
system's development life cycle process using a set of integrated software tools, such as modeling,
methodology, and automatic code generation. However, most often, the code generated by CASE tools is
only the skeleton of an application and a lot needs to be filled in by programming by hand. A new
generation of CASE tools is beginning to support component-based development.

COMPONENT BASED DEVELOPMENT
 Component-based development (CBD) is an industrialized approach to the software development
process.
 Application development moves from custom development to assembly of prebuilt, pretested, reusable
software components that operate with each other.
 Two basic ideas underlie component-based development(CBD).
 First, the application development can be improved significantly if applications can be assembled
quickly from prefabricated software components.
 Second, an increasingly large collection of interpretable software components could be made available
to developers in both general and specialist catalogs.
 Put together, these two ideas move application development from a craft activity to an industrial process
fit to meet the needs of modern, highly dynamic, competitive, global businesses.

COMPONENT BASED DEVELOPMENT
 A CBD developer can assemble components to construct a complete software system.
 Components themselves may be constructed from other components and so on down to the level of
prebuilt components or old-fashioned code written in a language such as C, assembler, or COBOL.
 The impact to users will come from faster product development cycles, increased flexibility, and
improved customization features. CBD will allow independently developed applications to work
together and do so more efficiently and with less development effort.
 Existing (legacy) applications support critical services within an organization and therefore cannot be
thrown away. Massive rewriting from scratch is not a viable option, as most legacy applications are
complex, massive, and often poorly documented.
 The CBD approach to legacy integration involves application wrapping, in particular component
wrapping, technology. An application wrapper surrounds a complete system, both code and data. This
wrapper then provides an interface that can interact with both the legacy and the new software systems.

SOFTWARE COMPONENTS
 Functional units of programs, building block offering collection of reusable services
 A Software Component Can request service form another component or deliver its own services on
request.
 Delivery of services are independent, component work together to accomplish task . Components can
depend on one another without interfering one another.
 Each component is unaware of context/inner workings of other components
 OO concept - analysis, design, programming
 Component-based-implementation, system integration

RAPID APPLICATION DEVELOPMENT
 Rapid application development (RAD) is a set of tools and techniques that can be used to build an
application faster than typically possible with traditional methods.
 The term often is used in conjunction with software prototyping .
 It is widely held that, to achieve, RAD, the developer sacrifices the quality of the product for a quicker
delivery.
 This is not necessarily the case. RAD is concerned primarily with reducing the "time to market," not
exclusively the software development time.
 RAD does not replace the system development life cycle but complements it, since it focuses more on
process description and can be combined perfectly with the object-oriented approach.
 The task of RAD is to build the application quickly and incrementally implement the design and user
requirements, through tools such as Delphi ,VisualAge , Visual Basic, or PowerBuilder.

INCREMENTAL TESTING
 Software development and all of its activities including testing are an iterative process.
 Waiting until after development to test is waste of money & time.
 The problem was that developers would turn over applications to a quality assurance (QA) group for
testing only after development was completed.
 Turning over applications to quality assurance group will not help since they are not included in initial
plan.
 At Bankers Trust in 1992: "Our testing was very complete and good, but it was costing a lot of
money and would add months onto a project," says Glenn Shimamoto, vice president of technology
and strategic planning at the New York bank.

REUSABILITY
 A major benefit of object-oriented system development is reusability, and this is the most difficult
promise to deliver on.
 For an object to be really reusable, much more effort must be spent designing it.
 To deliver a reusable object, the development team must have the up-front time to design reusability
into the object.
 The potential benefits of reuse are clear: increased reliability, reduced time and cost for development,
and improved consistency.
 Effectively evaluate existing software components
 Has my problem been solved?
 Has my problem been partially solved?
 What has been done before to solve problem similar to this one?

REUSABILITY
 Need detailed summary info about existing software components
 Some kind of search mechanism
 Define candidate object
 Generate broadly/narrowly defined query
 The reuse strategy can be based on the following:
 Information hiding (encapsulation).
 Conformance to naming standards.
 Creation and administration of an object repository.
 Encouragement by strategic management of reuse as opposed to constant redevelopment.
 Establishing targets for a percentage of the objects in the project to be reused (i.e., 50 percent reuse of
objects).

OODJ-MODULE 1.pptx

Recommended

Recommended

More Related Content

Similar to OODJ-MODULE 1.pptx

Similar to OODJ-MODULE 1.pptx (20)

Recently uploaded

Recently uploaded (20)

OODJ-MODULE 1.pptx