CIS224 Software Projects: Software Engineering and Research Methods

1. CIS224Software Projects: Software Engineering and Research Methods David Meredith d.meredith@gold.ac.uk www.titanmusic.com/teaching/cis224-2007-8.html Lecture 1a Software engineering with components (Based on Stevens and Pooley (2006), Chapter 1)

2. Set books and web page • Set books: • Stevens, P. and Pooley, R. (2006). Using UML: Software Engineering with Objects and Components (2nd Edition). Addison-Wesley. • Fowler, M. (2004). UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition). Addison-Wesley. • Web page: • www.titanmusic.com/teaching/cis224-2007-8.html • All lecture slides will be posted on this web page • So you don’t need to write down everything I say!

3. Overview of this lecture • Software engineering with components • Stevens & Pooley (2006), Chapter 1 • Object concepts • Stevens and Pooley (2006), Chapter 2

4. Basic questions • How do we know if a system is good? • Do we have good systems? • What are good systems like? • How do we build good systems?

5. How do we know if a system is good? • High quality system is one that meets its users’ needs • Must be • useful and usable • reliable • flexible (easily improved and maintained) • affordable (to buy and maintain - i.e., easy to build and maintain) • available (must run on available hardware and OS, project must complete successfully)

6. Do we have good systems? • Yes! • Book and document preparation • Banking • Finding information (e.g., internet, library catalogues) • Communication (e.g., e-mail, mobile phones, instant messaging) • …

7. Problems • Systems become out of date over the course of development • Users' needs missed during requirements capture • Users' needs change over course of development so that delivered software does not satisfy needs • Companies commonly cite "computer error" as an excuse for poor service • Most users expect their programs to crash quite often

8. Millennium bug • Up to about 15 years ago, disk storage was relatively much more expensive • So developers tried to save space by storing only the last two-digits of the year information in dates • With the new millennium, this had to be changed so that all four year digits were encoded • Many older systems that had been running for years had to be abandoned • Too expensive to make necessary changes • Implies original software was insufficiently flexible and easy to maintain • Couldn't even make this simplest change to the year format!

9. Software disasters: Ariane 5 • 4 June 1996: Ariane 5 launcher exploded 40 seconds after launch on maiden flight • Rocket and cargo worth $500 million • Due to failure of Inertial Reference Systems (SRI) • Computer system that measures attitude and movement of launcher • Failure caused by software trying to convert a 64-bit floating point value for a horizontal velocity into a 16-bit integer • Caused operand error which caused software to crash • Software same as that used on Ariane 4 • But horizontal velocity on Ariane 4 never reached as high a value as on Ariane 5 so was not a problem on Ariane 4 • Software re-used without thoroughly testing its operation in the new context • See www.titanmusic.com/teaching/cis224-2007-8.html for links to web resources on Ariane 5 disaster

10. Software disasters: Taurus • Automated transaction settlement system for London Stock Exchange • Project cancelled in 1993 after more than 5 years of development • £75m project cost, £450m loss to customers • Causes: • Tried to do too much in one go: tried to simplify(!), computerise sale of stocks and shares and make process paperless • Chose expensive new system instead of modifying existing one • Used committees with conflicting interests to specify requirements • Had two competing consultancies (Andersens and Coopers & Lybrands) working on the project • See www.titanmusic.com/teaching/cis224-2007-8.html for links to web resources on Taurus

11. Software disasters:Denver baggage handling system • Complex system involving 300 computers • Project overran badly • delayed opening of airport by 16 months (opened Feb 1995) • product extremely buggy • original budget $200m • actually cost $300m because of cost of fixing bugs • See www.titanmusic.com/teaching/cis224-2007-8.html for links to web resources

12. Other software disasters • London Ambulance System • System failed twice in 1992 because of defective project management • Cost £9m • People died that would not have if system had not failed • Therac-25 • Radiation therapy machine used for treating tumours • 1985-7 at least 6 people suffered severe radiation overdoses • At least 3 people died from the overdoses • Due to lack of quality assurance • Software interlocks did not prevent machine from being placed in a dangerous configuration • RISKS forum: http://catless.ncl.ac.uk/risks

13. Most large software projects fail • large projects take 50% longer than planned on average • 75% of large projects fail • 25% of large projects are cancelled • Source • Gibbs, W. W. (1994). Software's chronic crisis. Scientific American (International Edition), pp. 72--81, September 1994.

14. Standish Group CHAOS report (1994) • Failures in requirements capture were biggest cause of software project failure • unclear or incomplete requirements • changing requirements • lack of user involvement

15. The Mythical Man-Month • Time taken to complete a project does not necessarily get less just because you use more people • It may even increase! • Time required to do a job is time taken by individual to do work plustime taken to communicate with other team members • If all workers have to communicate with each other, amount of time spent communicating is proportional to the square of the number workers (n(n-1)/2) • Therefore proportion of total project time spent communicating increases quadratically with the number of workers, whereas amount of non-communication work to be done by each worker decreases only linearly • Source: Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.

