Raj Kumar Goel Institute of Technology, Ghaziabad

Object Oriented Analysis, Object Oriented

Programming Style

Unit: III
Object Oriented Programming

Mandeep Singh
B Tech 6th Semester Assistant Professor
CSE Department

1
 Faculty Information
Faculty Information

• Name: Mr. Mandeep Singh

• Qualification : Ph.D. (P), M. Tech (IS), B.TECH(CSE)

• Teaching Experience: 8 years

• Designation: Assistant Professor

• Area of Interest: WSN, MANETs, IoT, ML

• E-Mail: [email protected]

24-03-2023 Mr. Mandeep Singh Unit -3 2

Subject Syllabus

3
 Course Objective

At the end of the semester, the student will be able to:

• Understand the functionality and basic concepts of object oriented design
techniques.
• Understand and apply various object oriented features like inheritance, data
abstraction, encapsulation and polymorphism to solve various computing
problems.
• Appreciate the dynamic memory allocation functions, access specifiers and the
friend functions.
• Understanding the basics of C and C++.
• Implementing the subprogram call and return.

4
 Course Outcome

• Understand the application development and analyze the insights of object

oriented programming to implement application
• Understand, analyze and apply the role of overall modeling concepts (i.e.
System, structural).
• Understand, analyze and apply oops concepts (i.e. abstraction, inheritance).
• Understand the basic concepts of C++ to implement the object oriented
concepts.
• To understand the object oriented approach to implement real world
problem.

5
 Program Outcome

1. Engineering knowledge: Apply the knowledge of mathematics, science,

engineering fundamentals, and an engineering specialization for the solution of
complex engineering problems.
2. Problem analysis: Identify, formulate, research literature, and analyze complex
engineering problems reaching substantiated conclusions using first principles of
mathematics, natural sciences, and engineering sciences.
3. Design/development of solutions: Design solutions for complex engineering
problems and design system components or processes that meet the specified
needs with appropriate consideration for public health and safety, and cultural,
societal, and environmental considerations.
4. Conduct investigations of complex problems: Use research based knowledge and
research methods including design of experiments, analysis and interpretation of
data, and synthesis of information to provide valid conclusions.
5. Modern tool usage: Create, select, and apply appropriate techniques, resources,
and modern engineering and IT tools, including prediction and modeling to complex
engineering activities, with an understanding of the limitations.

6
6. The engineer and society: Apply reasoning informed by the contextual knowledge
to assess societal, health, safety, legal and cultural issues and the consequent
responsibilities relevant to the professional engineering practice.
7. Environment and sustainability: Understand the impact of the professional
engineering solutions in societal and environmental contexts, and demonstrate the
knowledge of, and need for sustainable development.
8. Ethics: Apply ethical principles and commit to professional ethics and
responsibilities and norms of the engineering practice.
9. Individual and team work: Function effectively as an individual, and as a member
or leader in diverse teams, and in multidisciplinary settings.
10. Communication: Communicate effectively on complex engineering activities with
the engineering community and with the society at large, such as, being able to
comprehend and write effective reports and design documentation, make effective
presentations, and give and receive clear instructions.
11. Project management and finance: Demonstrate knowledge and understanding of
the engineering and management principles and apply these to one’s own work, as a
member and leader in a team, to manage projects and in multidisciplinary
environments.
12. Life-long learning: Recognize the need for, and have the preparation and ability to
engage in independent and life-long learning in the broadest context of technological
change.

7
 CO-PO Mapping

CO PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO10 PO11 PO12 PSO1 PSO2

2 2 2 1 2 2 - - - - - 2 2 2
CO1
2 2 3 1 2 2 - - - - - 2 2 2
CO2
2 2 2 1 2 1 1 - - - - 2 2 2
CO3
2 2 2 1 2 - 1 - - - - 2 2 2
CO4
2 2 3 1 2 - - - - - - 2 2 2
CO5
2 2 2.4 1 2 1.6 1 - - - - 2 2 2
CO

8
 Brief Introduction about the Subject with Videos

Videos: https://www.youtube.com/watch?v=LpU2h-4iEys
https://www.youtube.com/watch?v=hozM7JhFFXg

9
 Prerequisites and Revision

In the Unit-1 students learnt the basic functionality and basic concepts of object
oriented design techniques and UML modelling.

In Unit-2, the students will understand the Structural model: a view of an system,
that emphasizes the structure of the objects, including their classifiers,
relationships, attributes and operations and the structural relationships.

In Unit-3, the students will understand the concept of object oriented design and
object oriented programming style: models, algorithms, concept of SA/SD, JSD

10
 Object oriented design

Object oriented design:

• The stages for object–oriented design can be iden fied as −
• Definition of the context of the system
• Designing system architecture
• Identification of the objects in the system
• Construction of design models
• Specification of object interfaces
Object design:
• Object design includes the following phases −
• Object identification
• Object representation, i.e., construction of design models
• Classification of operations
• Algorithm design
• Design of relationships
• Implementation of control for external interactions
• Package classes and associations into modules

11
 Object oriented design
Object Identification
• The first step of object design is object identification. The objects identified in
the object–oriented analysis phases are grouped into classes and refined so
that they are suitable for actual implementation.
• The func ons of this stage are −  Identifying and refining the classes in each
subsystem or package  Defining the links and associations between the
classes  Designing the hierarchical associations among the classes, i.e., the
generalization/specialization and inheritances  Designing aggregations.
Object Representation:
• Once the classes are identified, they need to be represented using object
modeling techniques. This stage essentially involves constructing UML
diagrams. There are two types of design models that need to be produced −
• Static Models − To describe the static structure of a system using class
diagrams and object diagrams.
• Dynamic Models − To describe the dynamic structure of a system and show the
interaction between classes using interaction diagrams and state–chart
diagrams
12
 Classification of Operations

Classification of Operations:
• In this step, the operation to be performed on objects are defined by
combining the three models developed in the OOA phase, namely, object
model, dynamic model, and functional model. An operation specifies what
is to be done and not how it should be done.
• The following tasks are performed regarding operations −
• The state transition diagram of each object in the system is developed.
• Operations are defined for the events received by the objects.
• Cases in which one event triggers other events in same or different objects
are identified.
• The sub–operations within the actions are identified.  The main actions
are expanded to data flow diagrams.

13
 Algorithm Design

Algorithm Design:
• The operations in the objects are defined using algorithms. An algorithm
is a stepwise procedure that solves the problem laid down in an
operation. Algorithms focus on how it is to be done. There may be more
than one algorithm corresponding to a given operation. Once the
alternative algorithms are identified, the optimal algorithm is selected for
the given problem domain. The metrics for choosing the optimal
algorithm are −
• Computa onal Complexity − Complexity determines the efficiency of an
algorithm in terms of computation time and memory requirements.
• Flexibility − Flexibility determines whether the chosen algorithm can be
implemented suitably, without loss of appropriateness in various
environments
• Understandability − This determines whether the chosen algorithm is easy
to understand and implement.

14
 Design of Relationships

Design of Relationships
• The strategy to implement the relationships needs to be chalked out during
the object design phase. The main relationships that are addressed comprise
of associations, aggregations, and inheritances.
• The designer should do the following regarding associations −
• Identify whether an association is unidirectional or bidirectional.
• Analyze the path of associations and update them if necessary.
• Implement the associations as a distinct object, in case of many–to-many
relationships; or as a link to other object in case of one–to-one or one–to
many relationships.
• Regarding inheritances, the designer should do the following −
• Adjust the classes and their associations.
• Identify abstract classes.
• Make provisions so that behaviors are shared when needed.

15
 Implementation of Control

• The object designer may incorporate refinements in the strategy of the state–chart
model. In system design, a basic strategy for realizing the dynamic model is made.
During object design, this strategy is aptly embellished for appropriate
implementation.
• The approaches for implementation of the dynamic model are −
• Represent State as a Location within a Program − This is the traditional procedure-
driven approach whereby the location of control defines the program state. A finite
state machine can be implemented as a program. A transition forms an input
statement, the main control path forms the sequence of instructions, the branches
form the conditions, and the backward paths form the loops or iterations.
• State Machine Engine − This approach directly represents a state machine through
a state machine engine class. This class executes the state machine through a set of
transitions and actions provided by the application
• Control as Concurrent Tasks − In this approach, an object is implemented as a task
in the programming language or the operating system. Here, an event is
implemented as an inter-task call. It preserves inherent concurrency of real objects.

