CIS224 Software Projects: Software Engineering and Research Methods

1
CIS224Software Projects Software Engineering
and Research Methods

• Lecture 1a
• Software engineering with components
• (Based on Stevens and Pooley (2006), Chapter 1)

David Meredith d.meredith_at_gold.ac.uk www.titanmus
ic.com/teaching/cis224-2007-8.html
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 dont 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 disastersDenver 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 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.

16
Attempted solutions tosoftware 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,T) and cartesian co-ordinates (x,y)
• Define two public operations
• printPolarCoords()
• printCartCoords()
• Define two private attributes
• x
• y
• printPolarCoords() actually computes r and T on
  the fly, but the user and any client module
  doesnt 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 dont
  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