16. Attempted solutions to“software crisis” • Ada • commissioned by US Dept of Defense • standardized in 1983 • incorporated principles like modularity and encapsulation • Used in Ariane 5 SRI software! • Improving software methodologies • Improving software education • Software Engineering Body of Knowledge (SWEBOK) http://www.swebok.org/

17. What are good systems like? • Fundamental problem in software engineering: • There is a limit to how much a human can understand at any one time • A small system can be completed by "heroic programming" • On larger systems, impossible for one developer to know and understand everything about the system • implies must be able to develop or maintain system without understanding all of it in detail

18. Spaghetti code • Change in one line of a program could affect behaviour in some completely different part of the program • Particularly bad when use "GOTO" statements which allow execution to jump suddenly to any other part of the program • Can result in “spaghetti code” • impossible to understand and maintain • code obfuscation programs use GOTO statements to intentionally make code impossible to read! • See • Dijkstra, E. (1968). Goto statement considered harmful. Communications of the ACM, 11: 147--8.

19. Modularity and encapsulation • To avoid being unable to predict effects of changes • use MODULARITY and ENCAPSULATION • MODULE: identifiable part of a system • e.g., file, subroutine, function, class, package • Cannot just arbitrarily split system into files • System has to be carefully decomposed into modules with low coupling or low dependency • A is dependent on B if change in B might necessitate change in A • If A depends on B, A is client of B and B provides services to A • Each module must be as independent as possible

20. Interfaces andcontext dependencies • If we make a change to module M, need to know • Which modules are clients of M • What assumptions these clients make about the structure and behaviour of M • Therefore need to know about • Interface of M • Context dependency of M

21. Interfaces • Every module has an interface which defines the features of the module on which its clients may rely • Interface defines services that a module can provide to its clients • Interface encapsulates the module • Hides details of module that client modules don't need to know about • Defines the ways in which clients may use the module • Interface must be designed and documented so that • A change to the module that doesn't change its interface won't necessitate any changes elsewhere

22. Interface example • Class Point represents a point in 2 dimensions • Class Point can be printed in polar co-ordinates (r,Θ) and cartesian co-ordinates (x,y) • Define two public operations • printPolarCoords() • printCartCoords() • Define two private attributes • x • y • printPolarCoords() actually computes r and Θon the fly, but the user and any client module doesn’t need to know that • Could change Point so that position stored as polar coordinates without having to change public interface • printCartCoords would then compute (x,y) coordinates on the fly

23. Context dependencies • Well-designed system exhibits low coupling or low dependency • But a module may still require services from other modules in order to work • If we re-use a module, we need to provide it with the other modules whose services it requires • Context dependencies of a module are the services that it requires to work • Interface and context dependencies of a module are a contract defining the services the module will provide if its context dependencies are satisfied

24. Benefits of encapsulation and modularity • Interface encapsulates module • Hides details that users and other modules don’t need to know about • Benefits • Less for developers to learn • More productive, less confused, better understanding, fewer errors • Easier to debug • Only need to look in clients and servers of a module • Easier to reuse module • Know its interface and context dependencies

25. A module may have many interfaces • Sometimes a client to a module only needs part of that module's functionality • Another client might need some other part of the server module's functionality • The same server module could be defined to have two different interfaces • each interface giving access to a different subset of its functionality • Example: Java class may implement more than one interface

26. What are good systems like? • So far: • A good system • has low coupling • consists of encapsulated modules

27. Abstraction • Abstraction is about • representing the important features of a thing • hiding and ignoring irrelevant details about the thing • A good interface provides a good abstraction of a module by • allowing access to its important features • hiding irrelevant details of how the module works (information hiding)

28. Cohesion • A module exhibits high cohesion if it is difficult to decompose into smaller modules • Example: • COHERENT (COHESIVE) class: • All methods use all instance variables • NOT COHERENT (COHESIVE): • Can partition methods into two sets so that no instance variable is used by methods from both sets

29. Components and abstractions • A module is a good abstraction if it has • high cohesion • low coupling • an appropriate level of information hiding • simulates well the behaviour and structure of an identifiable “thing” • A module which is a good abstraction may be • reusable • replaceable • A component is a reusable, replaceable module • Only possible if architecture supports component-based design (CBD)

30. Component-based design(“Pluggability”) • Easiest way to make a new system is to take components and plug them together (like Lego) • Components have to be compatible with each other • implies all components make same basic architectural assumptions • e.g., dimples are all the same size and same distance apart on Lego components • Architectural assumptions • have to be set early in a project • are affected by the nature of the components in the architecture • may be influenced by the environment of the project • e.g., hardware platform, operating system • Architecture-centric, component-based development gives a high priority to • making and following good architectural decisions • developing and using good components • Object-orientation supports architecture-centric, component-based development

31. What is a good system like? • A good system uses loosely coupled, encapsulated modules (components) that • have good interfaces • allow access to important features • hide irrelevant details of how module works • are good abstractions • high cohesion • appropriate information hiding • simulate well behaviour and structure of identifiable things • are reusable • are replaceable