Med4Object-Oriented Analysis, Design and Programming

Lecture 1aSoftware engineering with components(Based on Stevens and Pooley (2006),

Chapter 1)

David Meredithdave@imi.aau.dk

http://moodle.vrml.aau.dk/course/view.php?id=21

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

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!

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

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

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)

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

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/NCP08083B.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 isbegin 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 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.

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

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

• 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

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

based 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