Procedural Versus Object-Oriented Concepts

Before exploring programming languages and the security implications of software engineering technologies, it helps to frame programming in familiar terms: how do we guide groups of people to accomplish useful work in defined, measurable, and meaningful ways?

A core part of how people think about and organize work is the idea of a process—a clear set of steps, rules, roles, success criteria, and supporting information.

Processes are created in human-readable form, by people, for people to use and follow.

In everyday terms:

• Processes are executable. People can carry out the identified tasks, step by step, using business logic, constraints, and other elements of the process to guide, control, and monitor their work.
• Processes can be nested. A single step in one process may require launching and completing a different process, sometimes carried out by an entirely different group of people.
• Processes can running independently of each other.
• Processes encapsulate the data, knowledge, logic, and step-by-step procedures necessary for people to perform that process.
• Processes can operate under a variety of input conditions and perform different business functions (such as verifying user credentials, encrypting sensitive data, or generating an access audit log).

Network engineers, security analysts, identity provisioning administrators, and many other people write, read, follow, critique, and learn with many such processes every day. Processes might also be called jobs, tasks, assignments, duties, or activities.

This quick example illustrates two different ways people think and act:

• Procedural thinking. We think in stepby-step sequences of tasks. These sequences can contain conditional branches, loops or other sequence control patterns as needed.
• Object-oriented (OO) thinking. We think in packages or bundles of ideas, steps, data, logic, and so on, bundled together as a logical whole. We give it a name and we invoke that bundle by means of that name. Each package we create does not have to know | anything about what is inside other named packages that we (or someone else) created.

Software engineering uses much of these

Both procedural and OOP approaches same concepts of procedural and O0 provide ways to deal with the management thinking in defining, building, and using of complex sets of software: software tools to build other software:

• Code reuse. Strategies encourage programmers to reuse, rather
• Procedural programming emphasizes the logical sequence or flow of steps

than reinvent, units of software to be performed. A procedure is a set (procedures or objects) that have of software that performs a particular already been demonstrated to be function, requires specific input data correct, complete, safe, and secure. (and possibly other resources), and

• Adding or changing functionality.

produces a specific set of outputs.

The most common form of supporting

Outputs may include error signals deployed, in-use software.

when appropriate. Procedures can invoke ("call") other procedures.

• Refactoring. A partial or complete rewrite of a set of software to perform
• 00 programming (OOP) defines

the same functions, but in a more an object to be a set of software straightforward, more efficient, or that offers one or more methods, more maintainable form.

internal to the object, that software external to that object can request be

• Data modeling. A design process

performed. Each method may require that identifies all data elements that specific inputs and resources and may the system will need to input, create, produce a specified set of outputs.

store, modify, output, and destroy during its operational use. Arguably, data modeling should be one of the first steps in systems analysis and design, regardless of whether procedural or OOP approaches will be used to implement it.

and design, regardless of whether procedural or OOP approaches will be used to implement it.

• Data quality standards and practices. These constrain the use of data to meet organizationally approved rules and methods and can reduce, if not eliminate, many datadependent exploitable vulnerabilities by imposing standardized data declarations, including data validation criteria and associated business logic.
• Security practices. Such a practice can dictate the use of preapproved software libraries for sensitive or mission-critical functions.