Software Engineering Principles: Modularity, Testing, Security & More

Posted on Aug 26, 2024 in Design and Engineering

Software Engineering Principles

Modularity

What is a Module?

A program unit that is discrete and identifiable with respect to compiling, combining with other units, and loading.

What is Modularity?

The degree to which a system or computer program is composed of discrete components such that a change to one component has minimal impact on other components.

Modular Programming

A software development technique in which software is developed as a collection of modules.

Benefits of Modular Programming
  • Managerial
  • Product Flexibility
  • Comprehensibility

Module Complexity

The degree to which a system’s design or code is difficult to understand because of numerous components or relationships among components.

Simplicity (Opposite of Complexity)

The degree to which a system or component has a design and implementation that is straightforward and easy to understand.

Module Cohesion

The manner and degree to which the tasks performed by a single software module are related to one another.

Types of Cohesion
  • Communicational Cohesion: Tasks use the same input data or contribute to producing the same output data.
  • Logical Cohesion: Tasks perform logically similar functions.
  • Functional Cohesion: Tasks all contribute to the performance of a single function.
  • Procedural Cohesion: Tasks all contribute to a given program procedure (e.g., iteration or decision process).
  • Temporal Cohesion: Tasks are all required at a particular phase of program execution.

Module Coupling

The manner and degree of interdependence between software modules. The strength of the relationships between modules.

Decoupling

The process of making software modules more independent of one another to decrease the impact of changes to, and errors in, the individual modules.

Types of Coupling
  • Common-environment / Common Coupling: Two modules access a common data area.
  • Content Coupling: Contents of one module are included in another module.
  • Control Coupling: One module influences another module’s execution.
  • Data / Input-output Coupling: Output from one module serves as input to another.

Test-Driven Development (TDD)

Test-driven development is a discipline that helps professional software developers ship clean, flexible code that works, on time.

Steps in TDD

  1. Identify requirements
  2. Write tests (Objective: to fail the modules/codes)
  3. Write codes (Objective: to pass the tests)
  4. Repeat (Objective: 2 minutes per cycle)

The Three Laws of TDD

  1. You may not write production code unless you’ve first written a failing unit test.
  2. You may not write more of a unit test than is sufficient to fail.
  3. You may not write more production code than is sufficient to make the failing unit test pass.

Benefits of TDD

  • Flexibility
  • Documentation
  • Minimal debugging
  • Better design

Types of Testing

  • Interface
    • Input/Output
  • Exercising Data Structures
    • Type mismatch?
  • Boundary Conditions
    • Array out-of-bound?
  • Execution Paths
    • Infinite loop? Conditions not reached?
  • Error Handling
    • Try…catch

Assertions

An assertion is a Boolean expression placed at a specific point in a program which will always be evaluated “TRUE” unless there is a bug in the program.

Types of Assertions

  • Run-time Assertions: Ensure programming running correctly
  • Unit Tests: Ensure functionalities
  • Compile-time Assertions: Ensure codes written correctly

Handling Failed Assertions

  • Terminate the program: Not good. Prevents issues from occurring again, but other parts couldn’t carry on.
  • Allow execution to continue unhindered: Not good.
  • Print an error message: Not good. Printing the error has little context knowledge on the error. Automatic system might not have an output interface.
  • Throw an exception to back out of the erroneous code path: Good. Find ways to deal with the error. Does not stop the program.

Benefits of Assertions

  • Detect subtle errors that might otherwise go undetected.
  • Detect errors sooner after they occur than they might otherwise be detected.
  • Make a statement about the effects of the code that is guaranteed to be true.

Software Security

Software Security Goals

  • Confidentiality
  • Integrity
  • Availability

Secure Programming Techniques

Validate All Input

Check all input as it is passed into a function to check it’s the correct format. Examples: Keyboard presses, files read from disk, data passed to a function, data received over a network.

Restrict Operations to Buffer Bounds

Prevents functions from writing and reading data where they shouldn’t. Avoid buffer overflow errors (e.g., Heartbleed).

Design Your Program for Security

Follow good security design principles. Examples: Least privilege, economy of mechanism / simplicity, open design.

