3. Basics
SDLC (System Development Life Cycle)
a conceptual model used in project
management that describes the stages
involved in software system
development project
1. Problem Statement
2. Feasibility Study
3. Analysis
4. Design
5. Implementation
6. Validation and Verification
7. Operation, Support and Maintenance
4. Object Oriented System
◦ An Object-Oriented System is a way of designing and building software by thinking
about the real world.
◦ Instead of writing one big block of instructions, we break things down into small,
manageable pieces called objects — just like real-life things.
◦ We model the software system as a collection of interacting objects, where each object
represents a real or imaginary thing, with its own data and behavior.
◦ Object-Oriented Systems (OOS) are built around following basic elements:
◦ Objects
◦ Classes
◦ Attributes
◦ Methods
5. Object Oriented System
Objects
◦ Something that is like a real-world thing that has:
◦ Properties (something it has)
◦ Behaviors (something it does)
◦ Example:
A car.
Properties: color, brand, model, speed
Behaviors: start(), stop(), accelerate()
◦ In programming, when we say object, we mean a self-contained unit that holds data and
actions — just like a car does in real life.
7. Object Oriented System
Classes
◦ Something that defines the structure and behavior of objects
◦ A class can be thought of as a blueprint or a template for creating something
◦ Example: Imagine you're building a house. Before construction, you need a blueprint that defines:
◦ How many rooms it will have.
◦ Where the doors and windows go.
◦ What color the walls will be.
The blueprint isn’t the actual house—it’s just a plan.
◦ In programming, A class defines what an object will look like (its properties and actions).
Just like A Car class may define that every car has a color, brand, and can drive().
◦ A class does not occupy memory until an object is created from it.
9. Object Oriented System
Attributes
◦ Definition: Attributes represent the data or state of an object. They are variables that belong
to an object and describe its characteristics.
◦ Purpose: Store information about the object (e.g., name, age, color, size).
◦ Example: A Car object might have attributes like color, model, and speed. A Person object might have name,
age, and height.
Methods
◦ Definition: Methods define the actions or behaviors an object can perform. They are
functions associated with an object.
◦ Purpose: Modify attributes, interact with other objects, or perform computations.
◦ Example: A Car might have methods like accelerate(), brake(), or honk(). A Person might have
walk(), talk(), or eat().
10. Object Oriented System
Element Definition Purpose Example
Class
A blueprint/template for creating objects.
Defines structure and behavior.
Encapsulates data (attributes) and behavior
(methods).
class Car:
def __init__(self, brand):
self.brand = brand
Object An instance of a class (created from the
class blueprint).
Represents a specific entity with data and
actions.
my_car = Car("Tesla")
Attribute A variable that holds data/state of an
object (defined in a class).
Stores object-specific characteristics. my_car.brand (e.g., "Tesla")
Method
A function defined in a class that performs
actions or modifies object state. Defines object behavior.
class Car:
def honk(self):
print("Beep!")
my_car.honk()
11. Traditional Vs OO Software Engineering
1. Problem Statement
2. Feasibility Study
3. Analysis
4. Design
5. Implementation
6. Validation and Verification
7. Operation, Support and Maintenance
1. Problem Statement
2. Feasibility Study
3. OO Analysis
4. OO Design
5. OO Implementation
6. Validation and Verification
7. Operation, Support and Maintenance
13. Characteristics of OOS
Object-Oriented Systems (OOS) exhibit several key characteristics that make it a
popular development paradigm
◦ Modularity
◦ Encapsulation
◦ Inheritance
◦ Polymorphism
◦ Abstraction
◦ Reusability
◦ Maintainability
◦ Extensibility
14. Characteristics of OOS
Modularity
◦ OOS breaks down complex systems into smaller, manageable units called objects.
◦ This modularization enhances code organization and readability.
◦ Changes can be made to individual objects without affecting the entire system.
Encapsulation
◦ Data hiding
◦ Protects the internal state of an object from external access
◦ It helps prevent unauthorized access to sensitive data.
15. Characteristics of OOS
Inheritance
◦ Allows subclasses to inherit properties and methods from super-
classes, reducing code duplication.
◦ Creates a hierarchical relationship between classes, promoting a
clear understanding of the system.
◦ New features can be added by creating subclasses without
modifying existing code.
18. class Person {
String name;
String age;
void birthday () {
age = age + 1;
}
}
class Employee
extends Person {
double salary;
void pay () { ...}
}
Every Employee has a name, age, and birthday method as well as a salary and a pay
method.
Characteristics of OOS
Inheritance
19. Characteristics of OOS
Polymorphism
◦ Means that the same method will behave differently when it is
applied to the objects of different classes
◦ Objects can adopt more than one form, depending on their context
◦ Allows subclasses to provide their own implementations of methods
inherited from the superclass
◦ Determines the actual method to be called at runtime based on the
object's type and parameters passed.
20. Characteristics of OOS
Abstraction
◦ Hides unnecessary details and provides a simplified view of an
object
◦ Defines the public interface of an object, specifying what it can do
but hides the internal workings of an object
Reusability
◦ Encourages the reuse of existing code components, leading to
faster development and reduced errors
21. Characteristics of OOS
Maintainability
◦ Encapsulation and modularity make it easier to modify and
maintain code.
◦ The hierarchical structure of OOS simplifies the understanding and
management of large systems.
Extensibility
◦ Allows new features to be added without affecting existing code.
◦ Enables systems to adapt to changing requirements.
22. Need of Object Oriented System
• Object-Oriented (OO) systems are essential in modern software
development due to their ability to model real-world entities efficiently,
improve code reusability, maintainability, and scalability.
• Below are the key reasons why OO systems are necessary:
23. Need of Object Oriented System
• 1. Modularity & Organized Code
• Breaks complex problems into smaller, manageable objects (modules).
• Each object represents a real-world entity with attributes (data) and methods
(functions).
2. Reusability (Inheritance & Composition)
• Inheritance allows new classes to reuse properties of existing ones.
• Composition enables building complex objects by combining simpler ones.
3. Encapsulation (Data Hiding & Security)
• Restricts direct access to an object’s internal state.
• Provides controlled access via getters & setters.
24. Need of Object Oriented System
4. Polymorphism (Flexibility in Behavior)
• Allows objects of different classes to be treated as objects of a common superclass.
5. Maintainability & Scalability
• Changes in one part of the system (an object) have minimal impact on others.
• New features can be added without rewriting existing code.
6. Better Problem-Solving Approach
• Models real-world scenarios naturally (e.g., Student, Course, Teacher in a school system).
• Easier to understand and debug compared to procedural programming.
7. Supports Team Collaboration
• Different teams can work on different objects/classes simultaneously.
• Well-defined interfaces reduce conflicts.
25. Need of Object Oriented System
8. Industry Standard for Modern Development
• Used in Java, Python, C++, C#, etc.
• Essential for OOP design patterns (Singleton, Factory, Observer, etc.).
• Foundation for frameworks like Spring (Java), Django (Python), and .NET (C#).
• Object-Oriented Systems provide a structured, efficient, and scalable way to develop
software by mimicking real-world interactions.
• They enhance code reuse, security, flexibility, and teamwork, making them indispensable in
modern programming.
26. ◦ A complex system is a system composed of many interacting components
whose collective behavior is difficult to predict simply by analyzing individual
parts.
◦ Complex systems are often referred to as “wholes that are more than the sum
of their parts,”
◦ consist of a large number of elements that in themselves can be simple
◦ These systems exhibit emergent properties—behaviors or patterns that arise
from interactions but are not obvious when looking at single elements.
Complex Systems
27. Key Characteristics of Complex Systems include:
◦ Nonlinearity – Small changes can lead to disproportionately large effects
◦ Emergence – System-wide behaviors arise from interactions
◦ Adaptation – Components evolve or adjust in response to changes
◦ Feedback Loops – Positive (amplifying) or negative (stabilizing) feedback
influences system dynamics.
◦ Self-Organization – Order emerges without central control
◦ Networks & Interdependence – Components are interconnected in ways that
make isolation difficult.
Complex Systems
28. ◦ Complex systems often exhibit certain structural and dynamic
attributes that help us understand their organization, behavior, and
evolution. Below, we break down five key attributes:
◦ Hierarchical/Hierarchic Structure
◦ Components/Separation of Concerns
◦ Primitive Components/Relative Primitives
◦ Arrangement/Common Patterns
◦ Evolution/Stable Intermediate Form
Complex Systems
29. Complex Systems
1. Hierarchical/Hierarchic Structure
• Complex systems are often organized in nested layers, where higher levels emerge from interactions at
lower levels.
•Key Aspects:
• Levels of Abstraction: Each layer operates under its own rules but depends on lower layers (e.g., cells → tissues
→ organs → organisms).
• Modularity: Subsystems can function semi-independently (e.g., departments in a company).
• Control & Coordination: Higher levels impose constraints (e.g., government laws regulating individual
behavior).
• Example:
Technology Stack: Hardware → OS → Software → User Applications.
Biological Systems: Atoms → Molecules → Cells → Organs → Organisms.s
30. Complex Systems
2. Components/Separation of Concerns
• A complex system is composed of modular components, each with a specialized function.
• Key Aspects:
• Decoupling: Components interact through well-defined interfaces, reducing dependencies.
• Specialization: Each part handles a specific task (e.g., kidneys filter blood; routers direct
internet traffic).
• Robustness: Failure in one component doesn’t necessarily collapse the whole system.
• Example:
Software Engineering: Frontend (UI) vs. Backend (logic) vs. Database (storage).
Ecosystems: Producers (plants), Consumers (animals), Decomposers (fungi).
31. Complex Systems
3. Primitive Components/Relative Primitives
• Complex systems are built from fundamental building blocks that combine to create higher-
order complexity.
• Key Aspects:
• Atomicity: The simplest meaningful unit in a system (e.g., a neuron in a brain, a transaction in a
blockchain).
• Composability: Primitives can be combined in different ways (e.g., LEGO bricks, DNA base pairs).
• Relativity: What’s "primitive" depends on the level of analysis (e.g., cells are primitive to organs but
complex compared to molecules).
• Example:
Language: Letters → Words → Sentences → Paragraphs.
Economics: Individual transactions → Markets → Economies.
32. Complex Systems
4. Arrangement/Common Patterns
• Complex systems often follow recurring structural or behavioral patterns.
• Key Aspects:
• Network Structures: Scale-free, small-world, or modular networks (e.g., social networks, neural
networks).
• Feedback Loops: Reinforcing (growth) or balancing (stabilization) cycles.
• Recursive Symmetry: Self-similarity across scales (e.g., fractals, tree branches).
• Example:
Power Law Distribution: A few hubs dominate (e.g., internet traffic, wealth distribution).
Turing Patterns: Repeating structures in biology (e.g., zebra stripes, leopard spots).
33. Complex Systems
5. Evolution/Stable Intermediate Forms
• Complex systems often evolve through stages of increasing complexity, with stable intermediate
forms.
• Key Aspects:
• Gradual Adaptation: Small, incremental changes accumulate (e.g., software updates, biological evolution).
• Punctuated Equilibrium: Long periods of stability interrupted by rapid shifts (e.g., technological
revolutions, mass extinctions).
• Viability at Each Stage: Intermediate forms must be functional (e.g., proto-cells before full cells, MVP
products before scaling).
• Example:
Technology: Vacuum tubes → Transistors → Microchips → AI.
Life: Chemical soups → Self-replicating molecules → Cells → Multicellular life.
34. Complex Systems
• These five attributes help explain how complex systems:
• Organize (hierarchy, separation of concerns),
• Build complexity (primitives, patterns),
• Evolve (stable intermediate forms).
• Understanding these principles allows better design, prediction, and management of
systems ranging from software to ecosystems.
35. Rarely would a builder think about adding a new sub-basement to an
existing 100-story building
Doing that 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
Software Complexity
36. Software Complexity
“The complexity of software is an essential property, not an
accidental one.” - Frederick Brooks
Four elements:
◦the complexity of the problem domain,
◦the difficulty of managing the development process,
◦ the flexibility possible through software, and
◦ the problems of characterizing the behavior of discrete
systems
37. Software Complexity
• Software complexity refers to the difficulty of understanding,
maintaining, and modifying a software system due to its
structure, interdependencies, and behavior.
• High complexity leads to bugs, technical debt, and increased
development costs.
38. Software Complexity
Types of Software Complexity
A. Structural Complexity
◦ Cyclomatic Complexity: Measures the number of independent paths in code.
◦ Coupling: Coupling refers to how much one part of a system depends on another.
◦ Cohesion: Cohesion refers to how closely the operations in a single module or class are related to each other.
◦ Deep Nesting: Excessive if-else/for loops make logic hard to follow.
B. Behavioral Complexity
◦ Non-determinism: Race conditions, async behavior, and unpredictable states.
◦ Side Effects: Functions modifying external state unintentionally.
◦ Emergent Bugs: Issues arising from unexpected interactions between components.
C. Cognitive Complexity
◦ Readability: Poor naming, lack of documentation, and unclear abstractions.
◦ Mental Models: How much a developer must "hold in their head" to make changes.
39. Software Complexity
Measuring Software Complexity
• Quantitative Metrics
• Cyclomatic Complexity (McCabe) → Measures branching logic.
• Halstead Volume → Calculates complexity based on operators & operands.
• Lines of Code (LoC) → Not always meaningful, but extreme growth signals issues.
• Dependency Graphs → Visualizes coupling between modules.
• Qualitative Indicators
• "WTF/Minute" Rate → How often developers says “What the f*?!”** while reading or reviewing a piece of
code
• Bug Frequency → More bugs in a module often mean higher complexity.
• Onboarding Time → How long it takes new developers to understand the system.
40. Software Complexity
Managing & Reducing Complexity
A. Design Principles
• KISS (Keep It Simple, Stupid) → Avoid over-engineering.
• SOLID Principles → Especially Single Responsibility & Dependency Inversion.
• DRY (Don’t Repeat Yourself) → But avoid false abstractions.
• Law of Demeter → Reduce unnecessary dependencies ("only talk to friends").
B. Architectural Strategies
• Modularization → Break into independent, reusable components.
• Layered Architecture → Separation of concerns (UI, Business Logic, Data).
• Event-Driven Design → Decouple components using events/messages.
42. Software Complexity
Software complexity is inevitable but manageable. The key is:
• Measuring it (metrics, developer feedback).
• Containing it (modular design, clear boundaries).
• Reducing it (refactoring, deleting useless code).
44. Review
What is a complex system? Explain attributes of a complex system.
Software systems are always complex. Justify with example.
Explain the need of object oriented systems. What are the attributes of a complex system?
Compare object oriented and traditional software development life cycle.
