fc-md slide 1 oo reading techniques for design inspections ufrj coppe department of computer science...

FC-MD

OO Reading Techniques for Design Inspections

UFRJ

COPPE

Department of Computer ScienceExperimental Software Engineering Group

Fraunhofer Center - Maryland

Fag 45038 Programvarekvalitet og prosessforbedring, IDI, NTNU, Trondheim, våren 2000, 21. feb. 2000

Object-Oriented Reading Techniques (OORTs) for Design Documents: general and technical aspects

v1.4

Guilherme H. Travassos, Forrest Shull, Jeff Carver, Victor R. Basili, Univ. Maryland

Revised by: Reidar Conradi, NTNU, p.t. Univ. Maryland

{travassos, basili, carver}@cs.umd.edu; [email protected] http://www.cs.umd.edu/projects/SoftEng/ESEG/

[email protected], http://www.idi.ntnu.no/grupper/SU-grp

-

FC-MD

Table of contents

• Reading and Inspections p. 3

• OO Reading and UML Documents p. 6

• OO Reading and Defect Types p. 10

• Requirements for a Gas Station Control System p. 15

• OO Reading-Related Concepts p. 19

• What are We Learning? p. 24

• Experimental Set-up for OO Reading p. 27

• OORT-1: Sequence Diagram x Class Diagram p. 29

• OORT-2: State Diagram x Class Description p. 33

• OORT-3: State Diagram x Sequence Diagram p. 38

• OORT-4: Class Diagram x Class Description p. 43

• OORT-5: Class Descr. x Requirement Description p. 48

• OORT-6: Sequence Diagram x Use Case Diagram p. 53

• OORT-7: State Diagram x Reqmt.Descr./Use Case p. 59-64

FC-MD Reading and Inspections

• Reading (reviewing): Systematic reading of most software documents / artifacts (requirements, design, code, test data etc.) can increase:

– Reliability: since other persons are much better in finding defects (“errors”) created by you. You often have a psychological block on this.

– Productivity: since defect fixing is much cheaper in earlier life-cycle phases, e.g. 30$ to correct a line in rqmts, $4000 to fix a code line. And 2/3 of all defects can be found before testing, at 1/3 of the price.

– Understanding: e.g. for maintenance or error fixing.

– Knowledge transfer: novices should read the code of experts, and inversely.

– Maintainability: by suggesting a “better” solution/architecture, e.g. to increase reuse.

• We should not only write software (write-once & never-read?), but also read it (own and other’s). But need guidelines (e.g. OORTs) to learn to read efficiently, not ad-hoc.

Why read software?

FC-MD Reading and Inspections (2)

• “Fagan” inspections for defect discovery of any software artifact:

– I1. Preparation: what is to be done, plan the work etc.

– I2. Individual reading: w/ complementary perspectives to maximize effect.

– I3. Common inspection meeting: assessing the reported defects.

– I4. Follow-up: correct and re-check quality, revise guidelines?

• Will look at steps I1-I2 here, with OORT1-7 guidelines for perspectives.

• In industry: typically 10% of effort on inspections, with net saving of 10-25%. So quality is “free”!

• Recently: much emphasis on OO software development, e.g. using Rational Rose tool to create UML design diagrams. But few, tailored reading techniques for such documents. Over 150,000 UML licenses, so big potential.

• Example: Ericsson in Norway: previously using SDL, now UML and Java. Had an old inspection process, but need new reading techniques.

Classic inspections

FC-MD

Reading and Inspections (3)

Reading

Analysis

DefectDetection

Usability

Design Requirements Code UserInterface

SCR English Screen Shot

Defect-based Perspective-based Usability-based

Inconsistent

IncorrectOmission

AmbiguityTester UserDeveloper

Novice ErrorExpert

TechnologyTechnology

FamilyFamily

General GoalGeneral Goal

Specific GoalSpecific Goal

DocumentDocument(artifact)(artifact)

NotationNotationFormForm

TechniqueTechnique

PROBLEM SPACE (needs)

SOLUTION SPACE (techniques, perspectives)

UML Diagrams

Traceability

Horizontal Vertical

Different needs and techniques of reading:

Construction

FC-MD OO Reading and UML Documents

• Dynamic ViewDynamic View

– Use cases (analysis) *

– Activities

– Interaction sequences * collaborations

– State machines *

• Static ViewStatic View

– Classes * Relationships

Generalization - IsA Composition - PartsOf Association - HasA Dependency - DependsOn Realization

Extensibility Constraints Stereotypes

– Descriptions (generated from UML) *

– Packages

– Deployment

UML Artifacts/Diagrams, five used later (*):UML Artifacts/Diagrams, five used later (*):

• Unified Modeling Language, UML: just a notational approach, does not propose/define how to organize the design tasks (process).

• Can be tailored to fit different development situations and software life-cycles (processes)

FC-MD OO Reading and UML Documents (2)

• Requirements descriptions: here structured text with numbered items, e.g. for a Gas Station. In other contexts: possibly with extra ER- and flow-diagrams.

• (Requirement) Analysis documents: here use case diagrams in UML, with associated pseudo-code or comments. A use case describes important concepts of the system and the functionalities it provides.

• Design documents, also in UML:

– Class diagrams: describe the classes and their attributes, behaviors (functions = message definitions) and relationships.

– State diagrams: describe the states of the main system objects, and how state transitions can take place.

– Sequence diagrams (special interaction diagrams): describe how the system objects are exchanging messages.