Security Standards and Models

  • Security Development Lifecycle (SDL): A set of practices that support security assurance and compliance requirements.
  • Software Assurance Maturity Model (SAMM): Open framework to help organizations formulate and implement a strategy for software security.
  • Building Security In Maturity Model (BSIMM): Study of existing software security initiatives.
  • CLASP / OWASP: Designed to help software development teams build security into the early stages of existing and new-start SDLC in a structured, repeatable, and measurable way.

Types of Errors

  • Syntax Errors: Error in the syntax of a sequence of characters. “Grammatical” error. Program will not compile.
  • Compile/Interpret Errors: Computer fails to compile the program source code. Program will not compile.
  • Link / Build Errors: Libraries or object files not found. Program will not compile.
  • Non-Errors: Not exactly an error. Non-sensical calculation (logic errors). E.g., Negative area calculation. Program will run incorrectly.
  • Runtime Errors: Errors that happen when the program is running. E.g., division by zero (logic errors). Program will crash.

Exceptional Events and Handling

An exception is an event that occurs during the execution of a program that disrupts the normal flow of instructions. Exception handling is a technique used to deal with unexpected circumstances that occur while a program is running. It normally allows the program to continue running.

Assertions vs. Exceptions vs. Control Flow

  • Assertion: Method ensuring the program is in an appropriate state. Execution is typically halted if the state is deemed to not be appropriate.
  • Exception Handling: Technique used to deal with unexpected circumstances that occur while a program is running. It normally allows the program to continue running.
  • Control Flow: Method dictating which parts of the program should run under normal circumstances.

Debugging with GDB

Preparing and Launching

  • Prepare: g++ -g mycode.cpp -o debugme
  • Launch: gdb debugme then run

Setting Breakpoints and Inspecting

  • List code: list
  • Set breakpoint: break # (replace # with line number)
  • Inspect variables: print var, info locals

Conditional Breakpoints and Watchpoints

  • Conditional breakpoint: break # if "condition is true"
  • Watchpoint: watch var (triggers when ‘var’ changes value)

Easy Approach to Requirements Syntax (EARS)

EARS is a constrained natural language for writing requirements.

Different EARS Syntaxes

  • Generic: <optional pre-conditions> <optional trigger> the <system name> shall <system response>
  • Ubiquitous: The <system name> shall <system response>
  • Event-driven: WHEN <optional pre-conditions> <trigger> the <system name> shall <system response>
  • Unwanted Behaviors: IF <optional pre-conditions> <trigger>, THEN the <system name> shall <system response>
  • State-driven: WHILE <in a specific state> the <system name> shall <system response>

Black Box and White Box Testing

  • Black Box Testing: Testing without knowledge of the internal workings.
  • White Box Testing: Testing with knowledge of the internal workings.

Usability and Accessibility

  • Usability: The extent to which a system can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use.
  • Accessibility: The extent to which products, systems, services, environments, and facilities can be used by people from a population with the widest range of characteristics and capabilities to achieve a specified goal in a specified context of use.
  • Accessibility Requirement: The requirement to make a website or mobile application accessible by making it perceivable, operable, understandable, and robust.

Setting up Git

Credentials

  • Check version: git --version
  • Set username: git config --global user.name "Your Name"
  • Set email: git config --global user.email "your.email@example.com"

Repository

  • Navigate to directory: cd ~/your/directory
  • Initialize repository: git init

Basic Git Commands

  • git status: Check repository status.
  • git add example.py: Stage a file.
  • git rm --cached : Unstage a file.
  • git commit -m "Your message": Commit changes.
  • git commit --amend: Amend the previous commit.
  • git log: Show commit history.
  • git branch: List branches.
  • git branch new-branch: Create a new branch.
  • git checkout new-branch: Switch to a branch.
  • git merge new-branch: Merge a branch into the current branch.
  • git reset: Reset the repository.

Effectiveness, Efficiency, and Satisfaction

  • Effectiveness: The degree to which something is successful in producing a desired result.
  • Efficiency: The state or quality of the useful work performed.
  • Satisfaction: The fulfillment of one’s wishes, expectations, or needs, or the pleasure derived from this.