UNIT-2 :NOTES

Object-Oriented Concepts:
INTRODUCTION:

UML can be described as the successor of object-oriented (OO) analysis and design.

An object contains both data and methods that control the data. The data represents

the state of the object. A class describes an object and they also form a hierarchy to

model the real-world system. The hierarchy is represented as inheritance and the

classes can also be associated in different ways as per the requirement.

Objects are the real-world entities that exist around us and the basic concepts such as

abstraction, encapsulation, inheritance, and polymorphism all can be represented using

UML.

UML is powerful enough to represent all the concepts that exist in object-oriented

analysis and design. UML diagrams are representation of object-oriented concepts

only. Thus, before learning UML, it becomes important to understand OO concept in

detail.

Following are some fundamental concepts of the object-oriented world −

● Objects − Objects represent an entity and the basic building block.

● Class − Class is the blue print of an object.

● Abstraction − Abstraction represents the behavior of an real world entity.

● Encapsulation − Encapsulation is the mechanism of binding the data

together and hiding them from the outside world.

● Inheritance − Inheritance is the mechanism of making new classes from

existing ones.
 ● Polymorphism − It defines the mechanism to exists in different forms

A Conceptual Model of UML

To understand the conceptual model of UML, first we need to clarify what is a

conceptual model? and why a conceptual model is required?

● A conceptual model can be defined as a model which is made of concepts

and their relationships.

● A conceptual model is the first step before drawing a UML diagram. It

helps to understand the entities in the real world and how they interact

with each other.

As UML describes the real-time systems, it is very important to make a conceptual

model and then proceed gradually. The conceptual model of UML can be mastered by

learning the following three major elements −

● UML building blocks

● Rules to connect the building blocks

● Common mechanisms of UML

The purpose of OO analysis and design can described as −

● Identifying the objects of a system.

● Identifying their relationships.

 ● Making a design, which can be converted to executables using OO

languages.

There are three basic steps where the OO concepts are applied and implemented. The

steps can be defined as

OO Analysis → OO Design → OO implementation using OO languages

The building blocks of UML can be defined as −

● Things

● Relationships

● Diagrams

Things
Things are the most important building blocks of UML. Things can be −

● Structural

● Behavioral

● Grouping

● Annotational

Structural Things
Structural things define the static part of the model. They represent the physical and

conceptual elements. Following are the brief descriptions of the structural things.

Class − Class represents a set of objects having similar responsibilities.

Interface − Interface defines a set of operations, which specify the responsibility of a

class.

Collaboration −Collaboration defines an interaction between elements.

Dashed ellipse

Use case −Use case represents a set of actions performed by a system for a specific

goal.

Component −Component describes the physical part of a system.

Node − A node can be defined as a physical element that exists at run time.
Behavioral Things
A behavioral thing consists of the dynamic parts of UML models. Following are the

behavioral things −

Interaction − Interaction is defined as a behavior that consists of a group of messages

exchanged among elements to accomplish a specific task.

State machine − State machine is useful when the state of an object in its life cycle is

important. It defines the sequence of states an object goes through in response to

events. Events are external factors responsible for state change

Grouping Things
Grouping things can be defined as a mechanism to group elements of a UML model

together. There is only one grouping thing available −

Package − Package is the only one grouping thing available for gathering structural

and behavioral things.

Annotational Things
Annotational things can be defined as a mechanism to capture remarks, descriptions,

and comments of UML model elements. Note - It is the only one Annotational thing

available. A note is used to render comments, constraints, etc. of an UML element.

Relationship
Relationship is another most important building block of UML. It shows how the

elements are associated with each other and this association describes the

functionality of an application.

There are four kinds of relationships available.

Dependency
Dependency is a relationship between two things in which change in one element also

affects the other.

Association
Association is basically a set of links that connects the elements of a UML model. It

also describes how many objects are taking part in that relationship.

Generalization
Generalization can be defined as a relationship which connects a specialized element

with a generalized element. It basically describes the inheritance relationship in the

world of objects.

Realization
Realization can be defined as a relationship in which two elements are connected. One

element describes some responsibility, which is not implemented and the other one

implements them. This relationship exists in case of interfaces.

UML Diagrams
UML diagrams are the ultimate output of the entire discussion. All the elements,

relationships are used to make a complete UML diagram and the diagram represents a

system.
The visual effect of the UML diagram is the most important part of the entire process.

All the other elements are used to make it complete.