• Class descriptions: separate textual documentation of the classes, partly as UML-generated interfaces in some programming language.

Our six relevant software artifacts:

FC-MD

OO Reading and UML Documents (3)

Fixed_Rate Loan

risk()principal_remaining()

Variable_Rate Loanprincipal_remaining : number

risk()principal_remaing()

Lendername : textid : textcontact : textphone_number : number

Borrowername : textid : numberrisk : numberstatus : text

risk()set_status_good()set_status_late()set_status_default()borrower_status()set_status()

Bundleactive time period : dateprofit : numberestimated risk : numbertotal : numberloan analyst : id_numberdiscount_rate : numberinvestor_name : textdate_sold : date

risk()calculate_profit()cost()

Loan Arranger

rec_monthly_report()inv_request()generate reports()identify_report_format()verify_report()look_for_a_lender()look_for_a_loan()identify_loan_by_criteria()manually_select_loans()optimize_bundle()calculate_new_bundle()identify_asked_report()aggregate_bundles()aggregate_loans()aggregate_borrowers()aggregate_lenders()format_report()show_report()

Loan

amount : numberinterest rate : numbersettlement data : dateterm : datestatus : textoriginal_value : numberprincipal_original : number

risk()set_status_default()set_status_late()set_status_good()discount_rate()borrowers()principal_remaining()

1

1..*

1

1..*

1..*1..*

1..*1..*

1..*

0..1

1..*

0..1

Good

Late

monthly report informing payment on time[ payment time <= due time ]

receive a monthly report

Default

monthly report informing late payment[ payment time > due time + 10 ]

monthly report informing late payment[ due time < payment time < due time + 10 ]

monthly report informing late payment[ payment time > due time + 10 ]

monthly report informing payment on time[ payment time <= due time ]

Loan State Diagram

Fanny May : Loan Arranger

Borrower : Borrower

A Lender : Specified Lender

Loan : Loan

verify_report()

new_loan(lender, borrowers)

new_

look_for_a_lender(lender)

look_for_a_loan(loan)

look_for_a_

update_loan(lender, borrower)

update_

lender :

new_lender(name,contact, phone_number)

update(lender)

monthly_report(lender, loans, borrowers)

identify_report_format()

Receive Monthly Report

Specified Lender

Investor

Fanny May

Receive Reports

Monthly Report

Investment Request

Request

Generate Reports

Loan Analyst

Loan Arranger Classes Description

Class name: Fixed_Rate Loan Category: Logical View Documentation: A fixed rate loan has the same interest rate over the entire term of the mortgage

External Documents: Export Control: Public Cardinality: n Hierarchy: Superclasses: Loan Public Interface: Operations: risk principal_remaining

State machine: No Concurrency: Sequential Persistence: Persistent

Operation name: risk Public member of: Fixed_Rate Loan Return Class: float Documentation: take the average of the risks' sum of all borrowers related to this loan if the average risk is less than 1 round up to 1 else if the average risk is less than 100 round up to the nearest integer otherwise round down to 100 Concurrency: Sequential

Loan-Arranger Requirements Specification – Jan. 8, 1999

Background

Banks generate income in many ways, often by borrowing money from their depositorsat a low interest rate, and then lending that same money at a higher interest rate in theform of bank loans. However, property loans, such as mortgages, typically have terms of15, 25 or even 30 years. For example, suppose that you purchase a $150,000 house witha $50,000 down payment and borrow a $100,000 mortgage from National Bank forthirty years at 5% interest. That means that National Bank gives you $100,000 to pay thebalance on your house, and you pay National Bank back at a rate of 5% per year over aperiod of thirty years. You must pay back both principal and interest. That is, the initialprincipal, $100,000, is paid back in 360 installments (once a month for 30 years), withinterest on the unpaid balance. In this case the monthly payment is $536.82. Althoughthe income from interest on these loans is lucrative, the loans tie up money for a longtime, preventing the banks from using their money for other transactions. Consequently,the banks often sell their loans to consolidating organizations such as Fannie Mae andFreddie Mac, taking less long-term profit in exchange for freeing the capital for use inother ways.

The six software artifacts: requirement description, use cases and four design documents in UML:

FC-MD OO Reading and UML Documents (4)

Software Artifacts, with OO Reading Techniques (OORTs) indicated:

RequirementsDescriptions

Use-CasesRequirementsSpecification/Analysis

High LevelDesign

ClassDiagrams

ClassDescriptions

State Diagrams

SequenceDiagrams

OORT-1Vertical reading

Horizontal reading

OORT-6OORT-7

OORT-5

OORT-3OORT-2OORT-4

FC-MD

Reading Techniques and defect types:

Domain Knowledge

Software (Design) Artifacts

Other Domain

General Requirements

ambiguity

extraneousincorrect fact

omission

inconsistency

• Software reading techniques try 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 (design doc.) and identify defects.

• As mentioned, empirical evidence that tailored software reading increases the effectiveness of inspections for many software artifacts, not just source code.

OO Reading and Defect Types

FC-MDOO Reading and Defect Types (2)

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

FC-MD OO Reading and Defect Types (3)

• Omission (conceptually using vertical information) – “too little”: Ex. Forgot to consider no-coverage on credit cards, forgot a state transition.

• Incorrect Fact (most often vertical) – “wrong”: Ex. The maximum purchase limit is $1000, not $100.

• Inconsistency (most often horizontal) – “wrong”: Ex. Class name spelled differently in two diagrams, forgot to declare a class function/attribute etc.

