1 / 56

COSC3311 – Software Design

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.

finnea
Télécharger la présentation

COSC3311 – Software Design

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. COSC3311 – Software Design Quality Software – Design by Contract Object Oriented Software Construction 2014-09-23 6:26 PM0

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

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

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

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

  6. Seamless development Specification Specification TRANSACTION,PLANE,CUSTOMER,… Example classes Object Oriented Software Construction 2014-09-23 6:26 PM5

  7. Seamless development Specification Specification TRANSACTION,PLANE,CUSTOMER,… STATE, USER_COMMAND, … Design Example classes Object Oriented Software Construction 2014-09-23 6:26 PM6

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

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

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

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

  12. Thinking Quality • Information Hiding • Design by Contract • Test Driven Design Object Oriented Software Construction 2014-09-23 6:26 PM11

  13. Information hiding Public part Secret part Object Oriented Software Construction 2014-09-23 6:26 PM12

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

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

  16. Design by Contract • A discipline of • analysis, • design, • Implementation • Use a consistent notation throughout Object Oriented Software Construction 2014-09-23 6:26 PM15

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

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

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

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

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

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

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

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

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

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

  27. DbC: Run-time Monitor { invariant & P } A { Q & invariant } Object Oriented Software Construction 2014-09-23 6:26 PM26

  28. DbC: Run-time Monitor { invariant & P } A { Q & invariant }

  29. DbC: Run-time Monitor { invariant & P } A { Q & invariant }

  30. DbC: Run-time Monitor { invariant & P } A { Q & invariant }

  31. DbC: Run-time Monitor { invariant & P } A { Q & invariant }

  32. DbC: Run-time Monitor { invariant & P } A { Q & invariant }

  33. DbC: Run-time Monitor { invariant & P } A { Q & invariant }

  34. DbC: Run-time Monitor { invariant & P } A { Q & invariant }

  35. DbC: Run-time Monitor - Satisfaction { invariant & P } A { Q & invariant }

  36. DbC: Run-time Monitor: Weakness { invariant & P } A { Q & invariant }

  37. DbC: Run-time Monitor - Weakness { invariant & P } A { Q & invariant }

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

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

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

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

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

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

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

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

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

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

  48. Command/Query separation principle • In assertions, use only side-effect-free functions. Object Oriented Software Construction 2014-09-23 6:26 PM47

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

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

More Related