1 / 34

Med4 Object-Oriented Analysis, Design and Programming

Med4 Object-Oriented Analysis, Design and Programming. David Meredith dave@imi.aau.dk http://moodle.vrml.aau.dk/course/view.php?id=21. Lecture 1a Software engineering with components (Based on Stevens and Pooley (2006), Chapter 1). The aim.

jboatman
Download Presentation

Med4 Object-Oriented Analysis, Design and Programming

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Med4Object-Oriented Analysis, Design and Programming David Meredith dave@imi.aau.dk http://moodle.vrml.aau.dk/course/view.php?id=21 Lecture 1a Software engineering with components (Based on Stevens and Pooley (2006), Chapter 1)

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

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

  4. 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!

  5. 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?

  6. 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)

  7. 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) • …

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

  9. 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!

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

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

  12. 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)

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

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

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

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

  17. 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 is begin Ada.Text_IO.Put_Line("Hello, world!"); end Hello;

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

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

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

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

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

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

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

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

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

  27. Example of multiple interfaces functions as functions as

  28. What are good systems like? • So far: • A good system • has low coupling • consists of encapsulated modules

  29. 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)

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

  31. Example of cohesion

  32. 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)

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

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

More Related