• Ambiguity (most often horizontal) – “unclear”: Ex. Unclear state transition, e.g. how a gas pump returns to “vacant”.

• Extraneous or irrelevant information (most often vertical) – “too much”: Ex. Has included both gasoline and diesel sales.

• Miscellaneous: other kind of defects or comments.

Examples of defect types:

May also have defect severity: minor, major, supermajor.

FC-MDOO Reading and Defect Types (4)

• Horizontal Reading, for internal consistency of a design:

• Ensure that all design artifacts represent the same system.

• Design contains complementary views of the information:

– Static (class diagrams)

– Dynamic (interaction diagrams)

• Not obvious how to compare these different perspectives.

• Vertical Reading, for traceability between reqmts/analysis and design:

• Ensure that the design artifacts represent the same system as described by the requirements and use-cases.

• Comparing documents from different lifecycle phases:

– Level of abstraction and detail are different

Horizontal vs. Vertical Reading:

FC-MD OO Reading and Defect Types (5)

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 perspective

Final list of all defects sent to designer for

repairing

The design inspection process with OO reading techniques:

FC-MD

Requirements for Gas Station Control System

• 1. Gas station: Sells gasoline from gas pumps, rents parking spots, has a cashier and a GSCS.

• 2. Gas pump: Gasoline is sold in self-service gas pumps. The pump has a computer display and keyboard connected to the GSCS, and similarly for a credit card reader. If the pump is vacant, the customer may dispense gasoline. He is assisted in this by the GSCS, who supervises payment (points 7-9), and finally resets the pump to vacant. Gasoline for up to $1000 can be dispensed at a time.

• 3. Parking spot: Regular customers may rent parking spots at the gas station. The cashier queries the GSCS for the next available parking spot, and passes this information back to the customer. See points 7-9 for payment.

• 4. Cashier: An employee of the gas station, representing the gas station owner. One cashier is on-duty at all time. The cashier has a PC and a credit card reader, both communicating with the GSCS. He can rent out parking spots, and receive payment from points 2 & 3 above, while returning a receipt.

Ex. Simplified requirement specification for a Gas Station Control System (GSCS), mainly for payment:

FC-MDRequirements for Gas Station Control System (2)

• 5. Customer May fill up gasoline at a vacant gas pump, rent a parking spot at a cashier, and pay at the gas pump (for gasoline) or at the cashier. Regular customers are employed in a local business, which is cleared for monthly billing.

• 6. GSCS – Keeps inventory of parking spots and gasoline, a register of regular customers and their businesses and accounts, plus a log of purchases. – Has a user interface at all gas pumps and at the cashier’s PC, and is connected to an external Credit Card System and to local businesses (via Internet). – Computes the price for gasoline fill-ups, informs the cashier about this, and can reset the gas pump to vacant. – Will assist in making payments (points 7-9).

• 7. Payment in general Payment time and type is selected by the customer. Payment time is either now or monthly: – If it is now, payment type must be by credit card or cash (incl. personal check). – If it is monthly, payment type must be by billing account to local business. There are two kind of purchase items: gasoline fill-up and parking spot rental. A payment transaction involves only one such item.

FC-MD Requirements for Gas Station Control System (3)

• 8. Payment type

• 8.1 By cash (or personal check): can only be done at the cashier.

• 8.2 By credit card: can be done either at the gas pump or at the cashier. The customer must swipe his credit card appropriately, but with no PIN code.

• 8.3 By billing account: the customer must give his billing account to the cashier, who adds the amount to the monthly bill of a given business account.

• 9. Payment exception

• 9.1 Cash (check) problem: The cashier is authorized to improvise.

• 9.2 Credit card problem: The customer can only wait for 30 seconds for authorization from the Credit Card System. If no response or incorrect credit card number / coverage, the customer is asked for another payment type / credit card. At the gas pump, only one payment attempt is allowed; otherwise the pump is reset to vacant (to not block the lane), and the customer is asked to see the cashier.

• 9.3 Business account problem: If the account is invalid, the customer is asked for another payment type / account number.

FC-MD Requirements for Gas Station Control System (4)

• What about no more gasoline, or no more parking spots?

• How should the user interface dialogs be structured?

• Are any credit card allowed, including banking cards (VISA etc.)?

• What kind of information should be transferred between gas pumps and the GSCS, between the cashier and the GSCS etc.?

• How to collect monthly payment from local businesses?

• How many payment attempts should be given to the customer at the cashier?

• What if the customer ultimately cannot pay?

Ex. Possible weaknesses in GSCS requirements:

Can be found by special reading techniques for requirements, but this is outside our scope here.

FC-MD OO Reading-Related Concepts

• Levels of functionality in a design (used later in the OORTs):

– Functionality: high-level behavior of the system, usually from the user’s point of view. Often a use case. Ex. In a text editor: text formatting. At a gas station: fill-up-gasoline and pay.

– Service: medium-level action performed internally by the system; an “atomic unit” out of which system functionalities are composed. Often a part of a use-case, e.g. a step in the pseudo-code. Ex. In a text editor: select text, use pull-down menus, change font selection. Ex. At a gas station: Transfer $$ from account N1 to N2, if there is coverage.

– Message (function): lowest-level behavior unit, out of which services and then functionalities are composed. Represents basic communication between cooperating objects to implement system behavior. Messages may be shown on sequence diagrams and must be defined in their respective classes. Ex. In a text editor: Write out on a character. Ex. At a gas station: Add $$ to customer bill: add_to_bill(customer, $$, date).

