CT10708: Object Oriented

Programming using Java

Semester-B (Section-A)
Session Jan.- May 2026
 Systems

• Systems are constructed by interconnecting components (Boundaries,

Environments, Characters, Emergent Properties), which may well be
systems in their own right.
• The larger the number of these components and relationships between
them, higher will be the complexity of the overall system.
 Software Systems
• Software systems are not any different from other systems.
• They are also embedded within some operational environment, and perform
operations which are clearly defined and distinguished from the operations
of other systems in this environment.
• They also have properties which emerge from the interactions of their
components and/or the interactions of themselves with other systems in
their environment.
 Software Systems
• A system that embodies one or more software subsystems which contribute
to or control a significant part of its overall behavior is a software intensive
system.
• As examples of complex software-intensive systems:
stock and production control systems,
aviation systems,
rail systems,
banking systems, health care systems and so on.
 Complexity
Complexity depends on the number of the components embedded in software
as well as the relationships and the interactions between these components
which carry;
• Impossible for humans to comprehend fully
• Difficult to document and test
• Potentially inconsistent or incomplete
• Subject to change
• No fundamental laws to explain phenomena and approaches
 THE STRUCTURE OF COMPLEX SYSTEMS
Examples of Complex Systems:

• The structure of personal computer,

• plants and animals,
• matter,
• social institutions
are some examples of complex system.
 THE STRUCTURE OF COMPLEX SYSTEMS
The structure of a Personal Computer: A personal computer is a device of
moderate complexity. Major elements are CPU, monitor, keyboard and some
secondary storage devices. CPU encompasses primary memory, an ALU, and a
bus to which peripheral devices are attached. An ALU may be divided into
registers which are constructed from NAND gates, inverters and so on. All are
the hierarchical nature of a complex system.

The structure of Animals: Animals exhibit a multicultural hierarchical structure in

which collection of cells form tissues, tissues work together as organs, clusters
of organs define systems (such as the digestive system) and so on.
 THE STRUCTURE OF COMPLEX SYSTEMS
The structure of Plants: Plants are complex multicellular organism which are
composed of cells which is turn encompasses elements such as chloroplasts,
nucleus, and so on. For example, at the highest level of abstraction, roots are
responsible for absorbing water and minerals from the soil. Roots interact with
stems, which transport these raw materials up to the leaves. The leaves in turn
use water and minerals provided by stems to produce food through
photosynthesis.

The structure of Matter: Nuclear physicists are concerned with a structural

hierarchy of matter. Atoms are made up of electrons, protons and neutrons.
Elements and elementary particles but protons, neutrons and other particles are
formed from more basic components called quarks, which eventually formed
from pro-quarks.
 THE STRUCTURE OF COMPLEX SYSTEMS
The structure of Social institutions:

1. Institute/Universities
2. Education System in India
Education System in India
 THE INHERENT COMPLEXITY OF SOFTWARE
• Software may involve elements of great complexity which is of different kind.
Some software systems are simple:
Some Software Systems are Complex:
 Why Software is Inherently Complex?
The inherent complexity derives from four elements:
• the complexity of the problem domain,
• the difficultly of managing the developmental process,
• the flexibility possible through software and
• the problems of characterizing the behavior of discrete systems.
 The complexity of the problem domain
• Complex requirements
• Decay of system
 The complexity of the problem domain
• The first reason has to do with the relationship between the application
domains for which software systems are being constructed and the people
who develop them.
• Although software developers have the knowledge and skills required to
develop software they usually lack detailed knowledge of the application
domain of such systems.
• This affects their ability to understand and express accurately the
requirements for the system to be built which come from the particular
domain.
 The complexity of the problem domain
• Requirements evolve during the construction of the system as well as after
its delivery and thereby they impose a need for a continuous evolution of the
system.
• Complexity is often increased as a result of trying to preserve the
investments made in legacy applications.
• The components which address new requirements have to be integrated with
existing legacy applications.
• This results into interoperability problems caused by the heterogeneity of the
different components which introduce new complexities.
 The complexity of the problem domain
