Software Engineering Principles

Software Engineering Principles


Software Life Cycle

Modules and Modular Design

Functional Design

Program Testing

<li>A Bank Account Example</li>

Object-Oriented Design

<li>A Bank Account Example</li>

1.1 Software Engineering and Software Life Cycle

  • Large software requires a team.
  • Teamwork needs : an overall plan, organization, communication.
  • Important phases in the software life cycle:
  • The goal is to create a solution that minimize the cost incurring over all the cycle phases
  • A good solution should be
    • easy to use
    • algorithmic efficient
    • well structured
    • well tested
    • easy to modify
  • Careful design is required in order to achieve all of these properties.
  • This course is mainly concerned with
    • object-oriented design
    • data structures
    • and

    • algorithms

    which are the techniques used in C++ programs to build good programs.

  • There are a number of pieces used to describe a program, each with a different language to describe some aspect of how a program is produced from the descriptions.
    • header files are high-level descriptions of module interfaces and have names that end with .h.
    • source files are high-level descriptions of modules and have names that end with .cpp.
    • template files are higher-level descriptions for parts of modules and have names that end with .template.
    • object files are low-level descriptions for modules have names end with .o.
    • library files or archive files are collections of object files and have names that end with .a.
    • executable files have the data and machine instructions for a program and have names that are either a.out or whatever is specified using options on the command line.
    • build scripts describe the steps in the translation process from high-level descriptions to executable files and are in files whose names are usually makefile or Makefile.
  • These pieces are used in the various phases of program translation required to produce an executable program from the high-level descriptions in the various pieces. The following steps are usually involved in producing large programs.
    • compilation translates source files into object files using information in header files and template files.
    • linking and loading gather a number of object files and library files into a single executable file.

We will see each of these steps later in the course, where more complete explanations will be given.

Further reading and references

  • The software engineering life cycle from an object-oriented perspective.
    Use the index in the left frame to look up each of the terms in the software engineering life cycle, including validation and verification, which are defined in the same way they are used in our course notes, which is somewhat different than often appears in other references.

1.2 Modules and Modular Design

  • Fundamental concepts in Program design:
    • structuring and modularization
      • decomposing programs into small modules
    • abstraction
      • separation of the interface from the implementation
    • Efficient data structures.
    • efficient algorithms.
  • A module is a collection of related
    • data
    • operations

    packaged into one (compilation) unit.

  • A module has two parts:
    • public : visible by the client
    • private : invisible outside the module
  • A module exports its public parts.
  • A client imports the public parts of a module.
  • A module interface diagram shows the module’s exported items:

  • Modules provide the means for:
    • encapsulation or information hiding
    • Locality of information and design
    • off-the-shelf components
      • saves money
      • produces more reliable and efficient software
  • Modules should be:
    • highly cohesive ( components are highly related)
    • loosely coupled
    • general enough
  • In C++, a module is represented by a pair of files:
    • a header or specification file
      with declarations of public components
    • a source or implementation file
      with definitions of private and public components
  • A client needs only to include the header file.
  • Examples:
    • Each C++ library is a module.
    • The bank module in the next section

1.3 Functional Design

  • Also known as Top-Down design and Stepwise Refinement
  • Problem decomposition is based on the operations (tasks) involved
  • Problem is repeatedly decomposed into smaller tasks until the fimal tasks are simple functions
    • with well defined interface
    • hiding local decisions
  • Focuses on functional abstraction
    • End result: a set of tasks
    • used for the design of the module operations

1.3.1 A Bank-Account Example

Problem Description

  • The bank wants a program that can handle the accounts of its customers. The program should allow the customers to open an account, deposit and withdraw money and get their balance.


  • A customer can open an account, deposit and withdraw money and get their balance
  • Each account belongs to a single customer
  • A customer may have many accounts
  • Each account has a unique id set by the bank
  • A customer has to supply the account id to use their account
  • If a customer attempts to withdraw more money than in the account, the operation is canceled.
  • The balance of any account should always be >= 0.
    . . .

Functional Design

  • We may split the tasks into:
    • Customer Operations
    • Bank Operations
  • Customer Operations may include:
    • deposit into an account
    • withdraw from an account
    • get the balance of an account
  • Bank Operations may include
    • open a new account
    • close an account
    • etc.
  • May decide to keep  three modules:
    • customer- operations module
    • bank-operations module
    • bank-driver the main driver of the program

1.4 Object-Oriented Design

  • problem decomposition is based on data and their operations
  • a problem is decomposed into a collection of interacting objects
  • end product: a set of classes of objects (modules)
  • focuses on data abstraction
  • provides means for a natural program modularization
    • Classes / instantiation
    • inheritance
    • polymorphism

1.4.1 OO Design for the Bank-Account Example

  • Three modules:
    • Account class handling a single account
    • Bank (or AccountDB)class maintaining the collection of all accounts
    • bank-driver the main driver for the system
  • To complete the design, for each class we should define
    • Its public data
    • Its public operations
    • its invariants.

Sample design for class: Account


  • none


  • Account ( accountID :integer or string , customerName: string, initialBalance: real) creates a new account
  • deposit ( amount: real ) returns nothing
  • withdraw ( amount: real ) returns nothing
  • getBalance ( no arguments) returns account balance
  • getID ( no arguments) returns account id
  • getName( no arguments) returns account name

Class Invariants

  • assigned(account id, customer name, balance) and account balance >= 0

Sample design for class: AccountDB


  • none


  • AccountDB (max-size: integer) creates a new collection with 0 accounts in it.
  • openAccount ( customer_name: string, initial_balance:real )
  • closeAccount ( accountID: string or integer )
  • deposit ( accountID: string or integer , amount:real ) returns real
  • withdraw ( accountID: string or integer , amount:real ) returns real
  • getBalance ( accountID: string or integer) returns real

Class Invariants:

  • at most max-size number of accounts are valid at any time
  • the id of a new account is different from the id of any old account
  • an account does not exist unless it is opened
  • an opened account is valid until it is closed


The account class and account's test driver are implemented in account.C and account-dr.C.

1.5 Program Testing

  • Module Testing Plan
    • Is specified when the module is designed
    • contains the test cases for the module
  • Each test case shows
    • Input values
    • expected results
  • To determine the test cases
    • Partition the input into equivqlent partitions
    • for each partition pick
      • representative values
      • boundary values exceptional values
  • Example: Suppose a module has two positive integer inputs x and y. The test cases are:
    • x>0, y>0
    • x=0, y>0
    • x>0, y=0
    • x=0, y=0

Example: Testing Plan for Account

CASE 1: Typical account

  • Create an account with typical components and display the result.
  • Apply all public op’s and display the results.
  • Create an account with balance 0 and  null string for name and display the result.
  • Apply all public op’s and display the results.

CASE 2: Negative balance

  • Attempt to create an account with balance – 50. It should set balance to 0.

CASE 3: Overdraft

  • Attempt to withdraw from the typical account an amount greater than its balance. Withdrawal should be aborted and an error message should be printed.

CASE 4: Negative amount

  • Attempt to deposit or withdraw a negative amount. Operation should be aborted and an error message should be printed.

Copyright (C) 2000-2005, The University of British Columbia

2 thoughts on “Software Engineering Principles

  1. Hello! This is my 1st comment here so I
    just wanted to give a quick shout out and
    tell you I genuinely enjoy reading through your articles.
    Can you suggest any other blogs/websites/forums that
    cover the same subjects? Thanks a ton!

    1. Thanks for your compliment! There aren’t any websites that I use in particular. If I need to find out about something, Google is my go-to!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.