reading techniques for oo design inspections ufrj coppe department of computer science experimental...

Reading Techniques for OO Design Inspections

UFRJCOPPE

Department of Computer ScienceExperimental Software Engineering Group

Guilherme H. TravassosForrest Shull Jeff Carver

Victor R. Basili

{travassos, basili, carver}@[email protected]

http://fc-md.umd.edu

Fraunhofer Center - Maryland

UFRJCOPPE


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)

UFRJCOPPE


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

UFRJCOPPE


Reading Techniques

Domain Knowledge

SoftwareArtifacts

Other DomainGeneral

Requirements

ambiguity

extraneousincorrect fact

omission

inconsistency

• “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.

UFRJCOPPE


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.

UFRJCOPPE


Reading Techniques for OO Design

looking for defects:

Type of Defect DescriptionOmission One or more design diagrams that should contain some concept from

the general requirements or from the requirements document do notcontain a representation for that concept.

Incorrect Fact A design diagram contains a misrepresentation of a concept describedin the general requirements or requirements document.

Inconsistency A representation of a concept in one design diagram disagrees with arepresentation of the same concept in either the same or anotherdesign diagram.

Ambiguity A representation of a concept in the design is unclear, and could causea user of the document (developer, low-level designer, etc.) tomisinterpret or misunderstand the meaning of the concept.

ExtraneousInformation

The design includes information that, while perhaps true, does notapply to this domain and should not be included in the design.

Table 1 – Types of software defects, and their specific definitions for OO designs

UFRJCOPPE


Reading Techniques: Horizontal and Vertical

Target Artifacts:

RequirementsDescriptions

Use-CasesRequirementsSpecification

High LevelDesign

ClassDiagrams

ClassDescriptions

State MachineDiagrams

InteractionDiagrams

(Sequence)Vertical readingHorizontalreading

UFRJCOPPE



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

Horizontal Reading Techniques

UFRJCOPPE



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

Vertical Reading Techniques

UFRJCOPPE



Reader 1

Reader 2

Reader 3

looking for consistencyhorizontal reading

looking for consistencyhorizontal reading

looking for traceabilityvertical reading

Meet as a team to discuss a comprehensive defect list.Each reader is an “expert” in a different aspect

Final list of all defects sent to designer for

repairing

The inspection process with OO reading techniques:

UFRJCOPPE


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) …


Messages: Sequence diagram describes communications between objects.

E.g.: parking_spot_request(), next_available()

Customer :Customer

Gas Station Owner :Gas Station Owner

Credit Card System :Credit_Card System

Purchase :Purchase

Customer Bill :Bill

Parking Spot :Parking_Spot

parking_spot_request( account_number)next_available( )

where_to_park( available parking_spot)

lease_parking_spot(parking_spot, payment time, payment type)

authorize_payment(customer, amount, date)

[ Payment type = Credit Card and payment time = now]

new_purchase(customer, parking_spot, date)

add_to_bill(customer, amount, date)

[ payment time = monthly]new_payment_type_request()

[ response time => 30 secs orcredit card not authorized andpayment time = now]

[response time < 30 secs]


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”

Customer :Customer

Gas Station Owner :Gas Station Owner

Credit Card System :Credit_Card System

Purchase :Purchase

Customer Bill :Bill

Parking Spot :Parking_Spot

parking_spot_request( account_number)next_available( )

where_to_park( available parking_spot)

lease_parking_spot(parking_spot, payment time, payment type)


[ Payment type = Credit Card and payment time = now]

new_purchase(customer, parking_spot, date)

add_to_bill(customer, amount, date)

[ payment time = monthly]new_payment_type_request()

[ response time => 30 secs orcredit card not authorized andpayment time = now]


UFRJCOPPE



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.

UFRJCOPPE



Class, state, and sequence diagrams need to carry constraints and conditions along with the class and methods responsible for implementing the functionality.

Credit_Card System

+ authorize_payment(customer, amount, date)()

(from External Systems)

[ response time should be less than 30

secs for all Credit Card Systems ]


Gas Station Owner :

Gas Station Owner

Credit Card System :

Credit Card System

[ Payment type = Credit Card and

payment time = now]


UFRJCOPPE


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

UFRJCOPPE


How we are learning

Feasibilitystudy

Fall/98 Summer/99,Fall/99,Spring/00

Observationalstudies

Case Study in theSoftware Process

Spring/00

Case Study inIndustrial SoftwareProcess

Is the idea sound?

Is the process well-constructed?

Is the process usablein a software process?

Is the processusable in industry?

(Summer/01)

UFRJCOPPE


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

UFRJCOPPE


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

UFRJCOPPE


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.

UFRJCOPPE



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.

UFRJCOPPE



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.

UFRJCOPPE



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.

UFRJCOPPE



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

reading techniques for oo design inspections ufrj coppe department of computer science experimental...

Documents

software reading

design artifacts

software practitioners

lowlevel design

given software artifact

oo designwhy

oo designlooking

verticaltarget artifacts