Software engineering

Editor's Notes

• #3: Davd Parnas (“Structured programming: a minor part of software engineering”, Information Processing Letters, 88(1-2), 2003), one of the leading researchers on software engineering in the world has argued that “Software Engineering is … a branch of Engineering specialising in software intensive products. ……..it is argued that writing programs, though obviously an essential step in the process, is only a small part of Software Engineering.” That said, it is this essential step that this course is primarily looking at. I assume you have some skill in writing computer programs in Matlab, less in C, and maybe some knowledge of C++/Java, which will have been derived mostly from the 1st and 2nd year Computing practicals. There will be some brief revision of these during the course of the 4 lectures. The overall aim of this course is to take you beyond the narrow syntactical knowledge you acquired in these labs. To do this we will look in quite close detail at some things you have already seen, like functions, because a crystal clear understanding of these will greatly help in understanding how and why various programming practices are “good” and some (many!) are “bad”. I will try to use a mixture of both Matlab and C/C++ to illustrate the general principles.
• #5: The first is a comprehensive “classic” text book on software engineering, now in its 8th edition. Wirth is a classic. Some aspects are outdated, but it remains very sound. Leveson is very interesting and contains valuable lessons, but is really for peripheral reading. Lipmann and Lajoie, and Goodrich et al, are C++ text books. The C++ bible is by Stroustrup.
• #6: Computing is cheap: well, we have to be careful here. Leveson in her seminal book on computers and safety (see course texts) debunks this “myth”, along with several others. Computer hardware is cheap relative to other elctromechanical devices; but the cost of writing and certifying reliable and safe software may be enormous.
• #8: Sizewell B was Britain’s first (only?) Pressurised Water Reactor. It is also notable because the Primary Protection System uses software extensively. This sofwtare is thus an (extreme!) example of so=called safety-critical software; i.e. unexpected operation could lead to disaster. Over 100,000 lines of code were validated in a process that was contraversial, hugely time-consuming and at greatly expensive.
• #9: The A380 incorporates 1400 separate computer programs. These govern everything from XXXXX to XXXX <>fixme>. Indeed there are so many components to the software that there is a separate software project just to manage all the software! (cite)<fixme> CAD software, of course, has played a maor role in the design, but has in fact been at the root of major delays of as much as two years I production. Two of the partners (French and German) used different versions of the CAD software which were unable to interface to one-another. Sigh! (cite)<fixme> Like its predecessors (the first was the A320), the A380 is a fly-by-wire aircraft. This means that some of the software is safety-critical… Like its predecessors (the first f-b-w commercial airliner was the A320) it uses fbw for weight savings and also implemnents a “Flight Envelope Protection System” (i.e. the computer will overrule attempts to take the aircraft outside its safe flying limits). The A320 used 7 computers running sofwtare from two separate vendors (the aim being to minimise the possibility that the same bug would appear simultaneously. See comp.risks archives for extensive discussion of the A380, and if you go back to the archives from late 1980s you will see a lot of discussion about several A320 incidents; more on this in a bit.
• #10: NPfIT is one of the biggest, if not the biggest ever, civil information technology programmes. Sounds like a great plan. Or does it? See later for a little discussion about this project.
• #11: Programmers of course want to produce code that is correct; i.e. it produces the right output for all expected inputs. But beyond this software should ideally be robust, in that it is capable of gracefully handling inputs not explicitly defined for its application. Code that is well designed and implemented will facilitate current and future maintenance, make debugging more easy, and potentially expedite future changes. Well designed software, which has clearly defined interfaces to other code, can be reused to improve correctness, save time, etc. For example, you would not reimplement Matlab's trig functions since these are already implemented in an effecient manner in the Matlab function library, and have a well defined interface (eg put in an angle in radians and get out sine of the angle). Re-inventing the wheel here introduces unnecessary complexity and the possibility of errors. A well-encapsulated module can be re-used.
• #12: In many respects software engineering is no different from other forms of engineering. In designing a bridge, or a building, or a machine, or an electronic circuit, or a control system, the engineer uses a variety of techniques to make the analysis/design of an apparently complex system more tractable. Two key ideas that transcends all engineering disciplines are those of abstraction and modularity. In statics and dynamics the engineer will consider the behaviour of a component by by use of a free-body diagram in which the role of neighbouring/connected components is abstracted as a set of forces. The component can then be considered as a module. In control theory (for that matter any dynamic modelling) we use transfer functions to model dynamic behaviour and a block diagram is an abstract representation of a set of modules dynamic modules. In linear, passive component circuit analysis Norton’s and Thevenin’s theorems enable a complex circuit to be abstracted as a voltage and/or current source and a resistance. And when dealing with transistors and op-amps, one tried to ensure that parts of a circuit have high input impedance and low output impedance so that they can be considered as separate modules with simple interactions (eg output voltage of circuit 1 equals input voltage of circuit two). Of course this reaches an extreme in the design of a digital computer (see A2) which lives in (and is built with) an analogue world, but which is built using logic gates, an abstraction of underlying analogue electronics. In P2/A2 you saw how the transistors/op-amps could be combined to yield flip-flops and and/or (etc) gates. Then how these could be combined into registers. And how registers (a higher level abstraction) could be connected to form a control unit and a data unit, and ultimately to yield a micro-processor.
• #15: Use of software is attractive for these reasons. Consider Airbus A320, huge weight savings in fly-by-wire design. Wires carrying control signals will not fatigue like cables in traditional design. The most complex engineering systems in existence today are almost either software, or heavily reliant on software. A computer's behaviour can be easily changed by modifying its software. In principle, flexibility is a good thing, since major changes can be effected quickly and at apparently low cost. Software does not age in the sense that it will always do the same thing, so it will not fatigue/fail like other engineering systems (distinguish this from the hardware on which the software runs which is of course built from digital circuits). Software cannot be made more reliable by having multiple copies of it. Each copy will behave identically and have exactly the same failure modes. Furthermore, it has been observed that software teams writing code independently to perform the same tasks will often make the same mistakes!
• #16: Discrete behaviour means we cannot interpolate. A bridge can be tested at extreme loads and we can assume it will work for lesser loads, but with software, every input is a separate, distinct situation. Further, the failure behaviour need not be related in any way to the normal behaviour. A computer's behaviour can be easily changed by modifying its software. Though potentially advantageous (see previous slide), ease of change can encourage unnecessary complexity and introduce errors, because it blurs the distinction between what can be achieved versus what should be achieved. It can encourage a shifting of goalposts in specifications. As mentioned earlier, a standard way in all engineering disciplines is to attach complexity via modularity. In physical systems, the physical separation of functions can provide a useful guide for decomposition into modules: the spatial separation of these modules limits their interactions,. Makes their interactions easy to trace and makes introducing new interactions difficult. With software there are no such barriers: complex interfaces are as “easy” to produce as simple ones, and the interfaces/interactions between software components can be invisible or not obvious. Historical data: Consider aeroplane, or bridge design. The starting point for such designs is usually based on sound historical designs, and data collected about such designs over a long period [c.f. Millenium bridge, a new design of bridge that met with unexpected problems]. With much software it is specially constructed and therefore there is very little in the way of historical data to go on.
• #17: Air France Flight 296 was a chartered flight of a newly-delivered fly-by-wire Airbus A320 operated by Air France. On June 26, 1988, as part of an air show it was scheduled to fly over Mulhouse-Habsheim Airport at a low speed with landing gear down at an altitude of 100 feet, but instead slowly descended to 30 feet before crashing into the tops of trees beyond the runway. Three passengers were killed. The cause of the accident is disputed, as many irregularities were later revealed by the accident investigation. This was the first ever crash involving an Airbus A320. On 20th Jan 1992 another incident involving an A320 in which the aircraft descended much too rapidly without the flight crew noticing until it was too late. The official report states that from the moment of descent until impact, the aircraft's high descent rate was adopted and maintained. The official conclusion on the cause of the accident was "pilot error". The “pilot error” in this case was the confusion of the "flight-path angle" (FPA) and "vertical speed" (V/S) modes of descent. These were selectable on the Flight Management and Guidance System (FMGS) console. The pilots were inadvertently in V/S when they should have been in FPA mode. The error was not noticed on the console itself, due to the similarity of the number format display in the two modes. The other cues on the Primary Flight Display (PFD) screen and elsewhere (e.g., altitude and vertical speed indicator) were not noticed since the pilots were overloaded following a last-minute change of flight plan, and presumably were concentrating on the Navigational Display. The report criticised the ergonomic design of the descent-mode selector for being too easy to misread or mis-set. Officially neither of these accidents was caused by software. However the additional complexity introduced – which also of course has advantages – in these cases contributed to the accidents.
• #18: LAS: project to computerise ambulance despatch. To be completed in 6 months. A consortium of Apricot, Systems Options and Datatrak made the cheapest bid and was awarded the contract. Because of time pressures, and the lack of experience of the development team in dealing with safety-critical systems, fundamental flaws in system design, and inadequate consultation with users, the system went “live” even though there were 81 known errors. It ran for a day and a half before being shut down. A further 10-day trial was abandoned and the LAS reverted to manual operation. From the Independent, 30 Oct 1992, “Computer specialists yesterday said that the system blamed for this week's crisis at the London Ambulance Service appeared to ignore basic tenets for software where breakdown would put lives at risk. The failure of the computer system over 36 hours on Monday and Tuesday, which was said to have cost between 10 and 20 lives, raised serious questions about the way it was designed and tested, experts said. Yesterday, the software company involved, Systems Options, refused to comment.” Therac-25: See Leveson, especially Appendix A OSIRIS: Classic failures of trying to build a systemn to serve two different needs and neglecting one. Commissioned in 01/02. In Nov 2003 departmental administrators highlight 10 points critical to operation not adequately addressed, in partic the ability to generate reports central ro management of finances. System goes live in April 2004 with major omissions/flaws and University lucky to escape without serious financial meltdown.
• #19: NPfIT is one of the biggest, if not the biggest ever, civil information technology programmes. Original budget of £2.3billion over 3 years, by June 2006 this was estimated to be £12billion over 10 years. In April and June 2006 in an Open Letters, 23 leading professors of Computer Science wrote to the Health Select Committee calling for a public enquiry: “As computer scientists, engineers and informaticians, we question the wisdom of continuing NPfIT without an independent assessment of its basic technical viability. We suggest an assessment should ask challenging questions and issue concrete recommendations where appropriate, e.g.: - Does NPfIT have a comprehensive, robust: - Technical architecture? - Project plan? - Detailed design? Have these documents been reviewed by experts of calibre appropriate to the scope of NPfIT? - Are the architecture and components of NPfIT likely to: - Meet the current and future needs of stakeholders? - Support the need for continuous (i.e., 24/7) healthcare IT support and fully address patient safety and organisational continuity issues? - Conform to guidance from the Information Commissioner in respect to patient confidentiality and the Data Protection Act? - Have realistic assessments been carried out about the: - Volumes of data and traffic that a fully functioning NPfIT will have to support across the 1000s of healthcare organisations in England? - Need for responsiveness, reliability, resilience and recovery under routine and full system load? In April 2007, the Public Accounts Committee of the House of Commons issued a 175-page damning report on the programme. The Committee chairman, Edward Leigh, claimed "This is the biggest IT project in the world and it is turning into the biggest disaster." The report concluded that, despite a probable expenditure of 20 billion pounds "at the present rate of progress it is unlikely that significant clinical benefits will be delivered by the end of the contract period."
• #20: Specification: engineers and customers collaborate to specify objectives (what should it do?) and constraints. This process would typically be iterative, refining vague ambiguous objectives into more formal, tightly specified ones that clarify assumptions System/Software Design: the requirements specification is then mapped onto an overall architecture of the system (both hardware and software, probably including choices of programming language). Software design involves identifying and describing the fundamental sofwtare abstractions asnd their relationships (i.e. identifying individual software components and designing their interfaces). Implementation: software design is realised as a set of units or programs or modules. Unit/modules are tested to ensure each meets its specification. Integration and Validation: components brought together and tested rigorously to ensure conformity to user-requirements and correctness Operation/Maintenance/Evolution: system installed, modifications to adapt to changing user-requirements; maintenancce involves correcting errors that were not discovered earlier, imoroving the implementation and enahncing the services as new requirements are discovered. Because software is invisible, signoff will often involve production of copious documentation .
• #21: What does the statement n-bounce trajectory mean? We could either assume that this means “given a set of initial conditions, work out n”, or it could mean, “given n, work out what the initial conditions would need to be”. This may inform how we set about the task, or how we represent the trajectory (or if we even represent it at all).
• #22: Verification checks the system against its specification, while validation checks that it actually meets the real needs; the two may be different if there were problems moving from the vague mission statement to the formal requirements in the design process. Testing at the module/unit level should happen concurrently with implementation so that errors are found as quickly as possible. Top down testing involves coding top-level components first and substituting trivial “stubs” for the lower-level functionality that has not yet been implemented (eg writing a simple function that returns a number corrupted by a random element to simulate a sensor module). Bottom up testing involves building the lowest level components first and testing them using a “test harness”. Black-box testing checks a component by examining its outputs for a set of controlled inputs to check they match the specification. White-box, on the other hand, examines the internal structure of a module exercising every line of code and every decision point. It can be useful for checking limiting conditions which are a common source of error and may be missed in black-box testing. As mentioned previously interpolation is not possible in the discrete world of computer hardware and software, but exhaustive testing is impossible for all but the simplest (trivial) systems.
• #23: Incremental development supported through small, frequent releases of code; requirements specified via a set of customer scenarios forming the basis for planning; Customer involvement in the development cycle, defining acceptance tasks, etc Pairs of programmers work very closely together, collective ownership of code Change supported through regular releases, and continuous integration Simplicity maintained by use of simple designs that deliberately do not anticipate future requirements. Instead constant refactoring to improve code quality. Extreme programming takes the position that most design for change is wasted effort. Instead, code is re-factored: the programming team is constantly looking for improvements and implements them immediately; the software is then ideally easy to understand, facilitating change as/when necessary. Beck, 1999, “Embracing change with extreme programming”, IEEE Computer 32((10).
• #24: Top down design means breaking the problem down into components (modules) recursively. Each module should comprise related data and functions, and the designer needs to specify how these components interact – what their dependencies are, and what the interfaces between them are. Minimising dependencies, and making interfaces as simple as possible are both desirable to facilitate modularity. By minimising the ways in which modules can interact, we greatly limit the overall complexity, and hence limit unexpected behaviour, increasing robustness. Because a particular module interacts with other modules in a carefully defined manner, it becomes easier to test/validate, and can become a reusable component. Note the reference to the general engineering principles of abstraction and modularity. A word about each ion its software context: Abstraction: the idea here is to distil the software down to its fundamental parts, and describe these parts precisely, but without cluttering the description with unnecessary details such as exactly how it is implemented. The abstraction specifies what operations a module is for, without specifying how the operations are performed. A function header with a sensible name is an example of such an abstraction. The Matlab function header: function y = sin(x) tells us almost enough about this function to use it without ever needing to know how it is implemented (of course it doesn’t quite, since this specification does not expose the units of the angle x). Modularity: the aim is to define a set of modules each of which transcribes, or encapsulates particular functionality, and which interacts with other modules in well defined ways. We will explore this in the context of functions when we look at side-effects and global variables. The ore complicated the set of possible interactions between modules, the harder it will be to understand. The bottom line is that humans are only capable of understanding and managing a certain degree of complexity, and it is quite easy (but bad practice) to write software that exceeds this capability.
• #25: In 1975 Niklaus Wirth, famous Swiss computer scientist (investor of Pascal, Modula 2), wrote a seminal text called Algorithms + Data Structures = Programs. While the top-down design methodology is a general tool, how we approach it will potentially be language dependent. In procedural programming the design concentrates on the functional requirements and recursively subdivides the functionality into procedures/functions/subroutines until each is a simple, easily understood entity. Examples of procedural languages are C, Pascal, Fortran, Matlab In object-oriented programming the design emphasis shifts to the data structures and to the interfaces between objects. Examples of object-oriented languages are C++ and Java.
• #26: Donald Knuth interview, 7/12/1993: “You can create the parts in whatever order is psychologically best for you. Sometimes you can create them from the bottom up. Bottom-up means that you know somehow that you probably need a subroutine that will do something, so you write it now while you're ready, while you're psyched for it. With this bottom- up programming, your pencil gets more powerful every page, because on page nine you've developed more tools that you can use on page ten... your pencil is stronger. With top-down programming you start at the beginning and say "I'm going to do this first and then this, and then this"... but then you have to spell out what those are--- you can wind up gasping for breath a hundred pages later when you finally figure out how you're actually going to do those things! Top-down programming tends to look very nice for the first few pages and then it becomes a little hard to keep the threads going. Bottom-up programming also tends to look nice for a while, your pencil is more powerful, but that means you can also do more tricky stuff. If you mix the two in a good psychological way, then it works, even at the end. I did this with TeX, a very large program: 500+ pages of code in the book . Throughout that entire program, all those lines of code, there was always one thing that had to be the next thing I did. I didn't really have much choice; each step was based on what I'd done so far. No methodology would teach me how to write a piece of software like that, if I followed it rigorously. But if I imagined myself explaining the program to a good competent programmer, all that this long program was, then there was just this one natural way to do it. The order in which the code appears in the book is the order in which I wrote it.”
• #27: Traditional flow charts are a rather cumbersome and outmoded way of designing code. There is a strong emphasis on the sequences of operations and decisions that is probably better represented using pseudo code [picture from EDraw website] Pseudo-code is representation of program structure that is an intermediate between natural language and proper programming language. The structure of the program is expressed by the formatting (note indentation, etc).
• #28: Data flows,on the other hand, can be very useful in helping to abstracting the system architecture, and begin to define interfaces. One notation uses rounded rectangles to represent functional processing, rectangles to represent data stored, and arrows between boxes to represent data movement. Sommerville p175
• #29: State machines represents how a system responds to internal and external stimuli, by showing how the internal state of the system changes in response to events. This representation should be familiar from P2/A2 Digital Logic and Computer Architecture courses. Unlike the data-flow model, the state machine representation does not show the flow of data within the system. State machines are often useful abstractions when dealing with real-time systems, because these are often driven by external events. In the example the diagram (taken from Sommerville p176) shows how the states of a simple microwave oven vary.
• #31: Of course a much more efficient way of doing this in Matlab would be to make use of the fact that the in-built data type is a matrix and that this could be achieved as: x = [1:N]; tot = sum(x); totsq = sum(x.*x); Things to note are sequences of instructions. Note the different role played by the semicolon in the two languages. In C/C++ the ; denotes sequential statements. In contrast in Matlab the sequence is implicit from the different lines and the semicolon suppresses the output which would (implicitly) print the value of the variable to the console. In Matlab a group of sequential statements is bracketed by an initial statement (in this case “for” and and “end” statement. In C/C++ a group of sequential statements is denoted using “{ }”. C/C++ are strongly typed languages. This means variables must be decakred before use, and given an explicit type. In Matlab when a new variable name is encountered it is dynamically created. All variables in matlab are matrices of real numbers. In this case “tot” and “totsq” (and for that matter “i”) are simply 1x1 matrices (i.e. Scalars). Note the unfamilar “<<” notation used in the C code. This is actually C++ code; C++ implements i/o using “streams” and the streaming operators “<<” and “>>”. “cout” is the standard output stream (the console) and so the last two lines should be interpreted as writing the value of tot followed by a new line to the console.
• #32: All of these points are aimed at producing code which is clear and as simple as it needs to be. This in turn will aid with debugging, modification and maintenance of the code. Encapsulation is an important concept and we will discuss this in more detail with regard to functions and to data structures later in the course.
• #33: Note that Matlab does provide object-oriented support, but I do not discuss the details in this course. Matlab is an interpreted language (or at any rate, it is best thought of as being interpreted). Each statement is decoded and executed in turn. C is a compiled language
• #35: Confusingly in Matlab, (and in my view irritatingly) the name of the function in the function call is the filename, not the name that appears in the function header. Work that out!
• #37: Each .c file contains the implementation details of one or more functions and global variables Each is compiled independently of other code modules isolation to produce an object file (.o)
• #39: In Matlab this would live in a .m file. In C/C++ this would live in a .c or .cpp file
• #40: The formal parameters are the parameters that appear in the function definition. They are placeholders for the values of the inputs; in this way they are analogous to the use of a variable in an algebraic expression. In the case of fact there is only one formal parameter, n. The actual parameters are the values that get passed in at the time the function is called. In the examples above the actual parameters are 10, and 6 (since this is the value of “a” at the time fact(a) is called. Carrying the analogy of algebraic expression forward, the function call is an evaluation of the expression at a particular value, given by the current value of the actual parameter(s). C permits only one return value (can be a significant limitation!). This value is indicated in the definition using the “return …” statement. This return value becomes the “value of the function”. Matlab, in contrast, allows multiple return values. Matlab does not use the “return …” notation. It is rather more elegant: the placeholders to be used for the outputs are indicated in the function header as “function [a,b,c] = myfunc(d,e,f)”. Here d,e,f are input placeholders and a,b,c are output placeholders. In the eig example, the first output is assigned to the matrix V, and the second to the matrix D.
• #41: The implementation detail of myexp is in the .c file. In order to use the function, we do not need to know the internal detail from the .c file, just the function prototype in the header (.h) file. If you design a module that uses the function myexp, you need to include the prototype at the top of the code; more usually you put the prototype into a file with a .h extension and use the compiler directive #include “myexp.h” The whole C standard library is built like this, and to use functions from it you issue #include <math.h>. During the linking phase of Modules are then linked together to resolve undefined references. The prototype encapsulates the function interface and hides the implementation detail Though Matlab does not enshrine the prototype in quite the same explicit way, if it helps, think of the descriptions returned by “help xxxx” in matlab as being the prototypes: you find out the interface without being exposed to unnecessary implementation detail. Just for completeness, here is a version of myexp in Matlab: function y = myexp(x) precision = 1e-6; term=1; y=0; i=0; while abs(term)>precision y = y + term; i = i+1; term = x^i/factorial(i); end end
• #42: Note that in a Matlab context, variables are not declared explicitly. When a variable is used for the first time it is declared. If this use involves looking up the variable’s value it will cause an error: it must be an assignment, which implicitly declares the variable and sets its initial value. A common source of error in C programs is to forget to initialise the value of a variable before using it – the declaration does not set the value, it just allocates some memory.
• #43: Global variables are usually the resort of the lazy programmer. In general good practice dictates that you declare variables as close to where they are used as possible, and restrict their scope as much as possible. Matlab guards against “indiscriminate” use of globals within functions by assuming that all variables are local and giving an error if there is a reference to an unknown local variable – unless the variable has been explicitly declared global inside the function, viz: global varname; In contrast, if there is no local variable that matches a variable in an expression, then C checks to see if there is a global one and uses that if there is.
• #44: In the example, the inputs are the same to function “myexp”, but the output is different. We have used a global variable “precision” to govern the roundoff error in our exp function (we might think this is a good idea because we could use it for all functions involving a calculation of this sort, like sin and cos, etc). Later, we quite understandably used the term precision for the reciprocal of variance (as is common terminology), forgetting to declare it as a local variable in function “_tmain”. Resetting this to 1/variance drastically affects the output of myexp! It is easy to say “you made a silly mistake not declaring precision in _tmain”, but this misses the point. One way around this would be to make the global precision a const, viz: const precision = 1.0e-6; Then the assignment in _tmain would generate an error at compile time. However again the main point is that by making exp depend on something global, we effectively make its interface less transparent.
• #46: There is a temptation to use “easy” techniques like global variables rather than rigorously defining function interfaces, but this is the resort of the lazy programmer and can lead to very obscure errors. Do not be fooled by the simple examples in the lecture. The complexity of a program even for relatively simple tasks grows rapidly to the point where it is very easy to make unknowing errors in coding. In large projects, with multiple programmers working in teams this type of error can create enormous problems – one team may have no conception of the consequences of its implementation choices on another team. Errors relating to poor interface design may be obscure and hard to trace and eliminate. At best this creates expense, at worst serious risk of operational failure. Because of the way so-called object-oriented programming encapsulates related data and functions together, emphasizing the interfaces between objects, it has become the paradigm of choice for large projects. Implement an object correctly, with the right interface, and it can be used with confidence as a building block.
• #47: Whenever a function is called, the stack is use to store: return location (JSR, RTS machine code) parameter values local variables return values When a function returns the stack shrinks as the local variables are removed. Execution returns to wherever the function was called from (as given by the return location), and the parameters are removed from the stack. Finally the return values are removed from the stack.
• #48: Usually best to think of parameters as being values. All parameters in Matlab are passed by value. If you change the values of the formal parameters in the function, this has no effect (see example of “swap” when a and b are passed by value). However in C (well, actually, C++) you can specify that parameters are passed by reference. This is done with the & operator. Instead of placing the value of an actual parameter on the stack, the location of the actual parameter is placed on the stack. The compiled machine code uses indirect addressing to access the parameters (recall from A2?) One reason for this is to overcome the limitation that C only permits one return value. If not exercised carefully and in a completely transparent way, changing pass-by-reference parameters in a function can destroy its encapsulation. One sensible way of managing this would be to have all input parameters first in the list, followed by any “output parameters”, and make this clear in any comments and.or documentation. Note, also, that arrays in C/C++ are always passed by reference. This means that changes to array elements in a function “stick” – they remain after the function returns. This is not the case in Matlab.
• #49: When either designing recursive functions, or considering if a particular problem can (or should!) be solved recursively, it is useful to think about ways in which the problem can be subdivided into one or more problems with the same structure as the original. In some cases there are no gains to be had over a simple iterative version, and in other cases a naïve recursive version can be very inefficient (consider a simple implementation to compute the nth fibonacci number, fib(n) = fib(n-1) + fib(n-2) -- a naïve implementation would end up computing fib(2) many times. Exercise: can you think of a smart way of doing this in Matlab?). However the power of recursion lies in (i) the fact that recursive implementation are often beautifully elegant and map cleanly onto a problem specificiation; (ii) significant gains can be had using a divide-and-conquer approach. Typically one starts with a problem and then divides it into two wit the same structure, recursing, then combines the two in a clean way. Examples of this are the sorting algorithm due to C A R Hoare (QuickSort), with a run-time of O(NlogN), and the Fast Fourier Transform due to Cooley and Tukey.
• #52: The data elements that make up the class/struct are known as fields
• #53: We could represent the state as a set of four “atomic” variables. However this would not capture the conceptual relationship between the variables, and would result in code has a more complicated interface. The controller would need to take 4 input variables instead of one! Likewise the simulator output would be four quantities. Harder to understand, less close to our data flow diagram.
• #54: Data fields are accessed using the “.” (dot) operator. “s” is a variable of type “State”. In object-oriented terminology, “s” is an instance of “State”.
• #55: As shown on the previous slide, the use of classes is another way of returning multiple values from a function in C. Recall that an alternative is to use reference parameters. How do you decide which to use? If the data really are conceptually related, then put the data together in a class/struct. If they are not then consider using reference parameters. An example of when this might happen would be if you want to return some data unless there is an error, in which case you want to flag the error. Two possibilities are shown in the slide. I would recommend the second form: bool ReadImage(const string filename, Image& im); The informed reader would see this as one input parameter (indicated by the const keyword which means the function is not allowed to change its value), and one output parameter (Image& im is a reference to an image). This function will return an image, read from the file specified, but also return a boolean value to indicate if the read was successful. In Matlab, the cleaner looking function header (prototype) would be that makes it absolutely clear what the inputs and outputs are: function [Image, errflag] = ReadImage(filename)
• #56: Of course arrays are supported pretty much as atomic types in Matlab.
• #57: C/C++ provides no inbuilt runtime checking of array bounds, so beware – it is possible to access, eg d[1][7]. Because of the way arrays are stored, this will actually return the value stored in d[2][2] (why??). If you are lucky, your program will crash with a “Segmentation Fault” or something nasty like this. If you are unlucky, it will apparenrly run but give nonsensical results and be very difficult to trace.
• #59: Methods, like data fields, are accessed using the dot operator.
• #60: The third form above int i(10) is the C++ style of initialisation. This form makes it clearer that the constructor is being called. The constructor is defined in the class definition like any other method. It is called when an instance of the class is created (ie a variable of that class is declared) Live example.
• #62: The private data fields of an instance of the Complex class, cannot be accessed by other software components. Instead, these components must use the so-called accessor methods Re() and Im().
• #63: Here, the internal representation of Complex has been changed. This has necessitated a change to the internal workings of each of the methods, but the interface, the way other software components use this class, has remained unaltered. This is the essence of encapsulation and it is the reason why it is such an important programming concept. The interface captures all the functionality that is required for other program components to use the class.
• #64: In C++ programs the header file (.h) plays a much more important role than in C. Every program element that uses the Complex class needs to know how it is defined. Well, actually, more specifically, each program element needs to know the interface. This part, which is, captured in the header file is then incuded in every module that uses Complex: #include “Complex.h” The implementation detail is in the .cc or .cpp file
• #65: The implementation of each method in the Complex class appears in the .cpp file. The class scoping operator “::” is used to inform the compiler that each function is a method belonging to class Complex.
• #66: Strictly speaking, the first three points apply to so-called object-based programming. They are general design principles. Object-oriented programming includes further powerful mechanism that help organise hierarchies of objects (inheritance), and enable objects in the same hierarchy to respond in tailored ways to the same events (polymorphism). Object-oriented programming has become the programming paradigm of choice for large projects. The reason is that OOP actively encourages encapsulation. By specifying the object interfaces clearly in the design phase of a project, teams of programmers can then implement the components with some assurance that the components will all work together.
• #67: A class in C++ inherits from another class using the : operator in the class definition. The code above reads “class A inherits from class B”.
• #68: The class at the top is known as the base class. A GraphicsWindow, for example, has the data fields width, height, posx, posy, background_colour And the methods raise(), hide(), select(), iconify(), clear() and fill() An InteractiveGraphicsWindow does not add any data fields, but does add methods that deal with mouse interactions.
• #69: Notice that in the previous example, both TextWindow and GraphicsWindow have a method redraw(). Indeed it will probably be the case that we want a redraw() method for any type of window. We could get this, of course, by putting the method redraw() into the base class, but what if the way to redraw a TextWIndow is different from the way to redraw a GraphicsWindow? For example a TextWidnow redraw() method will probably render all the characters that are currently in the window in the right font, etc, while the GraphicsWindow redraw will display an image, or render a pipeline of graphics drawing commands. The idea behind polymorphism is to permit the two different window types to share the interface redraw(), but implement it in different ways. Thus different objects (TextWindow and GraphicsWindow) respond to the same event (eg a raise() event which calls a redraw() event) in different ways.
• #71: #include <iostream> using namespace std; class A { public: virtual void func() { cout << "A\n"; } }; class B : public A { public: void func() { cout << "B\n"; } }; class C: public A { public: void func() { cout << "C\n"; } }; void callfunc(A param) { param.func(); } int main(int argc, char* argv[]) { A x; B y; C z; x.func(); y.func(); z.func(); callfunc(x); callfunc(y); callfunc(z); return 0; }
• #72: Slightly technical point to do with C++ (rather than being a general principle): an array can only store objects of the same type. In this case it stores pointers to (ie the memory address of) each object. The -> operator does the same thing as the dot operator, but dereferences the pointer (looks up the object via the memory address) first.
• #75: Programmers regularly use similar, or even identical design solutions for problems.
• #76: The Standard Template Library is a suite of code that implements (among other things) classes of container types with standard ways of accessing elements, inserting, adding, deleting elements, etc, as well as a set of standard algorithms that operate on these classes (eg searching, iterating over all elemnets, etc). While these could all be coded from scratch by a competent programmer, code re-use in this way speeds development and reduces the possibility of introducing errors in the implementation. This addresses one of the issue with Software Engineering discussed in lecture 1, that of the lack of historical design data to rely on. The point here is that though different applications will have to represent different data, and will therefore have custom classes, it is common for the organisation of multiple instances of these classes to be done in standard ways (such as in an array). The use of custom classes is at first thought problematic if we want to implement these standard containers until we realise that templates enable us to write the generic, templated code, and specialise it to our custom classes at compile-time.
• #80: An iterator is a class that supports the standard programming pattern of iterating over a container type without exposing the underlying representation of the container type itself (cf iterating using an integer index – this relies specifically on the ability of the representation to index).
• #81: Refine specification. Not much to do here: How will the size be specified? How to print it out? What algorithm to use? Now design data structures…
• #82: Now design the data structures. In particular, think about the classes and the class interfaces.
• #83: // cell.h // #ifndef _cell_ #define _cell_ class Cell { public: Cell(); bool Visited(); void MarkVisited(); bool BottomWall(); bool RightWall(); void BreakBottom(); void BreakRight(); private: bool bottomwall; bool rightwall; bool visited; }; #endif //_cell_
• #84: // maze.h // #ifndef _maze_ #define _maze_ #include <vector> #include "cell.h" class Maze { public: Maze(int width, int height); void Compute(int x, int y); void Print(); private: int Rand(int n); int H, W; std::vector< std::vector<Cell> > cells; }; #endif //_maze_
• #85: // mazemain.cpp : Defines the entry point for the console application. // #include <iostream> #include "maze.h" using namespace std; int main(int argc, char* argv[]) { int width, height; cerr << "Enter maze width: "; cin >> width; cerr << "Enter maze height: "; cin >> height; Maze m(width, height); m.Compute(height-1,0); m.Print(); return 0; }