Transcript CIS224 Software Projects: Software Engineering and

Lecture 1a
Software engineering with components
(Based on Stevens and Pooley (2006),
Chapter 1)
David Meredith
[email protected]
www.titanmusic.com/teaching/cis224-2007-8.html
CIS224
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 (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 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/cis224-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
• £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
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
See www.titanmusic.com/teaching/cis224-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 £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)
• 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 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 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
• 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
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