• Consider the requirement for the electronic systems of a multi-engine
aircraft, a cellular phone switching system or a cautious (traditional) robot.
• The row functionality of such systems is difficult enough to comprehend.
• External complexity usually springs from the impedance mismatch that exists
between the users of a system and its developers.
• Users may have only vague ideas of what they want in a software system.
• Users and developers have different perspectives on the nature of the
problem and make different assumptions regarding the nature of the system.
 The complexity of the problem domain
• A further complication is that the requirement of a software system often
change during its development. Once system is installed, the process helps
developers master the problem domain, enabling them to ask better
questions that illuminate the done existing system every time its
requirements change because a large software system is a capital
investment.
• It is software maintenance when we correct errors, evolution when we
respond to changing environments and preservations, when we continue to
use extraordinary means to keep an ancient and decaying piece of software
in operation.
Example: A large e-commerce platform like Amazon requires thousands of
developers working on various components (payment, inventory, user interface,
recommendation engine, etc.). Coordinating this team is a massive challenge.
 The Difficulty of Managing the Development Process
• Management problems
• Need of simplicity
 The Difficulty of Managing the Development Process
• Complex software intensive systems cannot be developed by single
individuals. They require teams of developers.
• This adds extra overhead to the process since the developers have to
communicate with each other about the intermediate artifacts they produce
and make them interoperable with each other.
• This complexity often gets even more difficult to handle if the teams do not
work in one location but are geographically dispersed.
 The Difficulty of Managing the Development Process
• In such situations, the management of these processes becomes an
important subtask on its own and they need to be kept as simple as possible.
• It is difficult to understand the system whose size is measured in hundreds of
thousands, or even millions of lines of code.
• Even if we decompose our implementation in meaningful ways, we still end
up with hundreds and sometimes even thousand modules.
• The amount of work demands the use of team of developers and there are
always significant challenges associated with team development more
developer’s means more complex communication and hence more difficult
coordination.
 The flexibility possible through software
• Software is flexible and expressive and thus encourages highly demanding
requirements, which in turn lead to complex implementations which are
difficult to assess.
• The third reason is the danger of flexibility.
• Flexibility leads to an attitude where developers develop system components
themselves rather than purchasing them from somewhere else.
• Unlike other industrial sectors, the production depth of the software industry
is very large. The construction or automobile industries largely rely on highly
specialized suppliers providing parts. The developers in these industries just
produce the design, the part specifications and assemble the parts delivered.
 The flexibility possible through software
• The software development is different: most of the software companies
develop every single component from scratch.
• Flexibility also triggers more demanding requirements which make products
even more complicated.
• Software offers the ultimate flexibility. It is highly unusual for a construction
firm to build an onsite steel mill to forge (create with hammer) custom
girders (beams) for a new building.
• Construction industry has standards for quality of raw materials, few such
standards exist in the software industry.
Example: In the automobile industry, car manufacturers use standard parts (tires,
engines, etc.) from suppliers. But in software, even a small app may have custom-built
modules for user authentication, database access, and UI rendering.
 The problem of characterizing the behavior of
discrete systems
• Numerous possible states
• Difficult to express all states
 The problem of characterizing the behavior of
discrete systems
• The final reason for complexity according to Booch is related to the difficulty
in describing the behavior of software systems.
• Humans are capable of describing the static structure and properties of
complex systems if they are properly decomposed, but have problems in
describing their behavior.
• This is because to describe behavior, it is not sufficient to list the properties
of the system. It is also necessary to describe the sequence of the values that
these properties take over time.
 The problem of characterizing the behavior of
discrete systems
• Within a large application, there may be hundreds or even thousands of
variables well as more than one thread of control.
• The entire collection of these variables as well as their current values and the
current address within the system constitute the present state of the system
with discrete states.
• Discrete systems by their very nature have a finite numbers of possible
states.
• What it means: Software is a discrete system, which means its state
changes in steps rather than continuously. Describing how software behaves
over time is a major challenge.

