Lecture 1 a Software engineering with components Based

Lecture 1 a Software engineering with components (Based on Stevens and Pooley (2006), Chapter 1) David Meredith d. [email protected] ac. uk www. titanmusic. com/teaching/cis 224 -2007 -8. html CIS 224 Software Projects: Software Engineering and Research Methods

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

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

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?

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)

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) –…

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

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!

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/cis 224 -2007 -8. html for links to web resources on Ariane 5 disaster

Software disasters: Taurus • Automated transaction settlement system for London Stock Exchange • Project cancelled in 1993 after more than 5 years of development • £ 75 m project cost, £ 450 m 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/cis 224 -2007 -8. html for links to web resources on Taurus

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 $200 m actually cost $300 m because of cost of fixing bugs See www. titanmusic. com/teaching/cis 224 -2007 -8. html for links to web resources

Other software disasters • London Ambulance System • System failed twice in 1992 because of defective project management • Cost £ 9 m • 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

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.

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

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 plus time 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.

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/

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

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

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

Interfaces and context 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

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

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 • print. Polar. Coords() • print. Cart. Coords() • Define two private attributes • x • y • print. Polar. Coords() 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 – print. Cart. Coords would then compute (x, y) coordinates on the fly

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

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

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

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

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)

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

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 componentbased design (CBD)

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

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