UML includes the following nine diagrams, the details of which are described in the

subsequent chapters.

● Class diagram

● Object diagram

● Use case diagram

● Sequence diagram

● Collaboration diagram

● Activity diagram

● Statechart diagram

● Deployment diagram

● Component diagram

Usecase diagram:

A use-case model is a model of how different types of users interact with the system to solve a problem.
As such, it describes the goals of the users, the interactions between the users and the system, and the
required behavior of the system in satisfying these goals.

A use-case model consists of a number of model elements. The most important model elements are: use
cases, actors and the relationships between them.

A use-case diagram is used to graphically depict a subset of the model to simplify communications.
There will typically be several use-case diagrams associated with a given model, each showing a subset
of the model elements relevant for a particular purpose. The same model element may be shown on
several use-case diagrams, but each instance must be consistent. If tools are used to maintain the
use-case model, this consistency constraint is automated so that any changes to the model element
(changing the name for example) will be automatically reflected on every use-case diagram that shows
that element.
The use-case model may contain packages that are used to structure the model to simplify analysis,
communications, navigation, development, maintenance and planning.

Much of the use-case model is in fact textual, with the text captured in the Use-Case Specifications that
are associated with each use-case model element. These specifications describe the flow of events of the
use case.

The use-case model serves as a unifying thread throughout system development. It is used as the
primary specification of the functional requirements for the system, as the basis for analysis and design,
as an input to iteration planning, as the basis of defining test cases and as the basis for user
documentation

Basic model elements

The use-case model contains, as a minimum, the following basic model elements.

Actor

A model element representing each actor. Properties include the actors name and brief description. See
Concept: Actor for more information.

Use Case

A model element representing each use case. Properties include the use case name and use case
specification. See Artifact: Use Case and Concept: Use Case for more information.

Associations

Associations are used to describe the relationships between actors and the use cases they participate in.
This relationship is commonly known as a “communicates-association”.

Example Use-Case Diagram

Figure 1 shows a use-case diagram from an Automated Teller Machine (ATM) use-case model.
Use Case Diagrams
Use case diagrams are one of the five behavioral diagrams for modeling the dynamic
aspects of the system. A use case diagram specifies what the system does (behavior)
for the actors.

Use case diagram plays a key role in modeling the behavior of a system or subsystem
or a class. Each use case diagram consists of a set of use cases, actors and their
relationships.
Common Properties

Use case diagrams shares some common properties with the rest of the UML diagrams
like a name which identifies a use case diagram and the graphical content which is a
projection into a model.

Content

Use case diagrams commonly contain:

● Use cases
● Actors
● Dependency, generalization and association relationships

Like all other diagrams, use case diagrams may contain notes and constraints. They
may also contain packages or subsystems, which are used to group elements of your
model into larger chunks.

Common Uses

When we model the static use case view of a system, we apply use case diagrams in
one of the two ways:
 ● To model the context of a system
● To model the requirements of a system

Example:

Common Modeling Techniques

Modeling the context of a system

All the things (actors) that live outside the system and interact with the system constitute
the system’s context. This context defines the environment in which the system lives.

To model the context of a system:

1. Identify the actors that surround the system.

2. Organize actors that are similar to one another in a generalization-specialization
hierarchy.
3. For better semantics, provide a stereotype for each actor.
4. Create a use case diagram with these actors and specify the paths of
communication for each actor to the system’s uses cases using association
relationships.

Modeling the requirements of a system

A system’s functional requirements can be expressed as use cases, and the UML’s use
case diagrams are essential for managing these requirements.

To model the requirements of a system:

1. Establish the context of the system by identifying the actors that surround (use)
the system.
2. For each actor, identify the behavior that the actor expects from the system or
requires the system to provide.
3. Name these common behaviors as use cases.
4. Use include and extend relationships to factor common behavior and optional
behavior.
5. Model these use cases, actors and their relationships in a use case diagram.
6. Use notes to provide details about the use cases and other non-functional
requirements.
Forward and reverse engineering

To forward engineer a use case diagram:

1. For each use case, identify the flow of events and its exceptional flow of events.
2. Generate a test script for each flow, using the flow’s preconditions as the test’s
initial state and its post conditions as its success criteria.
3. As necessary, simulate test runs to represent each actor that interacts with the
use case.
4. Use tools to run these tests each time you release the element to which the use
case diagram applies.

To reverse engineer a use case diagram:

1. Identify each actor that interacts with the system.

2. For each actor, consider how the actor interacts with the system.
3. Trace the flow of events in the executable system relative to each actor.
4. Cluster (group) related flows by declaring a corresponding use case. Use include
and extend relationships as necessary.
5. Model these actors and use cases in a use case diagram, and establish their
relationships.

Class Diagrams
Class diagrams are most commonly found diagrams while modeling software systems.
A class diagram consists of classes, collaborations and interfaces. A class diagram is
used to model the static design view of the system.
Common Properties

The class diagram shares the common properties with the rest of the diagrams, a name
and graphical elements that are a projection into the model. What distinguish the class
diagram from the others are the contents of the diagram.

Contents

Class diagram contains the following:

● Classes
● Interfaces
● Collaborations
● Generalization, dependencies and associations

Like other diagrams, class diagrams may also contain notes and constraints. Class
diagrams may also contain packages or subsystems which are used to organize the
elements into groups. Generally, the class diagrams are used for:

● Modeling the vocabulary of the system

● Modeling the collaborations
● Modeling the logical database schema
Common Modeling Techniques

Modeling Simple Collaborations

To model simple collaborations,

1. Identify the function or behavior of the part of a system you would like to model.
2. For each function or mechanism identify the classes, interfaces, collaborations
and relationships between them.
3. Use scenarios (sequence of activities) to walk through these things. You may find
new things or find that existing things are semantically wrong.
4. Populate the things found in the above steps. For example, take a class and fill
its responsibilities. Now, convert these responsibilities into attributes and
operations.

Modeling a Logical Database Schema

To model a schema,

1. Identify the classes whose state must be saved over the lifetime of the
application.
2. Create a class diagram and mark these classes as persistent by using tagged
values.
 3. Provide the structural details for these classes like the attributes, associations
with other classes and the multiplicity.
4. Minimize the common patterns which complicate the physical database design
like cyclic associations, one-to-one associations and n-ary associations.
5. Provide the behavior for these classes by listing out the operations that are
important for data access and integrity.
6. Wherever possible, use tools to convert the logical design to physical design.

Forward and Reverse Engineering

To forward engineer a class diagram,

1. Identify the rules for mapping the models to the implementation language of your
choice.
 2. Depending on the semantics of the language, you may want to restrict the
information in your UML models. For example, UML supports multiple
inheritance. But some programming languages might not allow this.
3. Use tagged values to specify the target language.
4. Use tools to convert your models to code.

To reverse engineer the code,

1. Identify the rules for mapping the implementation language to a model.

2. Using a tool, navigate to the code that you want to reverse engineer. Use the tool
to generate a new model.

Component Diagrams
A component is just a special kind of a diagram and shares the same common
properties as the other diagrams like: a name and graphical contents. What
distinguishes a component diagram from the rest of the diagrams is its content.

Content

Component diagram commonly contain:

● Components
● Interfaces
● Dependency, generalization, association and realization relationships.
Like all other diagrams, component diagrams may contain notes and constraints.
Component diagrams may also contain packages.

Common Uses

When modeling the static implementation view of a system, we will typically use
component diagrams in one of four ways:

1. To model source code.

2. To model executable releases.
3. To model physical databases.
4. To model adaptable systems.

Common Modeling Techniques

Modeling source code

To model a system’s source code:

● Either by forward or reverse engineering, identify the set of source code files of
interest and model them as components stereotypes as files.
● For larger systems, use packages to show groups of source code files.
● Consider using tagged values indicating such information as the version number
of the source code file, its author, and the date it was last changed.
 ● Model the compilation dependencies among these files using dependencies.

Modeling an executable release

● dentify the set of components you’d like to model.
● Consider the stereotype of each component in this set.
● For each component in this set, consider its relationship to its neighbors. Most,
often this will involve interfaces that are realized by certain components and then
imported by others.
Modeling a physical database

To model a physical database:

● Identify the classes in your model that represent your logical database schema.
● Select a strategy for mapping these classes to tables. You have to also consider
the physical distribution of your databases.
● To visualize, specify, construct and document your mapping, create a component
diagram that contains components stereotyped as tables.
● Where possible, use tools to help you transform your logical design into a
physical design.
Modeling adaptable systems

To model an adaptable system:

● Consider the physical distribution of the components that may migrate from node
to node. We can specify the location of a component instance by marking it with
a location tagged value.
● If you want to model the actions that cause a component to migrate, create a
corresponding interaction diagram that contains component instances. We can
illustrate a change of location by drawing the same instance more than once, but
with different values for its location tagged value.
Interaction Diagrams
Introduction

An interaction diagram represents an interaction, which contains a set of objects and

the relationships between them including the messages exchanged between the
objects.

A sequence diagram is an interaction diagram in which the focus is on time ordering of

messages. Collaboration diagram is another interaction diagram in which the focus is on
the structural organization of the objects. Both sequence diagrams and collaboration
diagrams are isomorphic diagrams.
Common Properties

Interaction diagrams share the properties which are common to all the diagrams in
UML. They are: a name which identifies the diagram and the graphical contents which
are a projection into the model.

Contents

Interaction diagrams commonly contain:

1. Objects
2. Links
3. Messages

Sequence Diagrams

A sequence diagram is one of the two interaction diagrams. The sequence diagram
emphasizes on the time ordering of messages. In a sequence diagram, the objects that
participate in the interaction are arranged at the top along the x-axis.

Generally, the object which initiates the interaction is placed on the left and the next
important object to its right and so on. The messages dispatched by the objects are
arranged from top to bottom along the y-axis. This gives the user the detail about the
flow of control over time.

Sequence diagram has two features that distinguish them from collaboration diagrams.
First, there is the object lifeline, which is a vertical dashed line that represents the
existence of an object over a period of time. Most of the objects are alive throughout the
interaction.

Objects may also be created during the interaction with the receipt of the message
stereotyped with create. Objects may also be destroyed during the interaction with the
receipt of the message stereotyped with destroy.

Second, there is focus of control which is represented as a thin rectangle over the life
line of the object. The focus of control represents the points in time at which the object
is performing an action. We can also represent recursion by using a self message.

Collaboration Diagrams

A collaboration diagram is one of the two interaction diagrams. The collaboration

diagram emphasizes on the structural organization of the objects in the interaction.

A collaboration diagram is made up of objects which are the vertices and these are
connected by links. Finally, the messages are represented over the links between the
objects. This gives the user the detail about the flow of control in the context of
structural organization of objects that collaborate.

Collaboration diagram has two features that distinguish them from the sequence
diagrams. First, there is a path which indicates one object is linked to another. Second,
there is a sequence number to indicate the time ordering of a message by prefixing the
message with a number.

Common Uses

We use interaction diagrams to model the dynamic aspects (interactions) of the system.
When we use an interaction diagram to model some dynamic aspect of a system, we do
so in the context of the system as a whole, a subsystem, an operation or a class. We
typically use the interaction diagrams in two ways:

1. To model flows of control by time ordering

2. To model flows of control by organization

Common Modeling Techniques

Modeling flow of control by time ordering

To model a flow of control by time ordering,

1. Set the context for the interaction, whether it is a system, subsystem, operation
or class or one scenario of a use case or collaboration.
2. Identify the objects that take part in the interaction and lay them out at the top
along the x-axis in a sequence diagram.
3. Set the life line for each object.
4. Layout the messages between objects from the top along the y-axis.
5. To visualize the points at which the object is performing an action, use the focus
of control.
6. To specify time constraints, adorn each message with the time and space
constraints.
7. To specify the flow of control in a more formal manner, attach pre and post
conditions to each message.

Modeling flow of control by organization

To model a flow of control by organization,

1. Set the context for the interaction, whether it is a system, subsystem, operation
or class or one scenario of a use case or collaboration.
2. Identify the objects that take part in the interaction and lay them out in a
collaboration diagram as the vertices in a graph.
3. Set the initial properties of each of these objects.
4. Specify the links among these objects.
5. Starting with the messages that initiate the interaction, attach each subsequent
message to the appropriate link, setting its sequence number, as appropriate.
Use Dewey numbering system to specify nested flow of control.
 6. To specify time constraints, adorn each message with the time and space
constraints.
7. To specify the flow of control in a more formal manner, attach pre and post
conditions to each message.

Object diagrams
Before learning about object diagrams in UML, have a look at class diagrams in UML.

An object diagram models the instances of classes in a class diagram. An object

diagram contains objects and links connecting the related objects.

Object diagrams allow us to model the static design view or static process view. It
involves modeling a snapshot of the system which contains objects (instances), their
state and links between objects.

An object diagram represents the static part of an interaction containing the objects that
communicate and the links between them without any messages.

Common Properties
An object diagram shares the same common properties like the rest of the diagrams, a
name which identifies the diagram and graphical contents which are a projection into
the model. What distinguish an object diagram from the rest of the diagrams are its
contents.
Contents

