1 / 64

OO Reading Techniques for Design Inspections

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

helia
Download Presentation

OO Reading Techniques for Design Inspections

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. 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; fshull@fc-md.umd.edu http://www.cs.umd.edu/projects/SoftEng/ESEG/ conradi@idi.ntnu.no, http://www.idi.ntnu.no/grupper/SU-grp OO Reading Techniques for Design Inspections UFRJ COPPE Department of Computer Science Experimental Software Engineering Group Fraunhofer Center - Maryland

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

  3. Reading and Inspections Why read software? • 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 findingdefects (“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.

  4. Reading and Inspections (2) Classic inspections • “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.

  5. Reading and Inspections (3) Different needs and techniques of reading: Technology Technology Reading General Goal General Goal Analysis Construction PROBLEM SPACE (needs) Specific Goal Specific Goal Usability Defect Detection Document Document Design Requirements Code User (artifact) (artifact) Interface UML Diagrams Notation Notation SCR English Screen Shot Form Form SOLUTION SPACE (techniques, perspectives) Traceability Family Family Perspective-based Usability-based Defect-based Horizontal Vertical Incorrect Expert Novice Error Technique Technique Omission Developer Tester User Ambiguity Inconsistent

  6. OO Reading and UML Documents • 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) UML Artifacts/Diagrams, five used later (*): • Dynamic View • Use cases (analysis) * • Activities • Interaction • sequences * • collaborations • State machines * • Static View • Classes * • Relationships • Generalization - IsA • Composition - PartsOf • Association - HasA • Dependency - DependsOn • Realization • Extensibility • Constraints • Stereotypes • Descriptions (generated from UML) * • Packages • Deployment

  7. OO Reading and UML Documents (2) Our six relevant software artifacts: • 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.

  8. OO Reading and UML Documents (3) The six software artifacts: requirement description, use cases and four design documents in UML:

  9. OO Reading and UML Documents (4) • SoftwareArtifacts, with OO ReadingTechniques (OORTs) indicated: Requirements Requirements Use-Cases Specification/Analysis Descriptions OORT-7 OORT-5 OORT-6 Class Class State Sequence High Level Diagrams Descriptions Diagrams Diagrams Design OORT-4 OORT-2 OORT-3 OORT-1 Vertical reading Horizontal reading

  10. OO Reading and Defect Types Reading Techniques and defect types: Domain Knowledge Other Domain General Requirements incorrect fact extraneous Software (Design) Artifacts omission inconsistency ambiguity • 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.

  11. OO Reading and Defect Types (2)

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

  13. OO Reading and Defect Types (4) Horizontal vs. Vertical Reading: • 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

  14. OO Reading and Defect Types (5) The design 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 perspective looking for consistency horizontal reading Reader 2 looking for traceability vertical reading Final list of all defects sent to designer for repairing Reader 3

  15. Requirements for Gas Station Control System Ex. Simplifiedrequirement specificationfor aGas Station Control System (GSCS), mainly for payment: • 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.

  16. Requirements 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.

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

  18. Requirements for Gas Station Control System (4) Ex. Possible weaknesses in GSCS requirements: • 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? Can be found by special reading techniques for requirements, but this is outside our scope here.

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

  20. OO Reading-Related Concepts (2) • Example, part 1: Parking Spot related messages in a sequence diagram for Gas Station.

  21. OO Reading-Related Concepts (3) • Example, part 2: Abstracting messages to two services for Gas Station – GetParkingSpot (“dotted” lines) and PayParkingSpot (“whole” lines).

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

  23. OO Reading-Related Concepts (5) • Example, part 3: Checking whether a constraint is fulfilled in Gas Station class diagram: Credit_Card System (from External Systems) + authorize_payment(customer, amount, date)() [ response time should be less than 30 seconds for all Credit Card Systems ]

  24. How are We Learning? Empirical Evaluations of OORTs • 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?

  25. How are We Learning (2)? Experiments so far: • 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)

  26. How are We Learning (3)? What we know: • 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 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

  27. Experimental Set-up for OO Reading Experimental set-up for OORT • 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 requirementsand 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).

  28. Experimental Set-up for OO Reading (2) The seven OO Reading Techniques (OORTs) • 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.

  29. OORT-1: Sequence Diagram x Class Diagram OORT-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.

  30. OORT-1: Sequence Diagram x Class Diagram (2) Step R1.1: From a sequence diagram – identify system objects, system services, and conditions. • 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.

  31. OORT-1: Sequence Diagram x Class Diagram (3) Step R1.2: Check related class diagrams, to see if all system objects are covered. • Inputs: • 1. Marked up sequence diagrams (SqDs) – from R1.1. • 2. Class diagrams (CDs). • Outputs: • 1.Discrepancy reports. • 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?]

  32. OORT-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?]

  33. OORT-2: State Diagram x Class Description 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: • RepeatstepsR2.1 – R2.3 for each state diagram (StD).

  34. OORT-2: State Diagram x Class Description (2) Step R2.1: Read state diagram to understand possible states and their transition. • 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. • 3. Discrepancy reports. • 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?]

  35. OORT-2: State Diagram x Class Description (3) Step R2.2: Identify the associated class, and its attributes and behavior. • Inputs: partly from state diagram (StD) • 1. Set of class descriptions (CDe). • 2. Object states (marked in blue on StD – from R2.1). • 3. Transition actions/conditions (marked in green on StD – from R2.1). • Outputs: • 1. Discrepancy reports. • Instructions: see next page.

  36. OORT-2: State Diagram x Class Description (4) • 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?]

  37. OORT-2: State Diagram x Class Description (5) Step R2.3:Compare class diagram to state diagram. • 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: • 1. Discrepancy reports. • 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?]

  38. OORT-3: Sequence Diagram x State Diagram OORT-3: Sequence Diagram x State Diagram • Inputs: • 1. A set of sequence diagrams. • 2. A set of state diagrams for several objects. • Outputs: • 1. Discrepancy reports. • 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).

  39. OORT-3: Sequence Diagram x State Diagram (2) Step R3.1:Read the state diagram to understand the possible object states, their transitions and corresponding actions. • Inputs: • 1. Given state diagram (StD). • Outputs: • 1. Marked-up state diagram (StD), with transition actions labeled in green. • 2. Discrepancy reports. • 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?]

  40. OORT-3: Sequence Diagram x State Diagram (3) Step R3.2:Read the sequence diagrams to understand how the transition actions are achieved by messages sent to/from the relevant object. • 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. • 2. Discrepancy reports. • Instructions: see next page.

  41. OORT-3: Sequence Diagram x State Diagram (4) • 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).

  42. OORT-3: Sequence Diagram x State Diagram (5) Step R3.3: Review the marked-up diagrams to make sure that all transition actions are accounted for. • Inputs: • 1. Transaction actions on the given StD (labeled in green – fromR3.1) • 2. Object messages on the SqD (labeled in green – from R3.2) • Outputs: • 1. Discrepancy reports. • 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.

  43. OORT-4: Class Diagram x Class Description OORT-4: Class Diagram x Class Description • Inputs: • 1. A class diagram, possibly in several packages. • 2. A set of class descriptions. • Outputs: • 1. Discrepancy reports. • 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 eachclass in the class diagram (CD).

  44. OORT-4: Class Diagram x Class Description (2) Step R4.1: Read the class diagram to understand the necessary properties. • 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? ]

  45. OORT-4: Class Diagram x Class Description (3) • 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?]

  46. OORT-4: Class Diagram x Class Description (4) • 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?]

  47. OORT-4: Class Diagram x Class Description (5) Step R4.2: Review the class for extraneous information. • Inputs: • 1. A set of class descriptions (CDe). • Outputs: • 1. Discrepancy reports. • Instructions: • Q42.a: Are there any unstarred (i.e. superfluous) classes in the CDe? [extraneous?]

  48. OORT-5: Class Description x Requirement Description OORT-5: Class Description x Requirement Description • Inputs: • 1. A set of requirement descriptions (RD), mainly functional. • 2. A set of class descriptions (CDe). • Outputs: • 1. Discrepancy reports. • 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.

  49. OORT-5: Class Description x Requirement Description (2) Step R5.1: Read the requirements to understand the functionality described. • Inputs: • 1. Set of requirement descriptions (RD). • 2. Set of class descriptions (CDe). • 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.

  50. OORT-5: Class Description x Requirement Description (3) Step R5.2: Compare the class description to the requirements. • Inputs: • 1. Set of marked-up requirement descriptions (RD) – from R5.1 • 2. Set of class descriptions (CDe). • Outputs: • 1. Corresponding concepts have been marked on the RD and CDe. • 2. Discrepancy reports. • 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? [incorrectfact?]

More Related