• Why it matters:
o While it is easy to describe the structure of a system (how parts are
connected), it is much harder to describe its behavior (how it reacts to
different inputs).
o Behavior is not just a list of properties but a sequence of state changes
over time.
Inherent Complexity of Software
1. Complexity of the problem domain: Requirements are often
inconsistent, vague, or frequently changing.
2. Difficulty of managing the development process: Large teams and
complex requirements create communication and coordination
overhead.
3. Flexibility possible through software: Software can meet demanding
requirements, which often leads to "feature creep".
4. Problems of characterizing the behavior of discrete systems: The
number of possible states in a software system can be massive and hard
to fully test or analyze.
 The Consequences of Unrestrained Complexity
• The more complex the system, the more open it is to total breakdown.
• Rarely would a builder think about adding a new sub-basement to an existing
100-story building; to do so would be very costly and would undoubtedly
invite failure.
• Amazingly, users of software systems rarely think twice about asking for
equivalent changes. Besides, they argue, it is only a simple matter of
programming.
 The Consequences of Unrestrained Complexity
• failure to master the complexity of software results in projects that are late, over
budget, and deficient in their stated requirements.
• this condition is called software crisis
• this crisis translates into the wasting of human resources - a most precious
commodity - as well as a considerable loss of opportunities.
• There are simply not enough good developers around to create all the new software
that users need.
• A significant number of the developmental personnel in any given organization must
often be dedicated to the maintenance or preservation of this software.
• Given the indirect as well as the direct contribution of software to the economic base
of most industrialized countries, and considering the ways in which software can
amplify the powers of the individual, it is unacceptable to allow this situation to
continue.
Symptoms for SD Problems
• Inaccurate understanding of end-user needs.
• Inability to deal with changing requirements.
• Modules that don’t fit together.
• Software that’s hard to maintain and/or extend.
• Late discovery of serious project flaws.
Symptoms for SD Problems (Contd.)
• Poor software quality.
• Unacceptable software performance.
• Team members in each other’s way are unable to reconstruct who
changed what, when, where, why.
• An untrustworthy build-and-release process.
Unfortunately, What happens is-

Treating symptoms does not treat the disease, e.g. Late discovery of
serious project flaws is only a symptom of larger problems.
We have to diagnose for the symptom i.e. subjective project status
assessment for above symptom.
Root Causes of SD Problems
• Insufficient requirement management.
• Ambiguous & imprecise communications.
• Brittle architecture.
• Overwhelming complexity.
• Undetected inconsistencies among requirement, designs, and
implementations.
Root Causes of SD Problems (Contd..)
• Insufficient Testing.
• Subjective project status assessment.
• Delayed risk reduction due to waterfall approach.
• Uncontrolled change preparation.
• Insufficient Automation.
Actually, what we should do-

We should attack these root causes (diagnosis) so that we are not

only in position to get rid off the system, but also we are in a better
position to provide quality to the software in a repeatable and
productive manner.
The Five Attributes of Complex Systems
Hierarchic Structure
Relative Primitive
Separation of Concerns
 Separation of Concerns

If the separation of concern was not possible then we would

not have been able to study, design and develop the subsystems
independently.

So this attribute is very critical from our object-oriented analysis

design context.
Common Patterns
Stable Intermediate Forms
 Stable Intermediate Forms
MATLAB system:
• need to represent numbers
• representing a number itself is a very complex concept because need to deal
with bits. The bits are finite in size, they will overflow, underflow. difficult to
handle, they are complex in nature while your primitive remains to be the
bits.
• Once you have built up these objects, numbers say integer, double, floating,
floating point numbers, complex numbers, fractional numbers and so on.
• Then you can use them to build bigger functionality now you are building up
matrices, now you are building up vectors
• So now the objects like a floating point number which looked very complex
and was not considered to be primitive, now in turn it will become primitive.
Attributes of Complex Systems
Complex systems usually share 5 key characteristics:

Hierarchy: Complex systems are almost always composed of interrelated subsystems.

Relative Primitives: What is considered "primitive" depends on the level of abstraction.

Separation of Concerns: Dividing systems into smaller, independent components makes

them easier to understand.

Common Patterns: Simple structures often reappear across different subsystems.

Stable Intermediate Forms: Hierarchical systems that work are almost always composed of
stable intermediate forms.
why complex systems are hard,
what well-designed complex systems look like,
and
why humans struggle to design them anyway
 Organized and Disorganized Complexity
• Understanding complex systems becomes much easier when we can
identify common abstractions and mechanisms. This is called organized
complexity.
• For example, an experienced pilot can step into a multiengine jet they’ve never
flown and safely operate it. This is possible because the pilot recognizes common
properties of all jets, such as how the rudder, ailerons, and throttle work. Once
these shared mechanisms are understood, the pilot only needs to learn the
unique features of that specific aircraft.

• By contrast, disorganized complexity occurs when a system has many

interacting parts with little obvious structure or pattern.
• For instance, when a software engineer first examines a large system, the parts
may seem unrelated and highly intricate, with no apparent commonalities.
Initially, this makes the system overwhelming and hard to understand.
Disorganized complexity → everything seems unrelated, overwhelming,
chaotic

Organized complexity → structure, patterns, hierarchy, reuse

The goal of good design is to turn disorganized complexity into organized

complexity.
 Class
• “A class is a user-defined data type that bundles data (attributes/state) and
functions (methods/behavior) that operate on that data, serving as a
blueprint for creating objects.”
— Grady Booch, Object-Oriented Analysis and Design

• A class is a template or blueprint for creating objects. It defines what state

(attributes) and what behavior (methods) its objects will have. Identity is not
part of the class; it comes when an object is created.
Concept Class Perspective Object Perspective
Identity Not defined in the class Each object has a unique identity
(e.g., account number)

State Defines attributes that Object stores actual values of

objects will have attributes (e.g., balance = 5000)

Behavior Defines methods that objects Object can perform these

can use methods (deposit(), withdraw())
class Account:
Attributes: accountNumber, balance, accountType
Methods: deposit(), withdraw(), checkBalance()
 Two essential hierarchies in complex systems
A. Object structure (“part of” hierarchy) B. Class structure (“is a” hierarchy)
What the system is made of What kind of thing something is
Example: Example:
Aircraft Engine - Jet engine
- Flight-control system - Turbofan engine
- Autopilot - Pratt & Whitney TF30
- Seats • This is generalization / specialization.
• This is composition. • The jet engine class captures properties
• Each object is a concrete instance of a common to all jet engines, while specialized
class, and objects collaborate at the same subclasses (like turbofan engines) define
level of abstraction. properties unique to that type.

❖ If you only model parts, you repeat yourself.

❖ If you only model types, you lose real-world structure.
❖ Good systems explicitly model both.
❖ Together, these two hierarchies are called the system’s architecture.
 Why Both Hierarchies Are Essential?

Object structure answers: What is the system made of?

Class structure answers: What kind of things exist in the system?

Studying only one gives an incomplete view Both together enable

understanding of complex systems
 The “canonical form” of complex systems
• standardized, abstract representation of a complex system that
captures the essential structure and relationships common to almost all
such systems.
When we combine:
• Class structure
• Object structure
• The five attributes of complex systems:
Hierarchy
Multiple levels of abstraction
Separation of concerns
Patterns
Stable intermediate forms
We get the canonical form of a complex system.
Why most software still fails?

Software is rarely on time, within budget, and correct unless these

principles are explicitly used.

But even knowing this, there is still struggle. Why?

 The real enemy: human cognitive limits
