570 likes | 794 Views
COSC3311 – Software Design. Quality Software – Design by Contract. The waterfall model of the lifecycle. FEASIBILITY STUDY. REQUIREMENTS ANALYSIS. SPECIFICATION. GLOBAL DESIGN. DETAILED DESIGN. IMPLEMENTATION. VALIDATION & VERIFICATION. DISTRIBUTION. PROJECT PROGRESS.
E N D
COSC3311 – Software Design Quality Software – Design by Contract Object Oriented Software Construction 2014-09-23 6:26 PM0
The waterfall model of the lifecycle FEASIBILITY STUDY REQUIREMENTS ANALYSIS SPECIFICATION GLOBAL DESIGN DETAILED DESIGN IMPLEMENTATION VALIDATION & VERIFICATION DISTRIBUTION PROJECT PROGRESS Object Oriented Software Construction 2014-09-23 6:26 PM1
The waterfall model of the lifecycle FEASIBILITY STUDY REQUIREMENTS ANALYSIS DESIGN AND IMPLEMENTATION SPECIFICATION GLOBAL DESIGN DETAILED DESIGN IMPLEMENTATION VALIDATION & VERIFICATION DISTRIBUTION PROJECT TIME Object Oriented Software Construction 2014-09-23 6:26 PM2
Problems with the waterfall • Late appearance of actual code. • Lack of support for requirements change — and more generally for extendibility and reusability. • Lack of support for the maintenance activity (70% of software costs?). • Division of labor hampering Total Quality Management. • Impedance mismatches. Object Oriented Software Construction 2014-09-23 6:26 PM3
Impedance mismatches As Management requested it. As the Project Leader defined it. As Systems designed it. As Programming developed it. As Operations installed it. What the user wanted. (Pre-1970 cartoon; origin unknown) Object Oriented Software Construction 2014-09-23 6:26 PM4
Seamless development Specification Specification TRANSACTION,PLANE,CUSTOMER,… Example classes Object Oriented Software Construction 2014-09-23 6:26 PM5
Seamless development Specification Specification TRANSACTION,PLANE,CUSTOMER,… STATE, USER_COMMAND, … Design Example classes Object Oriented Software Construction 2014-09-23 6:26 PM6
Seamless development Specification Specification TRANSACTION,PLANE,CUSTOMER,… STATE, USER, … Design HASH_TABLE, LINKED_LIST… Implementation Example classes Object Oriented Software Construction 2014-09-23 6:26 PM7
Seamless development Specification Specification TRANSACTION,PLANE,CUSTOMER,… STATE, USER, … Design HASH_TABLE, LINKED_LIST… Implementation TEST_DRIVER, … V & V Example classes Object Oriented Software Construction 2014-09-23 6:26 PM8
Seamless development Specification Specification TRANSACTION,PLANE,CUSTOMER,… STATE, USER, … Design HASH_TABLE, LINKED_LIST… Implementation TEST_DRIVER, … V & V Generalization Example classes Object Oriented Software Construction 2014-09-23 6:26 PM9
The goal: Software quality • REUSABILITY • EXTENDIBILITY • RELIABILITY (Correctness + Robustness) • PORTABILITY • EFFICIENCY • INTEGRITY • … • 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. SPECIFICATION Correctness Robustness Object Oriented Software Construction 2014-09-23 6:26 PM10
Thinking Quality • Information Hiding • Design by Contract • Test Driven Design Object Oriented Software Construction 2014-09-23 6:26 PM11
Information hiding Public part Secret part Object Oriented Software Construction 2014-09-23 6:26 PM12
The Information Hiding Principle • The designer of every module must select a subset of the module’s properties (public features) as the official information about the module, to be made available to authors of client modules. • Which properties of a module should be public, and which ones secret? • As a general guideline, the public part should include the specification of the module’s functionality; • anything that relates to the implementation of that functionality should be kept secret Object Oriented Software Construction 2014-09-23 6:26 PM13
Application to information hiding Public features, comments and contracts Secret part: • Choice of representation • Implementation of public features • Private features Object Oriented Software Construction 2014-09-23 6:26 PM14
Design by Contract • A discipline of • analysis, • design, • Implementation • Use a consistent notation throughout Object Oriented Software Construction 2014-09-23 6:26 PM15
A human contract OBLIGATIONS BENEFITS Delivery service (Satisfy precondition:) Bring package before 4 p.m.; pay fee. (From postcondition:) Get package delivered by 10 a.m. next day. Client (Satisfy postcondition:) Deliver package by 10 a.m. next day. (From precondition:) Not required to do anything if package delivered after 4 p.m., or fee not paid. Supplier Object Oriented Software Construction 2014-09-23 6:26 PM16
Properties of contracts • A contract: • Binds two parties (or more): supplier, client. • Is explicit (written). • Specifies mutual obligations and benefits. • Usually maps obligation for one of the parties into benefit for the other, and conversely. • Has no hidden clauses: obligations are those specified. • Often relies, implicitly or explicitly, on general rules applicable to all contracts (laws, regulations, standard practices). Object Oriented Software Construction 2014-09-23 6:26 PM17
Precondition -- i.e. specified only. -- not implemented. Postcondition Class invariant Contracts for analysis deferred classPLANE inherit AIRCRAFT feature start_take_off-- Initiate take-off procedures. requirecontrols.passed assigned_runway.clear deferredensureassigned_runway.owner =Current moving end start_landing, increase_altitude, decrease_altitude, moving, altitude, speed, time_since_take_off ... [Other features] ... invariant (time_since_take_off <= 20) implies(assigned_runway.owner = Current) moving = (speed > 10) end Object Oriented Software Construction 2014-09-23 6:26 PM18
Contracts for analysis (cont’d) OBLIGATIONS BENEFITS start_take_off (Satisfy precondition) Make sure that the controls are passed and the assigned runway is clear . (From postcondition) Becomes the owner of the runway and plane is moving. Client (Satisfy postcondition) Assign the runway to the plane and make it start moving. (From precondition) Don’t have to deal with the issues e.g. controls are failing or runway is not clear. Supplier Object Oriented Software Construction 2014-09-23 6:26 PM19
A contract Example (from EiffelBase) extend (new: G; key: H) -- Assuming there is no item of key key, -- insert new with key; set inserted. require key_not_present: nothas (key) ensure insertion_done: item (key) = new key_present: has (key) inserted: inserted one_more: count = oldcount + 1 Object Oriented Software Construction 2014-09-23 6:26 PM20
The class invariant • Consistency constraint applicable to all instances of a class. • Must be satisfied: • After creation. • After execution of any feature by any client.(Qualified calls only: a.f (...)) Object Oriented Software Construction 2014-09-23 6:26 PM21
Invariants and business rules • Invariants are absolute consistency conditions. • They can serve to represent business rules if knowledge is to be built into the software. • Form 1 invariant not_under_minimum: balance >=Minimum_balance • Form 2 invariant not_under_minimum_if_normal:normal_stateimplies (balance >= Minimum_balance) Object Oriented Software Construction 2014-09-23 6:26 PM22
Correctness in software Basic notation: (P, Q: assertions, i.e. properties of the state of the computation. A: instructions). {P} A {Q} • “Hoare triple” • What this means (total correctness): • Any execution of A started in a state satisfying P will terminate in a state satisfying Q. Object Oriented Software Construction 2014-09-23 6:26 PM23
Concept of State • Each state is a combination of run-time instance values for all the class attributes • Expressed as a tuple of size corresponding to the number of class attributes • a, b: BOOLEAN • <T, T>, <F, T>, <T, F>, <F, F> Object Oriented Software Construction 2014-09-23 6:26 PM24
createa.make (…) S1 a.f (…) S2 a.g (…) S3 a.f (…) S4 The correctness of a class • For every creation procedure cp: {precp} docp {postcp and INV} • For every exported routine r: {INV and prer} dor {postr and INV} • The worst possible erroneous run-time situation in object-oriented software development: • Producing an object that does not satisfy the invariant of its own class. Object Oriented Software Construction 2014-09-23 6:26 PM25
DbC: Run-time Monitor { invariant & P } A { Q & invariant } Object Oriented Software Construction 2014-09-23 6:26 PM26
DbC: Run-time Monitor { invariant & P } A { Q & invariant }
DbC: Run-time Monitor { invariant & P } A { Q & invariant }
DbC: Run-time Monitor { invariant & P } A { Q & invariant }
DbC: Run-time Monitor { invariant & P } A { Q & invariant }
DbC: Run-time Monitor { invariant & P } A { Q & invariant }
DbC: Run-time Monitor { invariant & P } A { Q & invariant }
DbC: Run-time Monitor { invariant & P } A { Q & invariant }
DbC: Run-time Monitor - Satisfaction { invariant & P } A { Q & invariant }
DbC: Run-time Monitor: Weakness { invariant & P } A { Q & invariant }
DbC: Run-time Monitor - Weakness { invariant & P } A { Q & invariant }
Hoare triples: a simple example {n > 5}n := n + 9 {n > 13} • Most interesting properties: • Strongest postcondition (from given precondition). • Weakest precondition (from given postcondition). • “P is stronger than or equal to Q” means: P implies Q • An assertion A is stronger than B if A specifies a property more precisely than B, e.g., “party_start_time = 10pm” is stronger than “party_start_time = evening” • QUIZ: What is the strongest possible assertion? The weakest? Object Oriented Software Construction 2014-09-23 6:26 PM37
Weak and Strong Assertions • Suppose we want to describe (specify) this set of integers: • { 2 4 8 16 32 ... } • An assertion can be used to describe integers in a set • 1 – a set of all integers{ i: INTEGER • i } • 2 – a set of even integers{ i: INTEGER • even (i) } • 3 – a set of powers of two{ i: INTEGER • 2 ** i } • 4 – set of powers of two with positive exponent{ i: INTEGER | i > 0 • 2 ** i } Weaker Stronger Object Oriented Software Construction 2014-09-23 6:26 PM38
Weak and Strong Assertions – 2 • The stronger the assertion the closer the description comes to specifying the actual set • In general • Weak assertions describe bigger sets than strong assertions • In programming • The weaker the assertion the more cases that must be handledFor precondition – more input statesFor postcondition – more output states Object Oriented Software Construction 2014-09-23 6:26 PM39
Software correctness • Consider {P} A {Q} • Take this as a job ad in the classifieds. • Should a lazy employment candidate hope for a weak or strong P?What about Q? • Two special offers: • 1. {False}A{...} • 2. {...}A{True} Object Oriented Software Construction 2014-09-23 6:26 PM40
A contract violation is not a special case • For special cases (e.g. “if the sum is negative, report an error...”) use standard control structures (e.g. if ... then ... else...). • A run-time assertion violation is something else: the manifestation of A DEFECT (“BUG”) Object Oriented Software Construction 2014-09-23 6:26 PM41
Contracts and quality assurance • Precondition violation: Bug in the client. • Postcondition violation: Bug in the supplier. • Invariant violation: Bug in the supplier. {P} A {Q} Object Oriented Software Construction 2014-09-23 6:26 PM42
So, is DbC like “assert” in Java 1.4? • Design by Contract goes further: • “Assert” does not provide a contract. • Clients cannot see asserts as part of the interface. • Asserts do not have associated semantic specifications. • Not explicit whether an assert represents a precondition, post-conditions or invariant. • Asserts do not support inheritance. • Asserts do not yield automatic documentation. Object Oriented Software Construction 2014-09-23 6:26 PM43
Some benefits: technical • Development process becomes more focused. Writing to spec. • Sound basis for writing reusable software. • Exception handling guided by precise definition of “normal” and “abnormal” cases. • Interface documentation always up-to-date, can be trusted. • Documentation generated automatically. • Faults occur close to their cause. Found faster and more easily. • Guide for black-box test case generation. Object Oriented Software Construction 2014-09-23 6:26 PM44
Export rule for preconditions • In • some_property must be exported (at least) to A, B and C! • No such requirement for postconditions and invariants. feature{A, B, C} r (…) require some_property Object Oriented Software Construction 2014-09-23 6:26 PM45
The contract language • Language of boolean expressions (plus old): • No quantifiers, or, but we can use agents instead. • Function calls permitted (e.g. in a STACK class): put (x: G) -- Push x on top of stack. require notis_full do … ensure notis_empty end remove (x: G) -- Pop top of stack. require notis_empty do … ensure notis_full end Object Oriented Software Construction 2014-09-23 6:26 PM46
Command/Query separation principle • In assertions, use only side-effect-free functions. Object Oriented Software Construction 2014-09-23 6:26 PM47
Precondition design • The client must guarantee the precondition before the call. • This does not necessarily mean testing for the precondition. • Scheme 1 (testing): if notmy_stack.is_fullthen my_stack.put (some_element) end • Scheme 2 (guaranteeing without testing): my_stack.remove ... my_stack.put (some_element) Object Oriented Software Construction 2014-09-23 6:26 PM48
Not defensive programming • For every consistency condition that is required to perform a certain operation: • Assign responsibility for the condition to one of the contract’s two parties (supplier, client). • Stick to this decision: do not duplicate responsibility. • Simplifies software and improves global reliability. Object Oriented Software Construction 2014-09-23 6:26 PM49