Reading Techniques for OO Design Inspections

1. Reading Techniques for OO Design Inspections Guilherme H. Travassos Forrest Shull Jeff Carver Victor R. Basili {travassos, basili, carver}@cs.umd.edu fshull@fc-md.umd.edu http://fc-md.umd.edu UFRJ COPPE Department of Computer Science Experimental Software Engineering Group Fraunhofer Center - Maryland

2. Outline • Introduction • Reading techniques for OO design inspections • “Horizontal” and “vertical” reading • Semantic checking • Ongoing research: • How we are learning • What we know • What we don’t • (An Example)

3. Reading Techniques • Why read? • Software practitioners are taught how to write, but typically not how to read, software documents • Many software processes assume that practitioners know how to effectively find the information they need (i.e. how to read) such documents • e.g. inspection process: read a document to find defects

4. Domain Knowledge Other Domain General Requirements incorrect fact extraneous Software Artifacts omission inconsistency ambiguity Reading Techniques • “Software reading techniques” attempt to increase the effectiveness of inspections by providing procedural guidelines that can be used by individual reviewers to examine (or “read”) a given software artifact and identify defects • There is empirical evidence that software reading is a promising technique for increasing the effectiveness of inspections on different types of software artifacts, not just limited to source code.

5. Reading Techniques for OO Design • Why read high-level designs (HLD)? • To ensure that developers understand the problem fully before trying to define the solution, which will appear in the low-level design. • To locate and remove as many defects as possible at the higher level, before they become more difficult and more expensive to fix in low-level design or code.

6. Reading Techniques for OO Design looking for defects:

7. Reading Techniques: Horizontal and Vertical • Target Artifacts: Requirements Requirements Use-Cases Specification Descriptions Class Class State Machine Interaction High Level Diagrams Descriptions Diagrams Diagrams Design (Sequence) Vertical reading Horizontal reading

8. Reading Techniques: Horizontal and Vertical Horizontal Reading Techniques • Ensure all design artifacts represent the same system • Design contain complementary views of the information • Static (class diagrams) • Dynamic (interaction diagrams) • Not obvious how to compare these different perspectives

9. Reading Techniques: Horizontal and Vertical Vertical Reading Techniques • Ensure that the design artifacts represent the same system described by the requirements and use-cases • Comparing documents from different lifecycle phases • Level of abstraction and detail are different

10. Reading Techniques: Horizontal and Vertical The inspection process with OO reading techniques: looking for consistency horizontal reading Reader 1 Meet as a team to discuss a comprehensive defect list. Each reader is an “expert” in a different aspect looking for consistency horizontal reading Reader 2 looking for traceability vertical reading Final list of all defects sent to designer for repairing Reader 3

11. Reading Techniques: Semantic Checking • Reading Technique for Class diagrams x Class descriptions • … • 2)Read the class descriptions • … Look at all the attributes that are described, along with their basic types. • Can this class meaningfully encapsulate all these attributes? • Are the attributes associated with feasible/possible basic types? • Is some attribute missing from one of the documents, or is an extraneous attribute included on one of the documents? • … • 3) …

12. Reading Techniques: Semantic Checking • Messages: Sequence diagram describes communications between objects. • E.g.: parking_spot_request(), next_available()

13. Reading Techniques: Semantic Checking • Services: Requirements, class methods, state diagrams usually refer to services provided by the system • E.g.: “get an available parking spot”, “pay by credit card”

14. Reading Techniques: Semantic Checking • Requirements often describe conditions and constraints on functionality. • If the time of payment is the same as the purchase time and Customer decides to pay by Credit Card then Credit Card system should be used. The Customer can only wait for 30 seconds for the authorization process otherwise this payment should be made by cash or personal check to avoid other Customers waiting on the lane. The Gas Station Owner should ask the Customer for a new payment type.

15. Gas Station Owner : Credit Card System : Gas Station Owner Credit Card System Credit_Card System (from External Systems) + authorize_payment(customer, amount, date)() [ response time should be less than 30 [ Payment type = Credit Card and secs for all Credit Card Systems ] payment time = now] [response time < 30 secs] Reading Techniques: Semantic Checking • Class, state, and sequence diagrams need to carry constraints and conditions along with the class and methods responsible for implementing the functionality. authorize_payment (customer, amount, date)

16. How we are learning • Empirical Evaluations • Receiving feedback from users of the techniques • Controlled Experiments • Observational Studies • Modifying the techniques based on feedback • Qualitative • Quantitative • Continually evaluating the techniques to ensure they remain feasible and useful

17. How we are learning

18. What we know so far • Techniques are feasible • Techniques help find defects • Vertical reading finds more defects of omission and incorrect fact • Horizontal reading finds more defects of inconsistency and ambiguity • For more details: • http://fc-md.umd.edu/reading.html

19. What we don’t know • What influence does domain knowledge have on the reading process? • Horizontal X Vertical • Can we automate a portion of the techniques? • Some steps are repetitive and mechanical • Need to identify clerical activities

20. Reading Techniques Example: Sequence Diagram x Use Cases • The components: • A use case that describes important concepts of the system and the services it provides. • One or more sequence diagrams that describe the objects of a system and the services it provides. • The class descriptions of all classes in the sequence diagram. • The goal: • To verify that sequence diagrams describe an appropriate combination of objects and messages that work to capture the functionality described by the use case.

21. Reading Techniques Example: Sequence Diagram x Use Cases • Step 1 • Inputs: Use case. • Outputs: System concepts; Services provided by system;Data necessary for achieving services. • General instructions: Identify the functionality described by a use case, and important concepts of the system that are necessary to achieve that functionality. • Specific instructions: • Find system concepts in the use case. • For each concept, identify the services in which it is involved. Look for associated constraints and conditions. • Also identify any information or data that is required to be sent or received in order to achieve the services.

22. Reading Techniques Example: Sequence Diagram x Use Cases • Step 2 • Inputs: Use case, sequence diagram. • Outputs: System concepts; Services provided by system;Data exchanged between objects. • General instructions: Identify and inspect the related sequence diagrams, to identify if the corresponding functionality is described accurately and whether behaviors and data are represented in the right order. • Specific instructions: • For each sequence diagram, identify the system objects. • Identify the services described by the sequence diagrams. • Identify the information (or data) that is exchanged between system classes.

23. Reading Techniques Example: Sequence Diagram x Use Cases • Step 3 • Inputs: Use case, sequence diagram. • Outputs: Discrepancy reports. • General instructions: Compare the marked-up diagrams to determine whether they represent the same domain concepts. • Specific instructions: • For each of identified concepts on the use case, search the sequence diagram to see if it is represented. If not => omission.For each object on the sequence diagram search the use cases to see if it is represented.If not => extraneous info.

24. Reading Techniques Example: Sequence Diagram x Use Cases • Step 3 (cont.) • Identify the services described by the sequence diagram, and compare them with the description used on the use case. Do the classes exchange messages in the same specified order? Are all transported data in the right message? Is data being sent between the right two classes? => incorrect fact • Are all the constraints and conditions from the use case being observed in this sequence diagram? Were the constraints observed? Was all of the behavior and data on the sequence diagram directly concerned with the use-case? => incorrect fact