16
 Packaging Classes
• In any large project, meticulous partitioning of an implementation into modules or
packages is important. During object design, classes and objects are grouped into
packages to enable multiple groups to work cooperatively on a project.
• The different aspects of packaging are −
• Hiding Internal Information from Outside View − It allows a class to be viewed as a
“black box” and permits class implementation to be changed without requiring any
clients of the class to modify code.
• Coherence of Elements − An element, such as a class, an opera on, or a module, is
coherent if it is organized on a consistent plan and all its parts are intrinsically
related so that they serve a common goal.
• Construction of Physical Modules − The following guidelines help while
construc ng physical modules −
• Classes in a module should represent similar things or components in the same
composite object. Closely connected classes should be in the same module.
Unconnected or weakly connected classes should be placed in separate modules.
Modules should have good cohesion, i.e., high cooperation among its components.
A module should have low coupling with other modules, i.e., interaction or
interdependence between modules should be minimum.

17
 Design Optimization

• The analysis model captures the logical information about the system, while the
design model adds details to support efficient information access. Before a
design is implemented, it should be optimized so as to make the implementation
more efficient. The aim of optimization is to minimize the cost in terms of time,
space, and other metrics.
• However, design optimization should not be excess, as ease of implementation,
maintainability, and extensibility are also important concerns. It is often seen
that a perfectly optimized design is more efficient but less readable and
reusable. So the designer must strike a balance between the two.
• The various things that may be done for design optimization are −
• Add redundant associations
• Omit non-usable associations
• Optimization of algorithms
• Save derived attributes to avoid re-computation of complex expressions

18
 Design Documentation

● Documentation is an essential part of any software development process

that records the procedure of making the software. The design decisions
need to be documented for any non–trivial software system for
transmitting the design to others.
● Though a secondary product, a good documentation is indispensable,
par cularly in the following areas −
● In designing software that is being developed by a number of developers.
● In iterative software development strategies.
● In developing subsequent versions of a software project.
● For evaluating a software.
● For finding conditions and areas of testing.
● For maintenance of the software.
A beneficial documentation should essentially include the following contents-
● High–level system architecture − Process diagrams and module diagrams.
● Key abstrac ons and mechanisms − Class diagrams and object diagrams.
● Scenarios that illustrate the behavior of the main aspects − Behavioural
diagrams

19
 Implementation of control

The features of a good documenta on are −

● Concise and at the same time, unambiguous, consistent, and complete
● Traceable to the system’s requirement specifications.
● Well-structured  Diagrammatic instead of descriptive
Implementation of control:
• The designer must refine the strategy for implementing the state-event
models present in the dynamic model.
• As part of system design, We will have chosen a basic strategy for realizing
the dynamic model.
• Now during object design, we must flesh out this strategy
• There are three basic approaches to implementing the dynamic model:
1. Using the location within the program to hold state (procedure-driven
system).
2. Direct implementation of a state machine mechanism (event-driven
system).
3. Using concurrent tasks

20
 Structured Analysis and Structured Design (SA/SD)

It software Engineering Methodology based on data flow diagrams. It is a

diagrammatic notation that is designed to help people understand the system.
The basic goal of SA/SD is to improve quality and reduce the risk of system
failure. It establishes concrete management specifications and documentation.
It focuses on the solidity, pliability, and maintainability of the system.

Important Features of SA/SD

• Basically, the approach of SA/SD is based on the Data Flow Diagram. It is
easy to understand SA/SD as it focuses on well-defined system boundary.
• SA/SD includes various variety of notations for formally specifying
software
• During the Analysis phase data flow diagrams, process specifications, data
dictionary ,state transition diagram and ER diagrams are used to logically
describe a system
• In the Design phase details are added to analysis model and DFDs are
converted to structure charts

21
 Basic Structural
Structured Analysis Modeling(CO2)
and Structured Design (SA/SD)

Structured Analysis
• DFDs consists of Processes, data flows, actors, and data stores
• Data dictionary contains details missing from DFDs
• State transition diagrams models time dependent behavior similar to dynamic
models. State diagrams defines the timings of function Execution and data access
triggered by the events
• ER diagrams are based on object modeling.

