SEM510 Autumn 1996

Software Engineering

What is “Software Engineering” ? It involves: Software, People, Applications,

Methods, Tools and Practices. Recommended Books. Software Engineering. Ian Sommerville 4th edition

Addison-Wesley Software Engineering: A Practitioner’s Approach.

Roger S Pressman. 3rd edition McGraw Hill. You are recommended to BUY one of these - the

library copies must be shared by a large number of students.

SEM510 Autumn 1996

What is Software ?

A Software System consists of: 1) computer programs 2) data structures, necessary to allow the program

to mainpulate the information 3) documentation, necessary to allow humans to

understand the software

For large programs, documentation is at least as large a job as program development.

SEM510 Autumn 1996

Software Engineering

The systematic development, operation, maintenance and retirement of software.

Concerned with software built by teams rather than individual programmers (e.g. your group projects in semester two.).

Uses engineering principles to develop these systems.

Made up of both technical and non-technical aspects.

A software engineer must be able to communicate fluently - both orally and in writing.

SEM510 Autumn 1996

Need for Formal Methods.

Consider the problems encountered in building large software systems.

The system is too large for any one person to visualise all the details and perceive the effect of any changes.

Formal techniques are required for the specification and design of the project.

Each stage, including a record of testing, must be properly documented.

Careful management is essential.

SEM510 Autumn 1996

Structured Programming.

Necessary for efficient debugging, testing, maintenance and modification of software.

Uses the following concepts.

1) Generalisation (abstraction).

2) Standardisation ( including standard notation for pseudo-code and diagrams).

3) Modularity (decomposition of the problem into several smaller tasks).

SEM510 Autumn 1996

Software Documentation.

This should contain the following: 1) Requirements Specification. 2) Design Description. 3) Program Listings. 4) Description of test data and test results. 5) Conclusions. Recommendations to the users. 6) History of Systems maintenance and any

changes to date.

SEM510 Autumn 1996

Design Description.

Initially discuss the use of pseudo-code for program design.

Top-down method, also called “stepwise refinement” Top-level (usually very brief) gives functionally and

logically correct solution at highest level. Most statements are then refined by adding extra detail.

This may require several refinements. Final level is very close to program code in its detail.

(When producing documentation, you may save paper by including code and comments as the final level of detail. You should work through all the levels yourself when designing the program.)

SEM510 Autumn 1996

Developing Pseudo-Code.

A. Become familiar with the problem definition and input/output requirements.

B. Break down the problem into a few general steps which reflect a valid overall solution.

C. Take each step and break it down into smaller steps which are also logically correct.

D. Repeat step C until all steps have been fully developed.

E. Review the proposed solution for correctness.

SEM510 Autumn 1996

General Top-level Design.

1. Initialisation of parameters.

2. Read in data.

3. Process data.

4. Write out results.

5. Save results (if needed) and Stop.

SEM510 Autumn 1996

Example One: Calculate Average of Numbers.

Set total to zero. Read value of n If n>o then Loop for i from 1 to n read number add number to total end loop set average to total/n write value of average else write error message end if end of program

SEM510 Autumn 1996

Data Tables

The data table lists all the variables used in the program.

For each one, it states: Name Type of Variable Use e.g. for the previous example total integer total of the numbers. n integer how many numbers. i integer counter for loop number integer each number average real average value.

SEM510 Autumn 1996

Modularisation.

A large program needs to be split up into self-contained modules.

It is easier to understand a single module. It is much quicker and easier to test a single

module. If different programmers work on different

modules, the development may proceed in parallel. Some sections of the program are repeated several

times. It is more efficient to have such a section in a separate module and call it several times.

SEM510 Autumn 1996

Segmentation of Programs.

Different languages use different names for the same idea.

FORTRAN uses the terms “subroutine” and “function”. Pascal uses “procedure” and “function” C++ uses “function” and so on. In each case, we have mechanisms for passing data

between the segment and the calling segment, for using global data and for defining local data.

To make segments independent, you should avoid the use of global data.

SEM510 Autumn 1996

Defining the Interface.

Input: the segment receives data from the program (actually segements may be nested to any depth, but I will speak as though the main program is calling a segment).

Output: the segment returns results to the program.

Workspace: the segment defines it’s own local variables as needed.

These should be clearly specified when the segment is defined, with a separate data table for each.

SEM510 Autumn 1996

Use of Segments in Pseudo-Code.

The detailed design for the main program will contain statements referring to the segments used. These should appear in a statement of the form:

SET (RESULTS) USING segment-name(INPUT DATA)

The local variables should be defined in the segment and should be independent of the main program. Names may be re-used without changing the values in other segments. Use of global data can cause unpredictable results and should be avoided.

SEM510 Autumn 1996

Object-oriented Methods

One of the important aspects of object-oriented programming is the definition of data structures as well as methods.

This is not a new idea - 15 to 20 years ago FORTRAN had the facility to define subroutines sharing data in “labelled common” areas. However it has been developed further in the latest versions of Visual Basic and C++ and you will be expected to make full use of it when designing your programs.

The above form of definition will help you to keep these concepts clear while doing your workshop exercises.

SEM510 Autumn 1996

Diagrams and Pseudo-Code.

BS6224 flow-charts. pseudo-code data-flow diagrams. control-flow diagrams. structure charts.

see Pressman chapter 7 or Sommerville chapter 12.

SEM510 Autumn 1996

Example of BS6224

begin

end

pointer = false

X > K ?

Y set pointer to true

x <- X+1

CALL function(X,pointer,result)

result > 0?

print result

set pointer to false

Y

SEM510 Autumn 1996

Simple Flow Chart.

BEGIN

Step One

Step Two

Step Three

END

SEM510 Autumn 1996

IF statement in Flowchart

conditiontrue false

statements to be executed

statements to be executed

thenelse

statements to follow

SEM510 Autumn 1996

CASE statement in Flowchart

i=1?

i=2?

i=n?

true

true

true

statements when i=1

statements when i=2

statements when i=n

SEM510 Autumn 1996

Loops in flowcharts.

repeat

statements inside loop

is end- condition satisfied?

yes

no

is condition satisfied ?

yes

no

while loop for loop

for .......

statements inside loop

statements inside loop

end of loop?

yes

no

SEM510 Autumn 1996

Example of Flow Chart.Procedure Readnext

Loop i=1,4

Write promptRead guess[i]

Is guess[i] OK ?no

End of loop?

yesno yes

display guess

ask if guess OK

input ans

ans=“n”? yesnoEnd

Begin

SEM510 Autumn 1996

Pseudo-code.

may have numbers or not 2 top-level statement becomes 2.1 next level 2.2 giving 2.3 greater detail and so on. equivalent to flow chart - you must decide which is

clearer in any given case indentation to show range of compound statement (e.g.

if, loop etc)

SEM510 Autumn 1996

To Document a Procedure.

Name of Procedure. Purpose of Procedure (One short sentence

indicating what it does.) Calling Statement or Interface. Data Tables for Input data, Output data, Inout

data (if any) and Local variables. Avoid global variables if you want your procedures to be independant and reusable.

Structure of Procedure ( Flow chart, BS6224 or Pseudo-code, whichever you find clearest and easiest to use).

SEM510 Autumn 1996

Work for next Week

For this course, take the three Pascal Procedures for which coding is supplied and produce descriptions using all three methods (Flow chart, BS6224 and Pseudo-code). Hand in your documentation for one of these procedures (I don’t have time to check all 3 procedures for everyone, but you will benefit from doing them so try to find time).

For your workshop, decide which method you prefer and document the procedures as you design them, remembering to update the documentation if you make any changes.