Object diagrams contain:

● Objects
● Links

Like all other diagrams, object diagrams may contain notes and constraints.

Object diagrams may also contain packages and subsystems which are used to group
the related elements in the model together. Sometimes we can also include classes in
the object diagrams. Generally, object diagrams are used to model the object structures.

Common Modeling Techniques

Modeling Object Structures

To model an object structure,

● First, identify the function or behavior or part of a system you want to model as
collection of classes, interfaces and other things.
● For each function or mechanism identify the classes and interfaces that
collaborate and also identify the relationships between them.
● Consider a scenario (context) that walks through this mechanism and freeze at a
moment in time and identify the participating objects.
● Represent the state of objects by listing out the attributes and their values.
● Represent the links between objects which are instances of associations.
Forward and Reverse Engineering

Forward engineering a object diagram is theoretically possible but practically of limited

value as the objects are created and destroyed dynamically at runtime, we cannot
represent them statically.

To reverse engineer a object diagram,

1. Choose the target (context) you want to reverse engineer.

2. Use a tool to stop execution at a certain moment in time.
3. Identify the objects that collaborate with each other and represent them in an
object diagram.
4. To understand their semantics, expose these object’s states.
5. Also identify the links between the objects to understand their semantics.

Difference between Procedural and Functional Programming Languages

Functional programming orients the programmer in the world of pure functions,

procedural programming organizes code into chunks of procedures, object-oriented
programming restricts the programmer to objects that represent concepts or real-world
components, and procedural programming organizes code into chunks of procedures.

Table Of Contents

​ Functional Programming
​ Procedural Programming
​ Object oriented Programming
 ​ Functional vs Procedural vs OOPs

Functional Programming
In recent years, JavaScript, a functional programming language that has accumulated
more popularity recently, has brought attention to the functional programming paradigm.

Language independence is one of the benefits of functional programming, which has its
roots in mathematics. Executing a series of mathematical functions is the key principle
of this paradigm.

Functional Programming

This type of programming style is declarative. In contrast to an imperative style, which

emphasizes "how to solve", this style focuses on "what to solve".

Rather than using statements, it uses expressions. Expressions are evaluated to

produce values, while statements are executed to assign variables.
Aspects of Functional Programming

1. Pure Functions

There are two main characteristics of these functions. Their output is the same for the
same arguments regardless of any other factor.

The second advantage is that they do not have any side-effects, that is, they do not
modify any arguments or local/global variables or input/output streams.

Immutability is one of the more recent properties. The value returned by a pure function
is its only result. The results are deterministic.

The function-based programming approach makes debugging programs easy due to the
lack of side effects and hidden input/output. Using pure functions also simplifies the
process of writing parallel/concurrent applications.

As long as the input does not change, a smart compiler can parallelize the instructions,
evaluate results when needed, and memorize the results since the results never change
as long as the input does not.

The following is an example of a pure function:

// sum is function taking x and y as arguments

const sum = (x, y) => {

// sum is returning sum of x and y without changing them

return x + y;

};

//always returns same result given same inputs

sum(5, 5);

2. Recursion

