Software Design

What is Software Engineering?

• Software Engineering = Process of developing & maintaining large software systems
• Uses techniques from the discipline of engineering
• Large software = 100000 lines of code or more
• Many people could be working on the software (problem analysers, solution designers, programmers, managers)
• Systems are expected to be:
  • Reliable
  • Economical
  • Flexible
  • User-friendly
• Documentation and communication become very important

Software Life Cycle

• Analysis
  • Analysis = Describe the problem yourself, as clearly as possible
  • Problems must be clearly understood before attempting solutions
  • Figure out exactly what is required of the solution
  • Problem statements may not express all relevant information
  • To be determined:
    • Information provided (Input data, and its format)
    • Expected results (Output data, and its format)
    • How to handle data entry errors
    • Things that may be assumed
    • How to structure/record solution information (the kind of information, and its quantity)
    • How end users will interact with the program (user interface)
  • Top-down analysis
    • Divide the overall problem into smaller subproblems
    • If a subproblem is still complex, then repeat this process. This creates subsubproblems, and so on.
    • When a subproblem becomes trivial, then the process stops
    • The lowest level subproblems should have singular objectives
    • Results in a structure chart

• Design
  • Algorithm = A sequence of clear steps for solving a problem
  • Developing an algorithm
    • Algorithms have a unique starting point, and one or more unique ending points
    • Each step must have only one meaning
    • The sequence of steps must be clear
  • Results in a very detailed specification of the software

• Coding and documentation
  • Given a clear solution, translate the algorithm into code
  • Should be easy, assuming the design is good enough
  • Good/precise solutions mean easy translation into code
  • Common mistake: Coding too early in software development
  • Documenting the program is vital:
    • Documenting the solution (problem analysis, algorithm)
    • Comments in the program code (use the psuedo code)
    • End user information (how to use the program)
    • This aids future development of the solution or program

• Testing/Verification
  • Vital, if software reliability is to be obtained
  • May require re-development of solution/algorithm/program
  • Testing the program involves:
    • Testing individual modules
    • Testing entire software on a large amount of data
    • Field Testing = Allow selected users to experiment with the software to help discover any problems
  • Test cases
    • Trying a set of inputs
    • Observing the outputs of the program
    • If they are not what is expected, there are "bugs" in the program
    • Choosing test cases:
      • Use known input/output situations
      • Use extremes of data
      • Test valid and invalid inputs

• Maintenance
  • Software becomes public domain
  • Repairs, additions, subtractions are made to the software as required by the users
  • Good documentation and program comments aid this task greatly

• Obsolescence
  • Software is replaced or removed when no longer needed

Example: A Metric Conversion Problem

• Initial statement of the problem:
  A fabric store requires a program to help them convert measurements in square metres to square yards.

• Clarification:
  The required program must allow the user to enter a real number representing square metres, and calculates the equivalent real number representation in square yards, and displays both values in a readable way on the computer screen. It must be obvious which value is in square metres and which is in square yards.

• Structure Chart:

  

• Design

  1. Gather data
      1.1 Prompt user for square metres
      1.2 Get the value in square metres from the user
  2. Perform calculation
      2.1 square yards is 1.196 times the square metres
  3. Display results
      3.1 Display on the monitor the value in square metres
      3.2 Display on the monitor the value in square yards
            

• Program code
  • MetricConversion.java
  • Note correspondences (in some parts) with the structure chart.
  • Note how design is used as documentation

Example: A Pizza Place Problem

• Initial statement of the problem:
  Write a program to find the unit price for a given pizza. The size of the pizza will be provided in inches. The result must be cost/inch².

• Clarification:
  The program must obtain information about the pizza (a real number representing its size [in inches], and a real number representing its total cost). The result is a unit cost (a real number representing price per square inch).

• Structure Chart:

  

• Design

  1. Get data
      1.1 Prompt for the value representing the pizza's total cost.
      1.2 Get the total cost of the pizza from the user
      1.3 Prompt for the value representing the pizza's diameter.
      1.4 Get the pizza's diameter in inches from the user
  2. Perform computation
      2.1 Area is 3.14 times radius squared
      2.2 Unit cost is total cost divided by area
  3. Display the diameter, the total cost, and the unit cost
       

• Program code
  • PizzaCost.java

• Structure Chart

  

• Design

  1. Get information 
      1.1 get starting balance
      1.2 get transaction type
      1.3 get transaction amount
  2. Perform computations
      2.1 if deposit then
              add transaction amount to balance
          else
              subtract transaction amount from balance
      2.2 store result in ending balance
  3. Display results 
      3.1 display starting balance
      3.2 display transaction
          3.2.1 display transaction type
          3.2.2 display transaction amount
      3.3 display ending balance 

• One possible program translated from the pseudo-code
  • CheckbookByDesign.java