OO Reading-Related Concepts (2)

• Example, part 1: Parking Spot related messages in a sequence diagram for Gas Station.

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]

OO Reading-Related Concepts (3)

• Example, part 2: Abstracting messages to two services for Gas Station – GetParkingSpot (“dotted” lines) and PayParkingSpot (“whole” lines).

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( avai lable 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]

FC-MD OO Reading-Related Concepts (4)

• Constraints/Conditions in requirements:

– Condition (i.e. local pre-condition): what must be true, before a functionality/service etc. can be executed. Example from GSCS’s 7. Payment: … If it (payment time) is now, payment type must be by credit card or cash ... … If it (payment time) is monthly, payment type must be by billing account ...

– Constraint (more global): must be always be true for some system functionality etc. Example from GSCS’s 9.2 Credit card problem: … The customer can only wait for 30 seconds for authorization from the Credit Card System. …

– Constraints can, of course, be used in conditions to express exceptions.– Both constraints and conditions can be expressed as notes in UML class / state /

sequence diagrams.

FC-MD OO Reading-Related Concepts (5)

• Example, part 3: Checking whether a constraint is fulfilled in Gas Station class diagram:

Credit_Card System

+ authorize_payment(customer, amount, date)()

(from External Systems)

[ response time should be less than 30

seconds for all Credit Card Systems ]

FC-MD How are We Learning?

• Receiving feedback from users of the techniques: Controlled Experiments Observational Studies

• Revising the techniques based on feedback: Qualitative (mostly) Quantitative

• Continually evaluating the techniques to ensure they remain feasible and useful

• Negotiating with companies to implement OORTs on real development projects.

• Goal: To assess effectiveness on industrial projects … Are time/effort requirements realistic? Do the techniques address real development needs?

• … using experienced developers. Is there “value added” also for more experienced software engineers?

Empirical Evaluations of OORTs

FC-MDHow are We Learning (2)?

• Controlled Experiment I

– Undergraduate Software Engineering class, UMD, Autumn 1998

– Goal: Feasibility and Global Improvement

• Observational Studies, FC-UMD, Summer 1999

– Goal: Feasibility and Local Improvements

• Observational Studies II, UMD, Autumn 1999

– Two Graduate Software Engineering Classes, UMD, Autumn 1999

– Goal: Observation and Local Improvement

• Controlled Experiment III

– Undergraduate Program-Quality Class, NTNU, Spring 2000

– Goal: Feasibility and Local Adaptation

• Controlled Experiment IV

– Undergraduate Software Engineering Class, UMD, Spring 2000

– Goal: General life-cycle study (part of larger experiment)

Experiments so far:

FC-MDHow are We Learning (3)?

• 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

What we know:

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, e.g. by a better UML tool?

– Some steps are repetitive and mechanical

– Need to identify clerical activities

• See:– http://www.cs.umd.edu/Dienst/UI/2.0/Describe/ncstrl.umcp/CS-TR-4070

– http://fc-md.umd.edu/reading.html

FC-MD

Experimental Set-up for OO Reading

• Goals: Learn defect detection techniques and specially OORTs, check if the OORTs are feasible and receive proposals to improve them, compare discovered defects with similar OORT experiments at Univ. Maryland.

• Process:

– Make groups: two students in each group (a pair), based on questionnaires. Half of the groups are doing OORTs 2, 3, 6, 7 (mainly state diagrams), the other half OORTs 1, 4, 5, 6 (mainly class/sequence diagrams).

– General preparation: Two double lectures on principles and techniques (8 h).

– Special preparation (I1): Look at requirements and guidelines (2h, self study).

– OO Design Reading (I2): Read and fill out defect/observ. reports (6h, paired); one group member does the reading, the other is observing the first.

• Given documents: lecture notes w/ guidelines for OORT1-7 and observation studies, defect and observation report forms, questionnaires to form groups and resulting group allocation, set of “defect-seeded” software documents (requirement description, use cases, state/sequence/class diagrams, and class descriptions) – either for Loan Arranger or Parking Garage example.

• Other materials: green, blue and yellow pens (for markups).

Experimental set-up for OORT

FC-MD Experimental Set-up for OO Reading (2)

• OORT-1: Sequence Diagram x Class Diagram

• OORT-2: State Diagram x Class Description

• OORT-3: State Diagram x Sequence Diagram

• OORT-4: Class Diagram x Class Description

• OORT-5: Class Description x Requirement Description

• OORT-6: Sequence Diagram x Use Case Diagram

• OORT-7: State Diagram x Requirement Description / Use Case Diagram

• Abbreviations: Requirement Description (RD), Use Case Diagram (UC), Class Diagram (CD), Class Description (CDe), State Diagram (StD), Sequence Diagram (SqD).

• Defect types from p.10-12: report appropriately when a defects is found.

The seven OO Reading Techniques (OORTs)

FC-MDOORT-1: Sequence Diagram x Class Diagram

• Inputs:

– 1. A class diagram, possibly in several packages.

– 2. Sequence diagrams.

• Outputs:

– 1. Annotated versions of above diagrams.

– 2. Discrepancy reports.

• Goal: To verify that the class diagram for the system describes classes and their relationships in such a way that the behaviors specified in the sequence diagrams are correctly captured.

• Instructions:

– Do steps R1.1 and R1.2.

OORT-1: Sequence Diagram x Class Diagram

FC-MDOORT-1: Sequence Diagram x Class Diagram (2)

• Inputs:

– 1. Sequence diagram (SqD).

• Outputs:

– 1. System objects, classes and actors (underlined with blue on SqD);

– 2. System services (underlined with green on SqD);

– 3. Constraints/conditions on the messages/services (circled in yellow on SqD). I.e., a marked-up SqD is produced, and will be used in R1.2.

• Instructions: – matches outputs above.

– Q11.a: Underline system objects, classes and actors in blue on SqD.

– Q11.b: Underline system services in green on SqD.

– Q11.c: Circle constraints/conditions on messages/services in yellow on SqD.

Step R1.1: From a sequence diagram – identify system objects, system services, and conditions.

FC-MD

OORT-1: Sequence Diagram x Class Diagram (3)

• Inputs:

– 1. Marked up sequence diagrams (SqDs) – from R1.1.

– 2. Class diagrams (CDs).

• Outputs:


• Instructions (as questions – here and after):

– Q12.a: Can every object/class/actor in the SqD be found in the CD? Possible [inconsistency?]

– Q12.b Can every service/message in the SqD be found in the CD, and with proper parameters? [inconsistency?]

– Q12.c: Are all system services covered by (low-level) messages in the SqD? Possible [omission?]

– Q12.d: Is there an association or other relationship between two classes in case of message exchanges? [omission?]

– Q12.e: Is there a mismatch in behavior arguments or in how constraints / conditions are formulated between the two documents? [inconsistency?]

Step R1.2: Check related class diagrams, to see if all system objects are covered.

FC-MDOORT-1: Sequence Diagram x Class Diagram (4)

• Step R1.2 instructions (cont’d ):

– Q12.f: Can the constraints from the SqD in R1.1 be fulfilled? E.g. Number of objects that can receive a message (check cardinality in CD)? E.g. Range of data values? E.g. Dependencies between data or objects? E.g. Timing constraints? Report any problems. [ inconsistency?]

– Q12.g: Overall design comments, based on own experience, domain knowledge, and understanding: E.g. Do the messages and their parameters make sense for this object? E.g. Are the stated conditions appropriate? E.g. Are all necessary attributes defined? E.g. Do the defined attributes/functions on a class make sense? E.g. Do the classes/attributes/functions have meaningful names? E.g. Are class relationships reasonable and of correct type? (ex. association vs. composition relationships). Report any problems. [incorrect fact?]

FC-MD

OORT-2: State Diagram x Class Description

• Inputs:

– 1. A set of class descriptions.

– 2. A set of state diagrams for the system objects

• Outputs:

– 1. Discrepancy reports

• Goal: To verify that the classes are defined, so that they can capture the functionality specified by the state diagram.

• Instructions:

– Repeat steps R2.1 – R2.3 for each state diagram (StD).

OORT-2: State Diagram x Class Description

FC-MDOORT-2: State Diagram x Class Description (2)

• Inputs:

– 1. State diagram (StD).

– 2. Set of class descriptions (CDe).

• Outputs:

– 1. Object states (marked in blue on StD).

– 2. Transition actions/conditions (marked in green on StD). I.e., a marked-up state diagram is produced, used in R2.2 and R2.3.


• Instructions:

– Q21.a: Identify the actual class from the state diagram. Missing? [omission?]

– Q21.b: Underline the name of each object state (by blue pen).

– Q21.c: Underline the transition actions/conditions (by green pen).

– Q21.d: Can you understand the object's behavior from Q21.b-c above? [ambiguity?]

Step R2.1: Read state diagram to understand possible states and their transition.


• Inputs: partly from state diagram (StD)


– 2. Object states (marked in blue on StD – from R2.1).

– 3. Transition actions/conditions (marked in green on StD – from R2.1).

• Outputs:


• Instructions: see next page.

Step R2.2: Identify the associated class, and its attributes and behavior.


• Step R2.2 instructions:– Q22.a: In the CDe, identify the class being modeled by this state diagram.

Missing? [omission?]

– Q22.b: Find out how a blue state is represented, i.e. has the class captured each modeled state in a unique way?

E.g. by an explicit attribute. E.g. by an implicit attribute (merely via control flow). E.g. by a combination of attributes. E.g. by subtyping of the actual object (consult the class hierarchy). Report the result. [inconsistency? or ambiguity?]

– Q22.c: Are all green transition actions/conditions covered by class behavior? If not: error. [inconsistency?]

– Q22.d: Are green transition conditions using object data, that are defined as class attributes with matching names?

If not: error. [inconsistency?]


• Inputs: from state diagram (StD)

– 1. Object states (marked in blue on StD – from R2.1).

– 2. Transition actions and conditions (marked in green on StD – from R2.1).

• Outputs:


• Instructions:

– Q23.a: From your domain knowledge, are all relevant states defined in the StD? [incorrect fact?]

– Q23.b: For each unmarked state, assess if it is appropriate and essential: [incorrect fact? or extraneous?]

– Q23.c: For each unmarked transition action/condition: there is missing information. [inconsistency?]

Step R2.3: Compare class diagram to state diagram.

FC-MDOORT-3: Sequence Diagram x State Diagram

• Inputs:

– 1. A set of sequence diagrams.

– 2. A set of state diagrams for several objects.

• Outputs:


• Goal: To verify that every state transition for an object can be achieved by the messages sent and received by that object.

• Instructions:

– Repeat steps R3.1 – R3.3 for each state diagram (StD).

OORT-3: Sequence Diagram x State Diagram

FC-MDOORT-3: Sequence Diagram x State Diagram (2)

• Inputs:

– 1. Given state diagram (StD).

• Outputs:

– 1. Marked-up state diagram (StD), with transition actions labeled in green.


• Instructions:

– Q31.a: Determine which class is being modeled. Missing? [omission?]

– Q31.b: Trace all transitions from the start state to the end state, and mark corresponding actions with a unique name (A1, A2 etc.) with a

green pen.

– Q31.c: In general, do these transitions/actions and states make sense and are they understandable for such an object? [ambiguity?]

Step R3.1: Read the state diagram to understand the possible object states, their transitions and corresponding actions.


• Inputs:

– 1. Marked-up state diagram (StD) (w/ transition actions in green – from R3.1).

– 2. Set of sequence diagrams (SqD).

• Outputs:

– 1. Marked-up sequence diagrams (SqD), with matching object messages labeled in green.


• Instructions: see next page.

Step R3.2: Read the sequence diagrams to understand how the transition actions are achieved by messages sent

to/from the relevant object.


• Step R3.2 instructions: – Q32.a: Pick the relevant subset of SqDs concerning this state diagram (StD). Is

there a problem to identify these? [omission? or extraneous?] For each relevant sequence diagram (SqD) do below points Q32.b-e:

– Q32.b: Read the sequence diagram to identify the associated system service and its messages.

– Q32.c: Identify the object states in the StD, being semantically related to the actual system service.

– Q32.d: Map message arrows (one or many) in the SqD to state transitions in the StD. Are there “enough” messages to accomplish a given transition? [omission?] Mark related SqD-messages and StD-transitions with a green star.

– Q32.e: Look for constraints and conditions on the above SqD-messages. Check if the same constraint/condition information stands in both diagrams. [inconsistency?]

Such SqD-information may be correspondingly expressed in the StD by: 1) State information (e.g. t>0), 2) Transition information (what occurs when t>0?), 3) Nothing (not relevant for StD).


• Inputs:

– 1. Transaction actions on the given StD (labeled in green – from R3.1)

– 2. Object messages on the SqD (labeled in green – from R3.2)

• Outputs:


• Instructions:

– Q33.a: Look for unlabeled transaction actions in the StD, i.e. those not implemented by available messages in the SqD (cf. Q32.d).

Report these. [inconsistency?]

– Q33.b: Are the event order the same in the StD and SqD, i.e. check if labeled messages/transitions in the SqD appear in logical order? [inconsistency?] E.g. that action Ax on a later transition in the StD actually occurs after an action Ay on an earlier transition.

Step R3.3: Review the marked-up diagrams to make sure that all transition actions are accounted for.

FC-MDOORT-4: Class Diagram x Class Description

• Inputs:

– 1. A class diagram, possibly in several packages.

– 2. A set of class descriptions.

• Outputs:


• Goal: To verify that the detailed descriptions of classes contain all the information necessary according to the class diagram, and that the description of

classes make semantic sense.

• Instructions:

– Repeat steps R4.1 and R4.2 for each class in the class diagram (CD).

OORT-4: Class Diagram x Class Description

FC-MDOORT-4: Class Diagram x Class Description (2)

• Inputs: – 1. Given class from class diagram (CD).– 2. A set of class descriptions (CDe).

• Outputs: – 1. Discrepancy reports.

• Instructions:– Q41.a: Is there a CDe for this class? [omission?]

Mark with a star (“*”) in blue on the CDe when found, see R4.2.– Q41.b: Is the name and textual description of this class meaningful in the CDe?

[ambiguity?]– Q41.c: Are attributes and their types consistent between the CD and CDe?

[inconsistency? ] – Q41.d: Can this class meaningfully contain all these attributes and with

given types? [ambiguity? or incorrect fact? ]

Step R4.1: Read the class diagram to understand the necessary properties.


• Step R4.1 instructions (cont’d):

– Q41.e: On behavior and constraints: E.g. Check consistency for behavior and constraints between the CD and CDe. E.g. Are behaviors in the CDe described at the same level of detail / pseudocode? [inconsistency?] E.g. In general, should this class really contain all these behaviors and constraints? [incorrect fact?] E.g. Do the behaviors and constraints in the CDe use available behaviors or attributes from elsewhere, and are they defined? [omission? or ambiguity?] E.g. Do the behaviors and constraints in the CDe rely "excessively" on attributes in remote classes? I.e. too high coupling. [miscellaneous?]


• Step R4.1 instructions (cont’d 2)

– Q41.f: In case of use of inheritance in the CD: E.g. Is inheritance also included in the CDe? [omission?] E.g. In general, is it “meaningful” for the given class be a supertype/subtype of the given subclasses/superclass? [miscellaneous?]

– Q41.g: Check that all relationships are correctly described: E.g. Do they have the right cardinalities, and are they also defined in the CDe? [inconsistency?] E.g. Were object roles in the CD also defined in the CDe? [inconsistency?] E.g. Is the correct graphical notation used in the CD? [inconsistency?] E.g. In general, do the stated relationships “make sense”, such as composition vs. aggregation vs. association vs. inheritance etc.? [miscellaneous?] E.g. Is an attribute used to represent a relationship, and does this have the right type (a reference or sets of references)? [inconsistency?]


• Inputs:

– 1. A set of class descriptions (CDe).

• Outputs:


• Instructions:

– Q42.a: Are there any unstarred (i.e. superfluous) classes in the CDe? [extraneous?]

Step R4.2: Review the class for extraneous information.

FC-MDOORT-5: Class Description x Requirement Description

• Inputs:

– 1. A set of requirement descriptions (RD), mainly functional.

– 2. A set of class descriptions (CDe).

• Outputs:


• Goal: To verify that the concepts and services that are described by the functional requirements are captured by the class descriptions.

• Instructions:

– Do steps R5.1 - R5.3.

OORT-5: Class Description x Requirement Description

FC-MD

OORT-5: Class Description x Requirement Description (2)

• Inputs:

– 1. Set of requirement descriptions (RD).


• Outputs:

– 1. Candidate classes/objects/attributes (marked in blue in RD).

– 2. Candidate services (marked in green in RD).

– 3. Constraints or conditions on services (marked in yellow in RD). I.e., a marked-up RD is produced, used in R5.2 and R5.3 below.

• Instructions:

– Q51.a: Find the nouns, being candidates for classes/objects/attributes. Underline with a blue pen.

– Q52.b: Find the verbs or action descriptions, being candidates for services or behaviors. Underline with a green pen.

– Q52.c: Look for constraints and conditions on nouns/verbs above, e.g. for relationships, limiting quantities, or non-functional requirements. Underline with a yellow pen.

Step R5.1: Read the requirements to understand the functionality described.

FC-MDOORT-5: Class Description x Requirement Description (3)

• Inputs:

– 1. Set of marked-up requirement descriptions (RD) – from R5.1


• Outputs:

– 1. Corresponding concepts have been marked on the RD and CDe.


• Instructions:

– Q52.a: For each green-underlined verb/action in the RD: E.g. Find associated behavior(s) in the CDe. E.g. Do the classes/objects receive the right information to accomplish their required behavior, and are appropriate results produced? [incorrect fact?]

Step R5.2: Compare the class description to the requirements.


• Step R5.2 instructions (cont’d):

– Q52.b: For each blue-underlined noun/concept in the RD, try to find an associated class in the CDe, and mark both with a blue star (“*”). E.g. Does the class description contain sufficient and clear information for this

concept, and does the class name resemble the noun you had marked? [ambiguous?] E.g. Does the class encapsulate related (blue-marked) attributes, and does the class encapsulate related (green-marked) behavior, and are all identified constraints and conditions for this class described in the RD? [omission?]

– Q52.c: For each remaining, blue-underlined noun/concept in the RD, try to find a matching attribute in the CDe, and mark both with a blue star (“*”).

E.g. In general, is the CDe using appropriate types to represent information from the RD, and are the (yellow-underlined) constraints and conditions on these attributes also contained in the CDe? [incorrect fact?]


• Inputs:

– 1. Set of marked-up requirement descriptions (RD) – from R5.1.

– 2. Set of marked-up class descriptions (CDe) – from R5.2.

• Outputs:


• Instructions:

– Q53.a: Are there still unstarred blue-underlined nouns or green-underlined activities in the RD, i.e. not being represented in the Cde? [omission?]

Note: some RD-concepts may have been used just for explanation.

Step R5.3: Review the Class Descriptions and Requirement Documents to ensure that all concepts mutually correspond.

FC-MDOORT-6: Sequence Diagram x Use Case Diagram

• Inputs:

– 1. A use case diagram (UC) for a part of the system, with its services.

– 2. One or more sequence diagrams (SqD) for relevant system objects and services.

– 3. A set of associated class descriptions (CDe).

• Outputs:


• Goal: To verify that sequence diagrams describe an appropriate combination of objects and messages that capture the functionality from the use case.

• Instructions:

– Do steps R6.1 – R6.3 (only R6.3 finds defects).

OORT-6: Sequence Diagram x Use Case Diagram

FC-MDOORT-6: Sequence Diagram x Use Case Diagram (2)

• Inputs:

– 1. Use case diagram (UC).

• Outputs:

– 1. System concepts (marked by blue on UC).

– 2. System services provided (marked by green on UC).

– 3. Data necessary to achieve such services (marked by yellow on UC).

• Instructions: (similar to R5.1 for RD, but here for UC)

– Q61.a: Find the unique nouns/concepts in the UC. Underline and number consecutively with a blue pen (used in Q61.d).

– Q61.b: For each noun, find verbs/actions "to or by" that noun. Underline and number in assumed performance order with a green pen.

– Q61.c: Mark constraints/conditions in double-green (part of service marking).

– Q61.d: Also find the information or data to be sent/received in order to perform a certain action. Label the data in yellow as "Dx,y", where x,y are the nouns involved.

Step R6.1: Identity the main functionality of a use case and its important system concepts.


• Inputs:

– 1. Use case diagram (UC), marked-up w/ concepts, services, and data – from R6.1.

– 2. A set of sequence diagrams (SqD).

• Outputs:

– 1. System concepts (marked in blue on SqD).

– 2. System services (marked in green on SqD).

– 3. Data exchanged between objects (marked in yellow on SqD).

• Instructions: see next page. (cf. above R6.1, but here for SqD)

Step R6.2: 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.


• Step R6.2 instructions:

– Q62.a: For each SqD, underline in blue the system objects, and with the same noun number (from Q61.a) as in the UC.

– Q62.b: Identify the services described in the SqD. I.e. look at the horizontal message arrows between objects, and possibly cluster several arrows into one service. Underline the identified services in green, and number them in occurrence order (top-to-bottom) in the SqD.

