Object-Oriented Analysis, Design, and Programming Course

1. Med4Object-Oriented Analysis, Design and Programming David Meredith dave@imi.aau.dk http://moodle.vrml.aau.dk/course/view.php?id=21 Lecture 1a Software engineering with components (Based on Stevens and Pooley (2006), Chapter 1)

2. The aim • To provide you with the skills required for working in a team to build a large software system that • satisfies the users’ requirements • is easy and pleasant to use • is reliable • can be extended and maintained easily • is completed on-time and does not go over budget

3. The main skills to be learnt • How to analyse a problem from an object-oriented perspective using UML and other techniques • How to design an object-oriented system using primarily UML • How to implement an object-oriented design using Java and the Eclipse IDE • How to test and maintain a system using JUnit, SVN, etc. • How to manage and plan a large software project

4. Overview of today’s lecture • Today’s lecture based on first two chapters of • Stevens, P. and Pooley, R. (2006). Using UML: Software Engineering with Objects and Components (2nd Edition). Addison-Wesley. • In two parts: • Software engineering with components • Stevens & Pooley (2006), Chapter 1 • Object concepts • Stevens and Pooley (2006), Chapter 2 • Lecture notes will be very complete and posted on Moodle at • http://moodle.vrml.aau.dk/course/view.php?id=21 • So: • You probably don’t need to buy this book! • You probably don’t need to take many notes!

5. 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?

6. 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)

7. 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) • …

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

9. Millennium bug • Up to about 20 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!

10. Software disasters: Ariane 5 • 4 June 1996: Ariane 5 launcher exploded 40 seconds after launch on maiden flight • Rocket and cargo worth $500 million • http://www.youtube.com/watch?v=kYUrqdUyEpI • 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

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

12. 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 • Cost the city over $1m per day (Standish, CHAOS Report, 1994)

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

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

15. Standish Group CHAOS report (1994) • 31% of projects are cancelled • 53% of projects cost nearly twice their original estimates • Failures in requirements capture were biggest cause of software project failure • unclear or incomplete requirements • changing requirements • lack of user involvement • Also failure to retrospectively analyse why a project failed means that the same mistakes are made over and over again • http://net.educause.edu/ir/library/pdf/NCP08083B.pdf

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

17. Attempted solutions to“software crisis” • Developed object-oriented programming languages • First ISO standardardized OO language is 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 • i.e., the ways in which we analyse problems, design software and plan software projects • Improving software education • Software Engineering Body of Knowledge (SWEBOK) • http://www.swebok.org/ with Ada.Text_IO; procedure Hello is begin Ada.Text_IO.Put_Line("Hello, world!"); end Hello;

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

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

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

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

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

23. 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 • Another example – Temperature class that has getTempInCelsius() and getTempInFahrenheit() operations • Can store Fahrenheit as an attribute or calculate it on the fly

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

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

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

27. Example of multiple interfaces functions as functions as

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

29. 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)

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

31. Example of cohesion

32. 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)

33. 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 • Like deciding to use Lego instead of Meccano • 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

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