Software Engineering Concepts

Posted on Aug 26, 2024 in Design and Engineering

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

The benefits expected of modular programming are:

  • Managerial
  • Product flexibility
  • Comprehensibility

What is module complexity?

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

Opposite: Simplicity

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

What is module cohesion?

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

Communicational Cohesion

  • A type of cohesion in which the tasks performed by a software module use the same input data or contribute to producing the same output data

Logical Cohesion

  • A type of cohesion in which the tasks performed by a software module perform logically similar functions

Functional Cohesion

  • A type of cohesion in which the tasks performed by a software module all contribute to the performance of a single function

Procedural Cohesion

  • A type of cohesion in which the tasks performed by a software module all contribute to a given program procedure, such as an iteration or decision process

Temporal Cohesion

  • A type of cohesion in which the tasks performed by a software module are all required at a particular phase of program execution

What is 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

Common-environment / Common Coupling

  • A type of coupling in which two software modules access a common data area

Content Coupling

  • A type of coupling in which some or all of the contents of one software module are included in the contents of another module

Control Coupling

  • A type of coupling in which one software module communicates information to another module for the explicit purpose of influencing the latter module’s execution

Data / Input-output Coupling

  • A type of coupling in which output from one software module serves as input to another module

What is test-driven development?

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

Steps in Test-Driven Development

  1. Identify requirements
  2. Tests are written
  • Objective: to fail the modules/codes
Codes are written
  • Objective: to pass the tests
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 Test-Driven Development

  • 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

Assertion

  • 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 Assertion

  • 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 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 Development Lifecycle**
– A set of practices that support security assurance and compliance requirements
**Software Assurance Maturity Model**
– Open framework to help organizations formulate and implement a strategy for software security
**Building Security In Maturity Model**
– 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 way of:
  – Structured
  – Repeatable
  – Measurable
**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 Event**
– An exception is an event that occurs during the execution of a program that disrupts the normal flow of instructions
**Exception Handling**
– Technique used to deal with unexpected circumstances that occur while a program is running.
– It normally allows the program to continue running.
**Assertion**
– Method ensuring the program is in an appropriate state.
– Execution is typically halted if the state is deemed to not be appropriate.
**Control Flow**
– Method dictating which parts of the program should run under normal circumstances.
**(GDB) Tool**
– Prepare a program for debugging
  – g++ -g mycode.cpp -o debugme
– Launch the debugger
  – gdb debugme
  – run
– Set a breakpoint (by line numbers)
  – list
    – to view the entire code
  – break #
    – set pause point at line #
  – Inspecting various information of your codes at that moment
    – print var
    – info locals
**Conditional Breakpoint**
– break # if “condition is true”
**Watchpoint**
– watch var
– When var changes value
**(EARS)**
– Constrained natural language
*Generic Requirements Syntax*
– Pre-conditions; Trigger; System → Response
– the shall
*Ubiquitous Requirements Syntax*
– System → Response
– The shall
*Event-driven Requirements Syntax*
– When Pre-conditions; Trigger → System → Response
– WHEN the shall
*Unwanted Behaviours Requirements Syntax*
– If Pre-conditions; Trigger → System → Response
– IF , THEN the shall
*State-driven Requirements Syntax*
– While States; System → Response
– WHILE the shall
**Black Box Testing**
*Black Box*
– System or component whose inputs, outputs, and general function are known but whose contents or implementation are unknown or irrelevant
*Black Box Testing*
– Pertaining to an approach that treats a black box
– The tester cannot see the inner workings of the software system; they are operating it from the outside
**White Box Testing**
*White Box*
– System or component whose internal contents or implementation are known
*White Box Testing*
– Pertaining to an approach that treats a white box
**Usability Definition**
– The extent to which a system, product, or service can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use
**Accessibility Definition**
– 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**
– git –version
  – show the git version
– git config –global user.name “Handsome Koh”
– git config –global user.email “chkoh005@mymail.sim.edu.sg”
**Setting up Git Repository**
– cd ~/directory/gitKOH/
  – change to gitKOH directory
– git init
  – initialise empty Git repository in gitKOH
  – ~/directory/gitKOH/.git/ created
**Basic Git Commands**
– git status
  – check repository current status
  – branching; committing; staging
– git add example.py
  – git add
  – stage / adding example.py to repository for version control
– git rm –cached
  – un-stage / removing file from repository
– git commit -m “Handsome Version 1”
  – captures a snapshot or milestone along the timeline of a Git project
  – commits are created to capture the project’s currently staged changes
  – confirm a staged file
– git commit –amend
  – un-commit / edit previous commit
– git log
  – show complete log of all changes
  – list the commits done so far
– git branch
  – checking the branch currently at
  – a pointer to a snapshot of changes
  – git stores a branch as a reference to a commit, instead of copying files from directory to directory.
– git branch first-branch
  – create a new branch name first-branch
– git checkout first-branch
  – switch to branch first-branch
– git checkout master
  – switch to master branch
– git merge first-branch
  – merge first-branch into master
– git reset
**Effectiveness**
– The degree to which something is successful in producing a desired result
*Statements:*
– “I thought there was too much inconsistency in this system”
– “I would imagine that most people would learn to use this system very quickly”
– “I found the system very cumbersome to use”
– “I felt very confident using the system”
**Efficiency**
– The state or quality of the useful work performed
*Statements:*
– “I found the system unnecessarily complex”
– “I think that I would need the support of a technical person to use this system”
– “I found the various functions of this system were well integrated”
– “I would imagine that most people would learn to use this system very quickly”
**Satisfaction**
– The fulfilment of one’s wishes, expectations, or needs, or the pleasure derived from this
*Statements:*
– “I felt very confident using the system”
– “I needed to learn a lot of things before I could get going with this system”
– “I think that I would like to use the system frequently”
– “I found the system unnecessarily complex”
—
This is the full version of your notes compressed to fit on a single A4 page without summarization. Let me know if you’d like any adjustments!