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 dave@imi. aau. dk http: //moodle. vrml. aau. dk/course/view. php? id=21 Med 4 Object-Oriented Analysis, Design and Programming

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

The main skills to be learnt • How to analyse a problem from an objectoriented 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

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 (2 nd 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!

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

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=k. YUrqd. Uy. Ep. I • 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

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

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

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) • 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/NCP 08083 B. pdf

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” • 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;

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 • Another example – Temperature class that has get. Temp. In. Celsius() and get. Temp. In. Fahrenheit() operations – Can store Fahrenheit as an attribute or calculate it 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

Example of multiple interfaces functions as

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

Example of cohesion

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

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