Subject Syllabus 1

Course Objective
2
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.
 Course Outcome
3
 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.
 Program Outcome
4
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. The engineer and society: Apply reasoning informed by the contextual knowledge to
assess societal, health, safety, legal and cultural issues and the consequent 5
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.
 CO-PO Mapping
6

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
 Brief Introduction about the Subject with Videos

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

7
 Prerequisites and Revision
8

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
 Object oriented design
9
Object oriented design:
 The stages for object–oriented design can be identified 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
 Object oriented design
10
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 functions 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
 Classification of Operations
11
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.
 Algorithm Design
12
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 −
 Computational 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.
 Design of Relationships
13
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.
 Implementation of Control
14
 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.
 Packaging Classes 15
 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 operation, 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
constructing 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.
 Design Optimization
16
 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
 Design Documentation
17
● 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,
particularly 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 abstractions and mechanisms − Class diagrams and object diagrams.
● Scenarios that illustrate the behavior of the main aspects − Behavioural
diagrams
 Implementation of control
18
The features of a good documentation 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
 Structured Analysis and Structured Design (SA/SD)
19

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
 Basic Structural
Structured Analysis Modeling(CO2)
and Structured Design (SA/SD)
20

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.
 Basic Structural
Structured Analysis Modeling(CO2)
and Structured Design (SA/SD)
21
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
 SA/SD PHASES
22

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
 Basic
SA/SDStructural
PHASES Modeling(CO2)
23
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.

 Basic
SA/SDStructural
PHASES Modeling(CO2)
24
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.

 Basic
SA/SDStructural
PHASES Modeling(CO2)
25
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. 
 Basic
SA/SDStructural
PHASES Modeling(CO2)
26
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.
 Basic
SA/SDStructural
PHASES Modeling(CO2)
27
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.
 Jackson Structured Development (JSD) 28

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

 Phases Of Jackson System Development (JSD) 29

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. 
 JSD Steps:  30

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: 
7. Modelling Step 
8. Network Step 
9. Implementation Step
 31

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
c. Press a button
d. Elevator arrives at floor n
e. Elevator leaves floor n
 32

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

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.
 Merits of JSD 34

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. 
 Demerits of JSD: 35

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. 
 Video Links and Reference
36
• 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
 37

Thank You.