22
 Basic Structural
Structured Analysis Modeling(CO2)
and Structured Design (SA/SD)

Structured Design
• Structured design follows structured analysis and addresses low level details
• During structure design DFDs are grouped into task and allocated to operating system
processes and CPU
• Data flow diagrams processes are converted into programming language functions and
structure chart is created

SA/SD is combined known as SAD and it mainly focuses on the following 3 points:
1. System
2. Process
3. Technology

23
 SA/SD PHASES

1. Analysis Phase :

• Analysis Phase involves data flow diagram, data dictionary, state transition diagram,

and entity-relationship diagram.

• In the data flow diagram, the model describes how the data flows through the system.

• We can incorporate the Boolean operators and & or link data flow when more than

one data flow may be input or output from a process .

• For example, if we have to choose between two paths of a process we can add an

operator or and if two data flows are necessary for a process we can add an operator.

The input of the process “check-order” needs the credit information and order

information whereas the output of the process would be a cash-order or a good-

credit-order 24
 Basic
SA/SDStructural
PHASES Modeling(CO2)

2. State transition diagram

• It is similar to the dynamic model. It specifies how much time the function will take

to execute and data access triggered by events.

• It also describes all of the states that an object can have, the events under which an

object changes state, the conditions that must be fulfilled before the transition will

occur and the activities were undertaken during the life of an object.

• It is basically used in database design. It basically describes the relationship

between different entities.

25
 Basic
SA/SDStructural
PHASES Modeling(CO2)

3. Data dictionary

• The content that is not described in the DFD is described in the data

dictionary. It defines the data store and relevant meaning.

• A physical data dictionary for data elements that flow between processes,

between entities, and between processes and entities may be included.

• This would also include descriptions of data elements that flow external to

the data stores.

• A logical data dictionary may also be included for each such data element.

All system names, whether they are names of entities, types, relations,

attributes, or services, should be entered in the dictionary.

26
 Basic
SA/SDStructural
PHASES Modeling(CO2)

4. Design Phase
• Design Phase involves structure chart and pseudocode.
1. Structure Chart:
• It is created by the data flow diagram. Structure Chart specifies how DFS’s
processes are grouped into tasks and allocate to the CPU.
• The structured chart does not show the working and internal structure of
the processes or modules and does not show the relationship between data
or data-flows. Similar to other SASD tools, it is time and cost-independent
and there is no error-checking technique associated with this tool.
• The modules of a structured chart are arranged arbitrarily and any process
from a DFD can be chosen as the central transform depending on the
analysts’ own perception. The structured chart is difficult to amend, verify,
maintain, and check for completeness and consistency.

27
 Basic
SA/SDStructural
PHASES Modeling(CO2)

Pseudo Code:

It is the actual implementation of the system. It is an informal way of

programming that doesn’t require any specific programming language or
technology.
A pseudocode does not conform to any programming language and expresses
logic in plain English.
⮚ It may specify the physical programming logic without actual coding
during and after the physical design.
⮚ It is used in conjunction with structured programming.
⮚ It replaces the flowcharts of a program.

28
 Basic
SA/SDStructural
PHASES Modeling(CO2)

Guidelines for Selecting Appropriate Tools

We May use following guidelines for selecting the most appropriate tool that would
suit your requirements −

⮚ Use DFD at high or low level analysis for providing good system
documentations.
⮚ Use data dictionary to simplify the structure for meeting the data requirement of
the system.
⮚ Use structured English if there are many loops and actions are complex.
⮚ Use decision tables when there are a large number of conditions to check and
logic is complex.
⮚ Use decision trees when sequencing of conditions is important and if there are
few conditions to be tested.

29
 Jackson Structured Development (JSD)

• JSD does not distinguish between analysis and design instead lumps both
phases together as specification.
• JSD divides system development into two stages specification then
implementation.
• JSD first determines what and the How.
• JSD is intended specially for applications in which timing is important.
• JSD is less graphically oriented than SA/SD and OMT.
• Jackson Structured Development (JSD) is a method of system development
that covers the software life cycle either directly or by providing a
framework into which more specialized techniques can fit.
• JSD can start from the stage in a project when there is only a general
statement of requirements. However many projects that have used JSD
actually started slightly later in the life cycle, doing the first steps largely
from existing documents rather than directly with the users.

