
1 Software engineering 4 Last update: 30 March 2005 The collection of processes, methods, techniques, Software Architecture tools and languages for developing quality operational software. Bertrand Meyer ETH Zurich, 30 March – 29 June 2005 Lecture 2: Software quality; principles and criteria of modularity Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture Agenda for today 2 By the way… 5 Software quality “Software” is not just programs. It includes Modularity processes for producing and operating the Reusability programs, as well as all related documentation, Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture Reading assignment for next week 3 Software engineering 6 OOSC, chapters The collection of processes, methods, techniques, 3: Modularity tools and languages for developing quality 6: Abstract data types operational software. Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture 1 Software quality: external vs internal 7 Reliability 10 External factors: visible to customers Correctness: (not just end users but e.g. purchasers) The systems’ ability to perform according to specification, in cases covered by the specification Examples: ease of use, extendibility, timeliness Robustness: The systems’ ability to perform reasonably in Internal factors: perceptible only to developers cases not covered by the specification Examples: good programming style, Security (integrity): information hiding The systems’ ability to protect itself against hostile use Only external factors count in the end, but the internal factors make it possible to obtain them. Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture Software quality: product vs process 8 Security 11 Product: properties of the resulting software For example: correctness, efficiency Process: properties of the procedures used to produce and “maintain” the software Carcassonne, 13th century Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture External quality factors 9 Security 12 Product quality (immediate): Correctness Robustness Security Ease of use Ease of learning Efficiency Product quality (long-term): Specification Errors Hostility Extendibility Reusability Portability Process quality: Timeliness Cost-effectiveness Correctness Correctness Security Chambord, 16th century Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture 2 Security 13 Reliability 16 Correctness + Robustness + Security Techniques will be studied in detail: typing, Design by Contract, … Versailles, 17-18th century Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture Security 14 Modularity 17 “I think that it’s extraordinarily important that we in computer Reusability + Extendibility science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their Favored by architectural techniques tending to complaints seriously. We began to feel as if we really were ensure decentralization of modules responsible for the successful, error-free perfect use of these machines. I don’t think we are. I think we’re responsible for stretching them, setting them off in new directions, and keeping fun in the house.” Alan Perlis, Preface to The Structure and Interpretation of Computer programs by Abelson and Sussman Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture External quality factors 15 Modularity 18 CORRECTNESS Some principles of modularity: ROBUSTNESS INTEGRITY Decomposability Composability EASE OF USE REUSABILITY Continuity EXTENDIBILITY Information hiding PORTABILITY The open-closed principle EFFICIENCY … The single choice principle Correctness: The ability of a software system to perform according to specification, in cases defined by the specification. Robustness: The ability of a software system to react in a reasonable manner to cases not covered by the specification. Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture 3 Decomposability 19 Composability 22 Method helps decompose complex problems into Method favors production of software elements that may be subproblems. freely combined with each other to produce new software. COROLLARY: Division of labor. Example: Top-down design method (see next). Counter-example: General initialization module. Example: Unix shell conventions Program1 | Program2 | Program3 Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture Top-down functional design 20 Direct mapping 23 Method yields software systems whose modular Topmost functional abstraction structure remains compatible with any modular A structure devised in the process of modeling the problem domain. Sequence BD C Loop Conditional C1I I1 C2 I2 Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture Top-down design 21 Few interfaces principle 24 See Niklaus Wirth, “Program Construction by Every module communicates with as few others as Stepwise Refinement”, Communications of the possible. ACM, 14, 4, (April 1971), p 221-227. http://www.acm.org/classics/dec95/ (A) (B) (C) Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture 4 Small interfaces principle 25 Uniform Access Principle 28 If two modules communicate, they exchange as Facilities managed by a module are accessible to little information as possible. its clients in the same way whether implemented by computation or by storage. Definition: A client of a module is any module that x, y uses its facilities. z Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture Explicit interfaces principle 26 Uniform Access: An example 29 Whenever two modules A and B communicate, this balance = list_of_deposits.total – list_of_withdrawals.total is obvious from the text of A or B or both. list_of_deposits (A1) list_of_withdrawals Module A Module B balance Modifies Accesses list_of_deposits Data item (A2) list_of_withdrawals x Ada, Pascal, C/C++, Java, C#: Simula, Eiffel: a.balance a.balance balance (a) a.balance() Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture Continuity 27 Information hiding 30 Method ensures that small changes in Underlying question: how does one “advertise” the specifications yield small changes in architecture. capabilities of a module? Design method: Specification → Architecture Every module should be known to the outside world through an official, “public” interface. The rest of the module’s properties comprises its “secrets”. It should be impossible to access the secrets from the outside. Example: Principle of Uniform Access (see next) Counter-example: Programs with patterns after the physical implementation of data structures. Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture 5 Information Hiding Principle 31 The Open-Closed Principle 34 The designer of every module must select a subset Modules should be open and closed. of the module’s properties as the official information about the module, to be made Definitions: available to authors of client modules. Open module: May be extended. Closed module: Usable by clients. May be approved, baselined and (if program unit) compiled. The rationales are complementary: For closing a module (manager’s perspective): Clients need it now. For keeping modules open (developer’s perspective): One frequently overlooks aspects of the problem. Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture Information hiding 32 An object has an interface 35 Public part Secret part start item index forth put_right before after Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture Information hiding 33 An object has an implementation 36 Justifications: Continuity Decomposability start item index forth put_right before after Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture 6 Information hiding 37 The Single Choice principle 40 Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. Editor: set of commands (insert, delete etc.) Graphics system: set of figure types (rectangle, circle etc.) start item index Compiler: set of language constructs (instruction, forth loop, expression etc.) put_right before after Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture The Open-Closed principle 38 Reusability issues 41 Organizational and managerial issues: B A CE (Not covered here.) D Technical issues: what form of components? Routine libraries Packages (Ada) Class libraries FA’HI What form of classes? G Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture Closing modules prematurely 39 Reusability: Technical issues 42 type PUBLICATION = The general pattern for
Details
-
File Typepdf
-
Upload Time-
-
Content LanguagesEnglish
-
Upload UserAnonymous/Not logged-in
-
File Pages9 Page
-
File Size-