– Q62.c: Identify information/data exchanged between two system classes (x,y). Label the data in yellow as "Dx,y", as in R6.1.


• Inputs:

– 1. Use case (UC), w/ marked-up concepts, services, and data – from R6.1.

– 2. Set of sequence diagrams (SqD), with similar mark ups – from R6.2.

• Outputs:


• Instructions:

– Q63.a: For each blue-marked noun in the UC, search for a similar one in the SqD. Mark by blue star (“*”) in the UC if found. For unstarrred nouns in the UC, check also if they possibly are attributes in some class. The remaining, unstarred nouns from the UC may represent defects, as they are missing in the design (SqD). [omission?]

Step R6.3: Compare the marked-up Use Case / Sequence Diagrams to determine whether they represent the same domain concepts.


• Step R6.3 instructions (cont’d):– Q63.b: Similarly, for each unmarked noun in the SqD, it may belong to some

design-internal or worse: an unused concept. [extraneous?]

– Q63.c: For each blue-marked service in the SqD, look for the corresponding one in the UC. E.g. Are SqD classes/objects exchanging messages in the same order as in the UC? If not, this may be a defect. E.g. Are message parameters on the SqD correctly described in the UC, e.g. right data between right Dx,y etc.? E.g. Is it possible to “understand” the expected functionality, for instance from data being sent/received, by just reading the SqD? Report any problem in all this. [inconsistency? or ambiguity?]

– Q63.d: Are double-green-marked constraints/conditions from the UC being observed by the SqD? [incorrect fact?]

FC-MDOORT-7: State Diagram x (Rqmt Descr / Use Case)

• Inputs:

– 1. The set of all state diagrams (StD).

– 2. The set of all requirement descriptions (RD).

– 3. The set of use case diagrams (UC).

• Outputs:


• Goal: To verify that the state diagrams describe appropriate states of objects and events that trigger state changes as described by the requirements and use cases.

• Instructions: For each state diagram(StD) / object, do the steps R7.1 - R7.4:

OORT-7: State Diagram x (Requirement Description and Use Case Diagram)

FC-MD

OORT-7: State Diagram x (Rqmt Descr / Use Case) (2)

• Inputs:

– 1. Set of requirement descriptions (RD).

• Outputs:

– 1. Object States (marked in blue on RD).

– 2. Adjacency Matrix (AM), recording if there is a state transition from one state to another.

• Instructions: see next page (just reading).

Step R7.2: Read the functional requirements to determine the possible states of the object, which states are adjacent to each other, and which events/actions cause the state changes.

Step R7.1: Read the state diagram to basically understandwhat the object it is modeling

(nothing more here).

FC-MDOORT-7: State Diagram x (Rqmt Descr / Use Case) (3)

• Step R7.2 instructions:

– Q72.a: Put away the StD and erase any previous stars (“*”) in the RD. Read through the RD and mark up lightly – with a star (“*”) by a pencil –

the places where the actual StD-object/concept is used.

– Q72.b: Locate all corresponding places in the RD for all different states of this object, mark these places with a blue pen and number them from 1..N.

– Q72.c: Identify which of the numbered states being the Initial state ("I"), and similarly with the end state ("E").

– Q72.d: Make a N*N Adjacency Matrix (AM) on a separate sheet of paper. Try to identify possible ij-state transitions here, i.e. if state i can lead to state j. Put a check mark (“v”) in these AM-ij entries.


• Inputs:

– 1. Use case diagrams (UC).

– 2. Preliminary Adjacency Matrix (AM) – from R7.2.

• Outputs:

– 1. Completed Adjacency Matrix (AM).

• Instructions: (just reading)

– Q73.a: Read through the use cases and find the ones where the object participates.

– Q73.b: For each marked AM-ij entry (i.e. having a transition), document precisely the associated event and/or constraint someplace on the AM paper sheet.

– Q73.b: For the blank entries, see if there still might be events that may cause the transition. If not, write a “X” in that entry.

Step R7.3: Read the use cases and determine the events that cause state changes.


• Inputs:

– 1. Marked-up requirement descriptions (RD) – from R7.2.

– 2. Set of state diagrams (StD).

– 3. Completed Adjacency Matrix (AM) – from R7.3.

• Outputs:


• Instructions: Repeat the following steps for each state diagram (StD):

Step R7.4: Read the state diagrams to determine if the described states are consistent with the requirements, and if the transitions are consistent with the requirements and use cases.


• Step R7.4 instructions:– Q74.a: For each numbered state in the RD, find the corresponding state in the StD

and mark it with a blue pen and corresponding number. Note: state names may be different in the RD and the StD, and overlapping names may not represent identical states. E.g. Were all states in the RD found in the StD? [omission?] Or maybe some RD states were combined into one StD state, but this was not a sensible combination? [incorrect fact?] E.g. Inversely, were there extra states in the StD? [extraneous?] Or maybe a RD state was split into more than one StD state, but again this was not a sensible combination? [incorrect fact?]

– Q74.b: Check transition events and actions in the AM-matrix/sheet: E.g. Do all events in the AM appear on the StD? [omission?] E.g. Do all events in the StD appear on the AM? [extraneous?]

– Q74.c: Check transition constraints in the AM-matrix/sheet: E.g. Do all constraints in the AM appear on the StD? [omission?] E.g. Do all constraints in the StD appear on the AM? [extraneous?]