30
 Phases Of Jackson System Development (JSD)

Modelling Phase:
In the modelling phase of JSD, the designer creates a collection of entity
structure diagrams and identifies the entities in the system, the actions they
perform, the attributes of the actions and the time order of the actions in the
life of the entities.
Specification Phase: This phase focuses on actually what is to be done?
Previous phase provides the basic for this phase. An sufficient model of a
time-ordered world must itself be time-ordered. Major goal is to map progress
in the real world on progress in the system that models it.

Implementation Phase: In the implementation phase JSD determines how to

obtain the required functionality. Implementation way of the system is based
on the transformation of the specification into an efficient set of processes. The
processes involved in it should be designed in such a manner that it would be
possible to run them on available software and hardware.

31
 JSD Steps:

Initially there were six steps when it was originally presented by Jackson, they
were as below:
1. Entity/Action step
2. Initial Model step
3. Interactive Function step
4. Information Function step
5. System Timing step
6. System Implementation step
Later some steps were combined to create method with only three steps:
1. Modelling Step
2. Network Step
3. Implementation Step

32
During Entity action step the software developer lists entities and actions for the part
of real world
Example : Jackson Elevator control System
• The Elevator control system controls two elevators Which service six floors.
Each elevator has six inside buttons one for each floor. Each floor has up and down
buttons in the waiting area.
Jackson identifies two entities for the elevator control
a. Button
b. Elevator
He identifies three actions
a. Press a button
b. Elevator arrives at floor n
c. Elevator leaves floor n

33
The Entity structure step Partially orders the action of each entity by time .
the elevator control system illustrate the importance of ordering actions
.it is permissible for an elevator to arrive at floor 3 leaving floor 3 , arrive at floor
2, leave floor 2 and so on. It does not make sense for two arrived actions to occur
in succession; arrive and leave operations must be alternate.

The Initial Model step states how the real world connects to the abstract
model.JSD supports state vector and data stream connection
The elevator user does not want the control system to remember each button
pressed and send an elevator fine to service request .the JSD model of the
computer system is unaware of the number of presses and only communicates
with the real world in the “up-flag.
Function step: It uses pseudo code to state output of actions. At the end of this
step the developer has a complete specification of the required system in the
elevator example, turning the display panel lights on or off as an elevator arrives
at each floor is a function that must be specified.

34
System timing step: this step considers how much the model is
permitted to lag the real world. For the most part, the result of the
timing step is a set of informal notes on performance constraints. For
example an elevator control system must detect when up and down
buttons are pressed.

Implementation step: this focuses on the problems of process

scheduling and allocates processors to processes. The number of
processes may be different from the number of processors.
Jackson’s elevator control model has 50processes. The developer
must decide whether to match each process to one or50 CPU or how
to get several processes to share the same CPU. After the sixJSD steps
comes writing of code and database design.

35
 Merits of JSD

1. It is designed to solve the real-time problems.

2. JSD modelling focuses on time.
3. It considers simultaneous processing and timing.
4. Provides functionality in the real world.
5. It is a better approach for microcode applications.

36
 Demerits of JSD:

1. It is a poor methodology for high level analysis and database design.

2. JSD is a complex methodology due to pseudo code representation.
3. It is less graphically oriented as compared to SA/SD or OMT.
4. It is a bit complex and difficult to understand.

37
 Video Links and Reference

• https://www.youtube.com/watch?v=-DP1i2ZU9gk
• https://nptel.ac.in/courses/106105224/
• https://nptel.ac.in/noc/courses/noc21/SEM2/noc21-cs57/
• James Rumbaugh et. al, “Object Oriented Modeling and Design”, PHI
• Grady Booch, James Rumbaugh, Ivar Jacobson, “The Unified Modeling
Language User Guide”, Pearson Education
• Object Oriented Programming With C++, E Balagurusamy, TMH
• C++ Programming, Black Book, Steven Holzner, dreamtech
• Object Oriented Programming in Turbo C++, Robert Lafore, Galgotia
• Object Oriented Programming with ANSI and Turbo C++, Ashok Kamthane,
Pearson
• The Complete Reference C++, Herbert Schlitz, TMH

38
Thank
You.

39