collaboration other classes that work with the class No object is an island

Collaboration other classes that work with the class

This preview shows page 5 - 9 out of 9 pages.

collaboration, other classes that work with the class “No object is an island” Basic Kinds of Responsibilities To know To do To decide OOSD — Is Not Seamless Not every software object is an OOA entity GRASP Patterns GRASP is General Responsibility Assignment Software Patterns Guidelines for how to “jump” the representation gap Detailed Design 8
Image of page 5
Detailed Design Definition [ISO/IEC 24765] 1. the process of refining and expanding the preliminary design of a system or component to the extent that the design is sufficiently complete to be implemented; 2. the result of the process in (1). OO Software Detailed Design — How To Sketch CRC (Class-Responsibility-Collaboration) for each class UML diagram for system objects and their collaboration Determine interfaces (ie operations) of each class Specify contract for each operation Select algorithms and data structures for each class Describe algorithm for each major operation using UML note Detailed Design Quality Concerns Correctness Efficiency = Resource Usage Scaleability Issues Data representations Algorithms Interfaces (API) Data Structures Vector and Array: indexed by scalar type, often fixed length Set: no order, no duplicates List: order, duplicates Bag (or Multiset): no order, duplicates Map: relates “key” and “value” pairs Memory management Fixed size vs dynamic size Packed data representations Initialise expected size Set hash function IO is typically 30% of total computing time Scenario-Driven Review of Designs 9
Image of page 6
Design Cycle Loop: Draft design and describe clearly Review/Assess/Evaluate design — discover issues Resolve design issue = make decision Review Designs by “Executing” Scenarios Provide a Concrete Situation Attribute to Evaluate: Correct Working Design Context: Pick an example system input Context: Pick an example system state Context: Pick an example scenario Hand “Execute” the Designed System “Execute” scenario trace behaviour of the system of the design eg, use sequence diagram for messages to objects and object interface definitions Scenario-Driven Review of Correctness Ideal Review Trace all scenarios on all possible inputs! Practical Review For each scenario, trace one relevant input. Remember — No amount of testing can demonstrate correctness! There are too many combinations of valid input to test for a practical software system. There are simply too many tests to run Review aims to discover issues. Review can use one scenario at a time. Review can never consider all possible scenarios and inputs. Proof must show design works in all possible cases. Proof cannot do this using a small number of scenarios and inputs. Proof must reason about all possible inputs and scenarios. Question… 10
Image of page 7
Design is White-Box of Black-Boxes Your algorithm is written to use data structures as black-boxes: String, Substring, Collection, Integer You assume black-boxes work correctly ... and show your design is correct but you need to be clear on required properties of each black-box which are specified in contract for the interface of the black-box (and clear from the responsibility of the black-box) then design the black-boxes and show they are correct, ie, have the required properties Practical Review Pick relevant system input, state, and scenario relevant to usage of selected resource
Image of page 8
Image of page 9

You've reached the end of your free preview.

Want to read all 9 pages?

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture