1. SEM510 Autumn 1996 Software Engineering u What is “Software Engineering” ? u It involves: Software, People, Applications, Methods, Tools and Practices. u Recommended Books. u Software Engineering. Ian Sommerville 4th edition Addison-Wesley u Software Engineering: A Practitioner’s Approach. Roger S Pressman. 3rd edition McGraw Hill. u You are recommended to BUY one of these - the library copies must be shared by a large number of students.

2. SEM510 Autumn 1996 What is Software ? u A Software System consists of: u 1) computer programs u 2) data structures, necessary to allow the program to mainpulate the information u 3) documentation, necessary to allow humans to understand the software u For large programs, documentation is at least as large a job as program development.

3. SEM510 Autumn 1996 Software Engineering u The systematic development, operation, maintenance and retirement of software. u Concerned with software built by teams rather than individual programmers (e.g. your group projects in semester two.). u Uses engineering principles to develop these systems. u Made up of both technical and non-technical aspects. u A software engineer must be able to communicate fluently - both orally and in writing.

4. SEM510 Autumn 1996 Need for Formal Methods. u Consider the problems encountered in building large software systems. u The system is too large for any one person to visualise all the details and perceive the effect of any changes. u Formal techniques are required for the specification and design of the project. u Each stage, including a record of testing, must be properly documented. u Careful management is essential.

5. SEM510 Autumn 1996 Structured Programming. u Necessary for efficient debugging, testing, maintenance and modification of software. u Uses the following concepts. u 1) Generalisation (abstraction). u 2) Standardisation ( including standard notation for pseudo-code and diagrams). u 3) Modularity (decomposition of the problem into several smaller tasks).

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

7. SEM510 Autumn 1996 Design Description. u Initially discuss the use of pseudo-code for program design. u Top-down method, also called “stepwise refinement” u Top-level (usually very brief) gives functionally and logically correct solution at highest level. u Most statements are then refined by adding extra detail. This may require several refinements. u 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.)

8. SEM510 Autumn 1996 Developing Pseudo-Code. u A. Become familiar with the problem definition and input/output requirements. u B. Break down the problem into a few general steps which reflect a valid overall solution. u C. Take each step and break it down into smaller steps which are also logically correct. u D. Repeat step C until all steps have been fully developed. u E. Review the proposed solution for correctness.

9. SEM510 Autumn 1996 General Top-level Design. u 1. Initialisation of parameters. u 2. Read in data. u 3. Process data. u 4. Write out results. u 5. Save results (if needed) and Stop.

10. SEM510 Autumn 1996 Example One: Calculate Average of Numbers. u Set total to zero. u Read value of n u If n>o u then Loop for i from 1 to n u read number u add number to total u end loop u set average to total/n u write value of average u else write error message u end if u end of program

11. SEM510 Autumn 1996 Data Tables u The data table lists all the variables used in the program. u For each one, it states: u NameType of VariableUse u e.g. for the previous example u totalintegertotal of the numbers. u nintegerhow many numbers. u iintegercounter for loop u numberintegereach number u averagereal average value.

12. SEM510 Autumn 1996 Modularisation. u A large program needs to be split up into self- contained modules. u It is easier to understand a single module. u It is much quicker and easier to test a single module. u If different programmers work on different modules, the development may proceed in parallel. u 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.

13. SEM510 Autumn 1996 Segmentation of Programs. u Different languages use different names for the same idea. u FORTRAN uses the terms “subroutine” and “function”. u Pascal uses “procedure” and “function” u C++ uses “function” u and so on. u 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. u To make segments independent, you should avoid the use of global data.

14. SEM510 Autumn 1996 Defining the Interface. u 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). u Output: the segment returns results to the program. u Workspace: the segment defines it’s own local variables as needed. u These should be clearly specified when the segment is defined, with a separate data table for each.

15. SEM510 Autumn 1996 Use of Segments in Pseudo-Code. u The detailed design for the main program will contain statements referring to the segments used. These should appear in a statement of the form: u SET (RESULTS) USING segment-name(INPUT DATA) u 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.

16. SEM510 Autumn 1996 Object-oriented Methods u One of the important aspects of object-oriented programming is the definition of data structures as well as methods. u 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. u The above form of definition will help you to keep these concepts clear while doing your workshop exercises.

17. SEM510 Autumn 1996 Diagrams and Pseudo-Code. u BS6224 u flow-charts. u pseudo-code u data-flow diagrams. u control-flow diagrams. u structure charts. u see Pressman chapter 7 or Sommerville chapter 12.

18. 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

19. SEM510 Autumn 1996 Simple Flow Chart. BEGIN Step One Step Two Step Three END

20. SEM510 Autumn 1996 IF statement in Flowchart condition truefalse statements to be executed then else statements to follow

21. SEM510 Autumn 1996 CASE statement in Flowchart i=1? i=2? i=n? true statements when i=1 statements when i=2 statements when i=n

22. SEM510 Autumn 1996 Loops in flowcharts. repeat statements inside loop is end- condition satisfied? yes no is condition satisfied ? yes no while loopfor loop for....... statements inside loop end of loop? yes no

23. SEM510 Autumn 1996 Example of Flow Chart. Procedure Readnext Loop i=1,4 Write prompt Read guess[i] Is guess[i] OK ? no End of loop? yes noyes display guess ask if guess OK input ans ans=“n”? yes no End Begin

24. SEM510 Autumn 1996 Pseudo-code. u may have numbers or not u 2 top-level statement u becomes u 2.1 next level u 2.2 giving u 2.3 greater detail u and so on. u equivalent to flow chart - you must decide which is clearer in any given case u indentation to show range of compound statement (e.g. if, loop etc)

25. SEM510 Autumn 1996 To Document a Procedure. u Name of Procedure. u Purpose of Procedure (One short sentence indicating what it does.) u Calling Statement or Interface. u 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. u Structure of Procedure ( Flow chart, BS6224 or Pseudo-code, whichever you find clearest and easiest to use).

26. SEM510 Autumn 1996 Work for next Week u 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). u 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.