Trusted Components. Reuse, Contracts and Patterns. Prof. Dr. Bertrand Meyer Dr. Karine Arnout

Transcription

1 1 Last update: 15 October 2004 Trusted Components Reuse, Contracts and Patterns Prof. Dr. Bertrand Meyer Dr. Karine Arnout

2 2 Lecture 1: Issues of software quality

3 Agenda for today 3 Introduction Some statistics Quality criteria Quality approaches Components

4 Course overview 4 Three visible ideas that can help advance software quality: Components Contracts Patterns Goal of this course: Present each concept Explain how to combine them

5 Textbooks 5 Karine Arnout: From Patterns to Components, Ph.D. thesis, Download it here. Bertrand Meyer: Object-Oriented Software Construction, 2 nd edition, Prentice Hall, Recommended: Erich Gamma, et al. Design Patterns: Elements of Reusable Object-Oriented Software, Addison- Wesley, Richard Mitchell, Jim McKim: Design by Contract, by example, Addison-Wesley, 2001.

6 Grading 6 Exam (2h): 40% 2 February 2005 Project: 60% Deadline: 4 February 2005 Extension of a Pattern Wizard

7 Pattern Wizard 7 Automatically generates code from patterns. To be extended. Generated code

8 Contacts 8 Responsible assistants: Dr. Karine Arnout, Karine.Arnout@inf.ethz.ch, RZ-J4 Till G. Bay, Till.Bay@inf.ethz.ch, RZ-J22 Course web page: Course address: tc@se.inf.ethz.ch (To join Prof. Dr. Bertrand Meyer, Dr. Karine Arnout and Till Bay)

9 Registration 9 Please send an To: tc@se.inf.ethz.ch Subject: TC course participant Content: Your name Preferred address Status Diplom student (semester?), Ph.D. student, other. Taking the course for credit or not Attach a picture (JPEG, GIF, PNG) if you wish

10 Agenda for today 10 Introduction Some statistics Quality criteria Quality approaches Components

11 A sad story 11 Standish Group Research Study CHAOS, 1995 Fully successful (on-time, on-budget, with all features as initially specified) 16% 53% Unsuccessful (late, over-budget, or fewer features than originally specified) 31% Failure (cancelled prior to completion) On average, unsuccessful projects are: Over time: 222% longer than planned Over budget: by 189% over budget Incomplete functionality: 61% of planned features.

12 which is not improving over years 12 NIST report on testing, 2002 Estimated costs resulting from bad-quality software: 22.2 to 59.5 billion dollars! Financial industry: 3.8 billion dollars Auto/aerospace industry: 1.8 billion dollars

13 Not only figures 13 But also money Ariane 5 Year security attacks Buffer overflow and loss of human lives London Ambulance System Therac-25

14 Agenda for today 14 Introduction Some statistics Quality criteria Quality approaches Components

15 What is software quality? 15 Defining the attributes of software quality and determining the metrics to assess the relative value of each attribute are not formalized processes. Not only is there a lack of commonly agreed upon definitions of software quality, different users place different values on each attribute depending on the product s use. NIST report on testing, May 2002.

16 Software quality model, McCall et al Product operation criteria Correctness, reliability, integrity, usability, efficiency Product revision criteria Maintainability, flexibility, testability Product transition criteria Interoperability, reusability, portability

17 Software quality factors, Meyer External factors: perceptible to the users Efficiency, ease-of-use, Internal factors: only perceptible to programmers Modularity, readability Without internal factors, no external ones!

18 Other external factors 18 Reliability: Correctness + Robustness SPECIFICATION Correctness Robustness Correctness: Software performs according to specification, in cases defined by its specification Robustness: Software reacts reasonably to cases not covered by its specification. Other external factors: Integrity, extendibility, portability, reusability

19 Software reusability: A definition 19 Reusability is the ability of software elements to serve for the construction of many different applications. Bertrand Meyer, Object-Oriented Software Construction, 2 nd edition, 1997

20 Agenda for today 20 Introduction Some statistics Quality criteria Quality approaches Components

21 Approaches to software quality 21 A priori Build software right from the start. A posteriori Test, test, and retest.

22 Technical answers 22 Formal specification and verification Fully formal: Z, B,... Partly formal: Design by Contract Programming language support Static typing Garbage collection No goto Information hiding Clear syntax Style standards

23 Managerial answers 23 Capability Maturity Model ISO 9001 Buy from market leaders Get software in source from Code reviews

24 Technical & managerial answer: Components 24 New buzzwords : Reuse Components COTS (Commercial Off-The-Shelf) CBD (Component-Based Development) Different kinds of components: O-O libraries: Eiffel, C#, Java, STL,... Binary components: CORBA, COM, EJB,.NET

25 Agenda for today 25 Introduction Some statistics Quality criteria Quality approaches Components

26 Issues 26 Organizational and managerial issues Not covered in this course Technical issues What form of components? Quality of components

27 What form of component? (1/2) 27 The general pattern for a searching routine: has (t: TABLE; x: ELEMENT): BOOLEAN is -- Does item x appear in table t? local pos: POSITION do from pos := initial_position (t, x) until exhausted (t, pos) or else found (t, x, pos) loop pos := next (t, x, pos) end Result := found (t, x, pos) end

28 What form of components (2/2) 28 Reusability requirements Routine grouping Type variation Implementation variation Other requirements Representation independence Factoring out common behaviors

29 Factoring out common behaviors (1/3) 29 Example: the set of sequential table implementations TABLE has start after found forth SEQUENTIAL_ TABLE TREE_ TABLE HASH_ TABLE ARRAY_ TABLE LINKED_ TABLE FILE_ TABLE

30 Factoring out common behaviors (2/3) 30 before item after 1 back forth count start index

31 Factoring out common behaviors (3/3) 31 A common routine text for has: has (t: SEQUENTIAL_TABLE; x: ELEMENT): BOOLEAN is -- Does x appear in the table? do from start (t) until after (t) or else found (t, x) loop forth (t) end Result := not after (t) end

32 Software component: A definition 32 A software component is a reusable module with the following supplementary properties: It can be used by other modules (its clients ). The supplier of a component does not need to know who its clients are. Clients can use a component on the sole basis of its official information. (This is a broad view of component.)

33 Expected benefits 33 Benefits for the users Timeliness Maintainability Reliability Efficiency Interoperability Other qualities COMMON DESIRABLE Debugging Functionality Envisaged Early releases Benefits for the suppliers Interoperability Investment

34 Major software issues before components 34 Quality Correctness Robustness Extendibility Reusability Ease-of-use Productivity Time to market Number of developers

35 Major software issues after components 35 Quality Correctness Robustness Extendibility Reusability Ease-of-use Productivity Time to market Number of developers

36 Component quality 36 Bad-quality components are a major risk. Deficiencies scale up. The architecture of component-based systems is significantly more demanding than that of traditional monolithic integrated solutions. In the context of component software, full comprehension of established design reuse techniques is most important. Clemens Szyperski, Component Software, 1998

37 Perfectionism 37 Component design should be the Formula-1 racing of software engineering. Bertrand Meyer

38 Software reuse vs. design reuse 38 Reuse of architectural and design experience is probably the single most valuable strategy in the basket of reuse ideas Clemens Szyperski, Component Software, 1998, p 132. Seamless development reconciles design and implementation by covering the whole software lifecycle. From Patterns to Components

39 Complementary material 39 From Patterns to Components: Chapter 2: The benefits of reuse OOSC2: Chapter 3: Modularity Chapter 4: Approaches to reusability

40 40 End of lecture 1