Unlike the other programming paradigm, functional programming does not employ for
and while loops. Recursion is used instead for iteration in these languages. Recursive
functions are used to execute recursion, which calls themselves continually until the
base case is obtained.
public class Recursion {

static int factorial(int n) {

if (n == 1)

return 1;

else

return (n * factorial(n - 1));

public static void main(String[] args) {

System.out.println("Factorial of 5 is: " +

factorial(5));

3. Referential Transparency
In functional programming, variables cannot change their values once they have been
defined. As a result, there is referential transparency. By using this method, the same
language expression will produce the same result.

Functional programming does not use assignment statements. It is necessary to define

new variables in a functional paradigm program in order to store additional values. At
any given moment, a variable's state will never change in such a program.

Since variables may be replaced with their actual values at any time during the
execution of the program, Referential transparency eliminates the slightest possibility of
undesirable effects.

Example: The string.replace() method is referentially transparent, since using

jane.replace(‘j’, ‘J’) will always result in the same result because replacing returns the
new object rather than updating the original.

4. Functions are First-Class and Can be Higher-Order

The functional programming style treats functions as variables. Thus, they qualify as
first-class functions. A data structure is a collection of characteristics that can be passed
around as parameters or returned from functions or stored in data structures.

Functions that take other functions as arguments or return functions are higher-order
functions. Functions that are first-class in functional programming languages can be
higher-order functions.

5. Immutability

In the case of variables, they are immutable, meaning they cannot be modified once
they've been initialized. A new variable, however, can be created. Varables are
immutable, so they maintain state throughout the program.
// class is declared final
final class Immutable {

// private class members

private String name;

private int date;

Immutable(String name, int date) {

// class members are initialized using constructor

this.name = name;

this.date = date;

// getter method returns the copy of class members

public String getName() {

return name;

public int getDate() {

return date;

}
}

class Main {

public static void main(String[] args) {

// create object of Immutable

Immutable obj = new Immutable("Programiz", 2011);

System.out.println("Name: " + obj.getName());

System.out.println("Date: " + obj.getDate());

Pros of Functional Programming

​ The reason why functional programs are easier to verify is because their states
do not change during their execution. Functional programs can thus be modeled
and reasoned more easily this way.
​ In Concurrent programming, multiple tasks are executed concurrently (not
neccessarily simultaneously) while in parallel programming, mulitple tasks are
executed parallely (simultaneously).
 ​ Compilers can optimize and substituting complex expressions into simpler ones
easily. Compilers are given more flexibility in rearranging expressions because of
referential integrity.
​ Because functions are independent of one another, programs are guaranteed to
be secure and safe. The problem of leaks of critical information and accidental
modifications of data is now over.
​ Programs can be expressed elegantly.

Drawbacks of Functional Programming

​ There will be significant performance degradation for compilers that do not

optimize for recursion.
​ You need to think mathematically when you write functional programs. It imposes
a mathematical model for programs that isn't always convenient to organize
ideas. Putting it another way, writing functional programs isn't easy.
​ A significant amount of memory may be consumed by immutability since every
value occupies an extra space.

Function-oriented programming languages

​ C++
​ Python
​ Java
​ Lisp
​ Haskell
​ Julia
Examples of Applications

​ A mathematical computation relies on it.

​ Parallelism or concurrency are required wherever these are needed.

Procedural Programming
In programming, it is defined as a language derived from structure programming and
based on the use of call procedures. Essentially, procedures are the functions, routines,
or subroutines that specify the computational steps that need to be performed.

The process involves breaking a task down into variables and routines by following a
series of instructions. Programs can call procedures at any point during execution,
either by other procedures or by themselves.

Procedural Programming
Procedural programming can be done in ALGOL, COBOL, BASIC, PASCAL,
FORTRAN, and C.As Procedural programming is considered to be less secure than
object-oriented programming.

A program is designed using a top-down approach in procedural programming. As a

result, it emphasizes the concept of functions and divides large programs into smaller
parts.

In terms of procedural programming, there is no complexity. Procedural programming

does not introduce access modifiers like object-oriented programming. The subsequent
is an instance;
public class Example {

public static void main(String[] commandLine) {

display( "Hello world" );

private static void display(String text) {

System.out.println(text);

Aspects of procedural programming

1. Scoping
The scoping concept is concerned with setting the locality of entities (objects) within a
procedural program. Without explicit permission, scoping prevents non-local variables
from being accessed from other procedures.

2. Modularity

Using this method, components are broken down into interchangeable chunks of
functionality that can be reused and shared.

3. Parameter Passing

A Parameters can be passed into a procedure call via this mechanism. It is possible to
pass parameters as references or as values.

Pros of Procedural Programming

​ Parsing through a Procedural program can be implemented with relatively simple

compilers and interpreters. It is also easy to learn and practice this approach.
​ By modularizing procedural programs, less redundant and productivity is
increased.
​ Building new modules is easier if concepts are contained and organized in
modules that can be combined.
​ It is well suited to general-purpose programming.

Drawbacks of Procedural Programming

​ The data is publicly accessible. Data can be accessed and modified without
restriction. As a result, unintended alterations occur and serious mistakes are
more likely to be committed.
 ​ Rather than focusing on data organization, this approach emphasizes
procedures. Concepts can be obscured by this, making it difficult to map them
into code.

Programs that follow Procedural approach

​ Python
​ Dart
​ Swift
​ Rust
​ Bash
​ PowerShell

PRINCIPLES OF PROGRAMMING LANGUAGES:

A programming language's features include orthogonality or simplicity, available control

structures, data types and data structures, syntax design, support for abstraction,
expressiveness, type equivalence, and strong versus weak type checking, exception
handling, and restricted aliasing