We can handle ~7 ± 2 chunks of information at once (Miller’s Law)
Each new chunk takes ~5 seconds to process (Simon)
Complex systems involve:
Many interacting parts,
Large state spaces,
Non-deterministic behavior
Result:
A single human cannot mentally hold the whole system.
Early in analysis, everything looks like:
Many parts
Many interactions
No obvious patterns
This is disorganized complexity, and it overwhelms.
There are fundamental limiting factors of human cognition;
This can be addressed through the use of decomposition, abstraction, and hierarchy.
 Decomposition
• Breaking a large system into smaller parts
• Each part handles a specific responsibility
• Makes complex systems easier to understand
 Algorithmic Decomposition
Definition: Algorithmic decomposition breaks a system into functions or
procedures, focusing on what the system does, not what it represents.
Characteristics:
• Function-centric
• Data and behavior are separate
• Easy to write initially for small programs
• Hard to maintain as system grows
Problem:
• Any change in data affects multiple functions
• Poor mapping to real-world objects
• Leads to high coupling and low modularity
 Algorithmic Decomposition
Example: Banking System
Functions: --deposit(account, amount) --withdraw(account, amount) --
checkBalance(account)
Account Data (shared globally): accountNumber, balance, accountType
Issues: Rules (like minimum balance) must be repeated in every function.
Adding new account types (Savings, Current) requires changing multiple
functions.
Hard to understand and maintain as the system grows.
 Object-Oriented Decomposition (OO)
Definition:OO decomposition divides a system into objects that encapsulate both
data and behavior, focusing on what the system is.
Characteristics:
Object-centric (represents real-world entities)
Combines data + methods
Promotes encapsulation, low coupling, high cohesion
Easy to extend, maintain, and reuse
 Object-Oriented Decomposition (OO)
Example: Banking System -→ (OO)Objects and Methods: Account
-- balance -- accountNumber
-- deposit(amount) -- withdraw(amount) --checkBalance()
Benefits:
Rules (like minimum balance) are inside Account object — change in
one place.
Adding new account types (Savings, Current) is simple using
inheritance.
Clear mapping to real-world entities → easier to understand.
 Categories of Analysis and Design Methods
•A method is a disciplined procedure for creating models of a software system
using defined notations.
•A methodology is a collection of methods applied across the software lifecycle,
unified by process, practices, and philosophy.

Methods are important because they:

•Introduce discipline in software development
•Provide common models for team communication
•Define milestones for tracking progress and managing risk
Most design methods fall into three categories:
• Top-down structured design – uses algorithmic decomposition and
focuses on functions and control flow

• Data-driven design – derives system structure from input-output data

relationships

• Object-oriented design – models systems as collections of cooperating

objects organized in class hierarchies
Categories of Analysis and Design Methods
Complex software systems are best managed using:
• Object-oriented decomposition
• Abstraction
• Hierarchy

These concepts together form the foundation for building

scalable, maintainable, and evolvable software systems.
 Abstraction
Abstraction is the process of focusing on essential characteristics while ignoring
unnecessary details.

•It addresses the limits of human cognition (7 ± 2 chunks of information).

•Through abstraction:
•Complex details are grouped into meaningful units
•Each unit carries higher semantic content
•Objects are powerful abstractions because they combine:
•Data (state)
•Operations (behavior)
•Abstraction enables humans to understand and manage complex systems
effectively.
 Hierarchy
• Hierarchy organizes abstractions into levels of increasing detail.

• Two kinds of hierarchies exist:

• Class hierarchy (is-a relationship) – shows generalization and specialization
• Object hierarchy (part-of relationship) – shows how objects collaborate and compose
systems

• Hierarchy helps by:

• Exposing common structure and behavior
• Reducing redundancy
• Simplifying understanding of large systems

• Identifying hierarchies reveals patterns that significantly reduce perceived complexity.

 References
• Object-Oriented Analysis and Design with Applications, Booch, 3rd Edition,
January 2009.
• Object Oriented Analysis and Design, IIT Kharagpur, Prof. Partha Pratim Das
Prof. Samiran Chattopadhyay Prof. Kausik Datta,
[Link]