cis224 software projects software engineering and research methods l.
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

  • Uploaded on

CIS224 Software Projects: Software Engineering and Research Methods. David Meredith Lecture 1a Software engineering with components (Based on Stevens and Pooley (2006), Chapter 1). Set books and web page. Set books:

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

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

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

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:
      • 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)
  • 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 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 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 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:
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)
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
  • 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
  • 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 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)
  • A module exhibits high cohesion if it is difficult to decompose into smaller modules
  • Example:
    • COHERENT (COHESIVE) class:
      • All methods use all instance variables
      • 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