cis224 software projects software engineering and research methods l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
CIS224 Software Projects: Software Engineering and Research Methods PowerPoint Presentation
Download Presentation
CIS224 Software Projects: Software Engineering and Research Methods

Loading in 2 Seconds...

play fullscreen
1 / 31

CIS224 Software Projects: Software Engineering and Research Methods - PowerPoint PPT Presentation


  • 280 Views
  • Uploaded on

CIS224 Software Projects: Software Engineering and Research Methods. David Meredith d.meredith@gold.ac.uk www.titanmusic.com/teaching/cis224-2007-8.html. Lecture 1a Software engineering with components (Based on Stevens and Pooley (2006), Chapter 1). Set books and web page. Set books:

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'CIS224 Software Projects: Software Engineering and Research Methods' - JasminFlorian


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
cis224 software projects software engineering and research methods

CIS224Software Projects: Software Engineering and Research Methods

David Meredith

d.meredith@gold.ac.uk

www.titanmusic.com/teaching/cis224-2007-8.html

Lecture 1a

Software engineering with components

(Based on Stevens and Pooley (2006), Chapter 1)

set books and web page
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
Overview of this lecture
  • Software engineering with components
      • Stevens & Pooley (2006), Chapter 1
  • Object concepts
      • Stevens and Pooley (2006), Chapter 2
basic questions
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
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
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
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
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
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
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
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
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
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
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
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 plustime 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
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
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
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
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
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
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
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
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
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
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 like26
What are good systems like?
  • So far:
    • A good system
      • has low coupling
      • consists of encapsulated modules
abstraction
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
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
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
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
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