1 / 22

CS3500 Software Engineering

CS3500 Software Engineering. Object-Oriented Analysis & Design (2). Object-oriented view. Traditional view. message. message. withdraw. account_balance. withdraw. deposit. account_ balance. Balance_enquiry. deposit. Balance enquiry. message.

manasa
Download Presentation

CS3500 Software Engineering

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. CS3500 Software Engineering Object-Oriented Analysis & Design (2) Object-oriented view Traditional view message message withdraw account_balance withdraw deposit account_ balance Balance_enquiry deposit Balance enquiry message

  2. CS3500 Software Engineering Object-Oriented Analysis & Design (3) Well-designed units are independent units! Everything in the software that relates to that part of the real world modeled by that object can be found in the object itself! Encapsulation! Information-hiding! Read! Note in the previous diagram how everything (operations & data) to do with account_balance is contained within the object. This is not the case in the classical view and in how an implementation would have been done before OO

  3. CS3500 Software Engineering Object-Oriented Analysis & Design (4) • Object-oriented uses the Unified Modeling Langauage (UML) for • specifying • visualising • constructing, and • documenting • all system components. • This means that the same methodology carries through the SD process from beginning to end. • This is in real contrast to other approaches where the methods/techniques used in analysis & design are very different from those used in documenting code.

  4. CS3500 Software Engineering Object-Oriented Analysis & Design (5) Exploratory Programming (4) UML provides several different kinds of diagrams for defining different things about objects, interaction between objects and processes (methods) which operate on objects. (Class diagrams, use case diagrams, sequence diagrams, collaboration diagrams, statechart diagrams, activity diagrams, component and deployment diagrams). Methods provide “services” on objects. The services (functions) provided by methods is achieved by message-passing between objects.

  5. CS3500 Software Engineering Object-Oriented Analysis & Design (6) Exploratory Programming (4) In summary: The OO approach provides a consistent methodology and set of techniques that serve the developer from project inception through to delivery. OO supports encapsulation and therefore information-hiding. New data types can be defined as extensions of previously defined types rather than having to be defined as totally new ones Post-delivery maintenance is greatly simplified. OO reduces the level of complexity of a product and therefore simplifies both development and maintenance. OO promotes reuse: because objects are independent entities they can be utilised in future products. Read about inheritance

  6. CS3500 Software Engineering Object-Oriented Analysis & Design (7) Exploratory Programming (4) OO compared to Classical? An IBM survey in 1994 of 3 different projects showed that the OO model outperformed the classical approach in every respect. Specifically, there were - major decreases in the number of faults detected, far fewer change requests during both development and maintenance and significant increases in ease of maintenance. A report in 2000 surveyed 150 U.S. software developers to determine attitudes towards OO – 96 who used OO and 54 who still used classical approaches. Both groups felt the OO model was superior.

  7. CS3500 Software Engineering Formal Specification (1) Exploratory Programming (4) Formal methods allow a software engineer to create a specification that is more complete consistent, and unambiguous than that produced by any other means developed to date.

  8. CS3500 Software Engineering Formal Specification (2) Exploratory Programming (4) Set theory and logic notation are used to create a clear statement of facts (requirements). This mathematical specification can then be analysed to prove correctness and consistency. Formal methods reduce specification errors dramatically. Because of this, formal methods are mainly used in safety- critical systems where system failurecanhave a high price (e.g. software embedded in life-support systems, traffic control systems, environmental control software, etc.) System failure unacceptable

  9. CS3500 Software Engineering Formal Specification (3) Exploratory Programming (4) Several techniques are available for formal specification: The Z specification language Vienna definition method (VDM) Finite state machine analysis Petri net analysis

  10. CS3500 Software Engineering Formal Specification (4) Formal specification requires that a process or function is defined (using some mathematical notation) in terms of the state of all data before the function executes, the transforming steps of the function, the state of all data after the function has executed, and any constraints that apply. As such, a formal specification can be proved to be correct while an informal specification can not.

  11. CS3500 Software Engineering Formal Specification (5) Formal specification focuses mainly on function and data. Timing, control and behavioural aspects of a problem (as well as human-machine interfaces) are better specified using graphical techniques. Applying formal specification to a project is time-consuming. Also expensive because required skills are in short supply. Accordingly, use of formal methods still generally restricted to safety-critical systems.

  12. CS3500 Software Engineering Reuse (1) (System construction with re-usable components) Stephen Schach wrote: “If reinventing the wheel were a criminal offence, many software professionals would be languishing in jail.” Facts: There are thousands of different COBOL payroll programs, all doing essentially the same thing. The world needs just one (or a few) payroll program that can run on a variety of hardware and be tailored/configured to match the specific needs of a particular organisation. This re-invention is the main cause of the sheer size of the legacy problem.

  13. CS3500 Software Engineering Reuse (2) Building software by reuse means using components of one product to help in the building of another product with a different functionality. A reusable component need not necessarily be a module or piece of code – it could be a design document, part of a manual, a set of test data, or a time or cost estimate. Developers realise that a piece of a previously developed product can be reused in a new product Utilisation of components constructed specifically for possible future reuse Opportunistic (or accidental) = reuse Systematic (or deliberate) = reuse

  14. CS3500 Software Engineering CS3500 Software Engineering Software Component Library Reuse (2) Reuse (2) B C D N A N E E T T E F G H Software Product 1 K K New 1 P P I J K L I I L L New 2 O P M N Software Product 2 J I S T Q R R New 3 F C E New 1 New 2 New 3 New 4 K New 4

  15. CS3500 Software Engineering Reuse (3) By the 1970’s people began to realise that there was no need to construct new code from scratch each time an input-output routine, or a routine for computing sines and cosines was required. Now, we are familiar with the availability of libraries of routines (methods, functions, etc) which we can use when programming in C++, Java or other languages. Class libraries are available to make life easier for object- oriented programmers. The idea of libraries of subroutines has been extended to large statistical libraries such as SPSS and numerical analysis libraries like NAG. Despite this, there has been a slow take-up of reusability as a mainstream SD strategy among application developers

  16. CS3500 Software Engineering Reuse (4) Points to note: On average, only about 15% of any software product serves a truly original purpose The other 85% of the product could, in theory, be standardised and reused In future products. Some organisations achieve reuse rates approaching 40% Why do so few organisations employ reuse to shorten the development process?

  17. CS3500 Software Engineering Reuse (5) Impediments to Reuse Many software professionals prefer to rewrite a routine from scratch rather than reuse a routine written by someone else(also know as the NIH or not invented here syndrome!) Developers often suspicious that reusing software components might introduce faults into the product Reuse can be expensive - estimates vary from 11% to 480% cost increases to make a component reusable compared to original construction cost of that component Legal issues could arise, e.g. developer uses a component from a product built for client A in a new product for client B … For COTS (commercial off-the-shelf) components source code rarely available so COTS components have limited modifiability.

  18. CS3500 Software Engineering Reuse (6) The Future: The current focus on objects and methods, encapsulation and information-hiding, component-based software systems and the growing availability of well-tested libraries of routines should promote reuse and offers greater promise for time-efficient delivery of fault-free software products than is seen in the other SD models now in use.

  19. CS3500 Software Engineering Software Quality (1) Software quality has to be the focus and the SD model chosen for a project does not, in itself guarantee quality. In 1977, McCall identified 9 criteria which could provide the basis for measuring software quality. (Factors in Software Quality)

  20. CS3500 Software Engineering Software Quality (2) The McCall Quality Factors Correctness – the extent to which software is consistent with its specification and matches the customer’s needs Reliability – the probability of failure-free operation of software in a specified environment for a specified time Maintainability & Flexibility – the effort (work + resources) required to fix errors & make changes in software Testability – the effort (work + resources) required to test software Usability – the effort required to become a competent operator of a software system, (operation & configuration, data input preparation, output checking and interpretation)

  21. CS3500 Software Engineering Software Quality (3) The McCall Quality Factors (cont) Efficiency – the amount of computing resources and code required by a software system to perform its functions in the shortest possible time Reusability – the extent to which components of a software system can be used in other applications Inter-operability– the effort required to couple (link) one piece of a software system to another, or to another separate system Portability – the effort needed to move software and re-install/configure it on a different hardware platform and/or operating system

  22. CS3500 Software Engineering Software Quality (4) McCall Factors & Metrics The McCall factors are not in themselves measurements. It isn’t useful (from a quality viewpoint) to say that a piece of software is “very reliable”, “nice to use”, or “easy to maintain”. These are entirely qualitative (and non-quantitative) subjective statements. The McCall factors are useful because they identify those criteria around which metrics can be built. A “metric” is a measurement (with a mathematical basis) of some particular aspect of software Many different metrics can be developed for each of the McCall factors

More Related