Object-Oriented Software Engineering Revision Paul J Krause

Software Lifecycle Customer Requirements Functional Requirements Design Implementation Unit Test System Test Acceptance Test Lecture 10 Lecture 11 Lectures 6/8/9 Most of the rest! Lecture 18

Customer Requirements Functional Requirements Design Implementation Unit Test System Test Acceptance Test Lecture 10 Lecture 11 Lectures 6/8/9 Most of the rest! Lecture 18

Why Requirements? “The firms improving their development speed at the fastest rate actually spend more elapsed time and more effort in the customer requirements stage of the project …. These firms spend significantly less time in the testing and integration stage of development.…” Blackburn, Scudder, et al, in Improving Speed and Productivity of Software Development: A Global Survey of Software Developers (1996) Resources spent on Customer Requirements:

Tom on ‘Requirement’ Requirement: Concept *026 November 8, :16 Requirement: Concept *026 November 8, :16 A requirement is a stakeholder-desired Target or Constraint. A requirement is a stakeholder-desired Target or Constraint. Notes: Notes: 1. The constraints can apply to an engineering process, a design or an operational system. 1. The constraints can apply to an engineering process, a design or an operational system. 2. A requirement is an input to a defined level of design process. 2. A requirement is an input to a defined level of design process. 3. Requirements give information to the designer about the necessary nature of their design. 3. Requirements give information to the designer about the necessary nature of their design. 4. Consequently the design, specification or implementation, can be judged {Spec QC, review, test or in operation} in terms of how well it satisfies those requirements. 4. Consequently the design, specification or implementation, can be judged {Spec QC, review, test or in operation} in terms of how well it satisfies those requirements. INTRO

Requirement Specification. Requirement Specification. Concept *508. November 8, Requirement Specification. Concept *508. November 8, A requirement specification is the readable expression of a requirement and any requirement background. A requirement specification is the readable expression of a requirement and any requirement background.  Related Concepts:  requirement *026 the future state or constraint  specification *137 the readable artifact  background *507 additional information about the requirement

Stakeholders: requirements sources  ‘Stakeholders’ are: Any person, group or thing which Any person, group or thing which Can determine our system’s degree of success or failureCan determine our system’s degree of success or failure By having an “opinion” aboutBy having an “opinion” about system performance characteristics system performance characteristics system lifecycle constraints system lifecycle constraints Stakeholders determine requirements! Stakeholders determine requirements! Systems engineers determine which requirements the stakeholders need Systems engineers determine which requirements the stakeholders need Even if the stakeholders are not currently conscious of those needs!Even if the stakeholders are not currently conscious of those needs!

Non-functional Requirements  Functional Requirements What the system should do - the services it should provide What the system should do - the services it should provide  Non-Functional Requirements The constraints that must be adhered to during development The constraints that must be adhered to during development Performance, memory, reuse, usability, … Performance, memory, reuse, usability, … See Tom Gilb, and our Lecture 10 See Tom Gilb, and our Lecture 10

Functional Requirements Customer Requirements Functional Requirements Design Implementation Unit Test System Test Acceptance Test Lecture 10 Lecture 11 Lectures 6/8/9 Most of the rest! Lecture 18

What are Actors and Use Cases?  Actors - users of the system external entities (people or other systems) who interact with the system to achieve a desired goal. external entities (people or other systems) who interact with the system to achieve a desired goal.  Use Cases - what happens when Actors interact with the system by recording all the ways the system is used (“cases of use”) we accumulate all the goals or requirements of the system. by recording all the ways the system is used (“cases of use”) we accumulate all the goals or requirements of the system.

Identifying Actors  Who uses the system?  Who installs the system?  Who starts up the system?  Who maintains the system?  Who shuts down the system?  What other systems use the system?  Who gets information from this system?  Who provides information to the system?  Does anything automatically happen at preset times?

Examples of Actors CustomerClerkShipping Company Supplier

Use Case Diagram CustomerClerkShipping Company Supplier Place Order Get Order Status Calculate Postage Supply Product Deliver Package

Use Case: Place Order Customer Place Order

Place Order: Flow of Events Trigger: The Customer selects a Product category 1. The Customer browses the chosen Product category page 2. The Customer selects a specific Product to purchase 3. The Customer adds the Product to their Shopping Cart 4. The Customer may repeat events 1, 2 and 3 to add additional items to their Shopping Cart 5. When ready, the Customer requests that the Order be commited to 6. The Credit Company is notified to authorise the Customer’s credit rating 7. If the credit rating is positive, the Order will be placed

Nouns as Candidate Classes Trigger: The Customer selects a Product category 1. The Customer browses the chosen Product category page 2. The Customer selects a specific Product to purchase 3. The Customer adds the Product to their Shopping Cart 4. The Customer may repeat events 1, 2 and 3 to add additional items to their Shopping Cart 5. When ready, the Customer requests that the Order be commited to 6. The Credit Company is notified to authorise the Customer’s credit rating 7. If the credit rating is positive, the Order will be placed

Design Customer Requirements Functional Requirements Design Implementation Unit Test System Test Acceptance Test Lecture 10 Lecture 11 Lectures 6/8/9 Most of the rest! Lecture 18

Identifying classes  Think about general properties of the domain in which you are working  Identify the nouns  These form candidate classes A Publisher produces and markets a Book A Customer purchases a Book An Author writes a Book

Publisher name address webSite Book bookNumber title unitPrice Customer name shippingAddress Author name address webSite

Publisher name address webSite Book bookNumber title unitPrice Customer name shippingAdd Author name address webSite R1R3 R2 is produced and marketed by produces and markets purchases is sold to wrote was written by

Publisher name address webSite Book bookNumber title unitPrice Customer name shippingAdd Author name address webSite R1R3 R2 is produced and marketed by produces and markets purchases is sold to wrote was written by 10..*1..* 0..* 1..* There are books not sold to any customer To be a customer you must have purchased at least one book But where do I put the number of books a customer purchased?

Publisher name address webSite BookProduct bookNumber title unitPrice Customer name shippingAdd Author name address webSite R1R3 R2 is produced and marketed by produces and markets is a purchase of is sold as wrote was written by 10..*1..* 0..* 1..* Order quantity salePrice date makes1..* is made by 1

Interaction Diagrams  These are used to model the dynamic aspects of a software system  Typically, a class diagram and Use Cases are used as inputs to the development of interaction diagrams  In UML there are two kinds of interaction diagram Sequence diagrams Sequence diagrams Collaboration diagrams Collaboration diagrams

Sequence Diagram ATM Customer ATM CardATM Control Customer Interface Bank Server Card Inserted Get Pin PIN Prompt PIN Input Card Request Card Data PIN Entered Validate PIN

Order Item: Flow of Events Trigger: The Customer selects an item 1. A new Order is created 2. The selected item is addded to the Order 3. The Customer selects “check out” 4. A charge is made to the Customer’s Credit Card 5. Approval for the Credit Card Charge is requested from the Credit Card Company 6. The Customer is notified when the Credit Card Charge has been approved 7. Once the Credit Card Charge has been approved, then Shipment is approved …

Testing Customer Requirements Functional Requirements Design Implementation Unit Test System Test Acceptance Test Lecture 10 Lecture 11 Lectures 6/8/9 Most of the rest! Lecture 18

The Drive for Software Quality Low Defect Rates High User Satisfaction

But Testing is:-  Time consuming writing test cases writing test cases executing test cases executing test cases  Error prone

But Testing is:-  Time consuming writing test cases writing test cases executing test cases executing test cases  Error prone

Errors, defects, failures ErrorDefectFailure Introduces aMay result in one or more

Effective and Efficient Testing  To test effectively, you must use a strategy that uncovers as many defects as possible.  To test efficiently, you must find the largest possible number of defects using the fewest possible tests Testing is like detective work: Testing is like detective work: The tester must try to understand how programmers and designers think, so as to better find defects.The tester must try to understand how programmers and designers think, so as to better find defects. The tester must not leave anything uncovered, and must be suspicious of everything.The tester must not leave anything uncovered, and must be suspicious of everything. It does not pay to take an excessive amount of time; tester has to be efficient.It does not pay to take an excessive amount of time; tester has to be efficient.

Inspections  An inspection is an activity in which one or more people systematically Examine source code or documentation, looking for defects. Examine source code or documentation, looking for defects. Normally, inspection involves a meeting... Normally, inspection involves a meeting... Although participants can also inspect alone at their desks.Although participants can also inspect alone at their desks.

Black-box testing  Testers provide the system with inputs and observe the outputs They can see none of: They can see none of: The source codeThe source code The internal dataThe internal data Any of the design documentation describing the system’s internalsAny of the design documentation describing the system’s internals But they can see: But they can see: Requirements documents and/or specificationsRequirements documents and/or specifications

Glass-box testing  Also called ‘white-box’ or ‘structural’ testing  Testers have access to the system design They can They can Examine the design documentsExamine the design documents View the codeView the code Observe at run time the steps taken by algorithms and their internal dataObserve at run time the steps taken by algorithms and their internal data Individual programmers often informally employ glass-box testing to verify their own code Individual programmers often informally employ glass-box testing to verify their own code But they are testing what is implemented, and not necessarily what is required!

Recommended Practice  Use Black Box techniques for initial test design Check all requirements are covered Check all requirements are covered  Analyse the code or design to see to what extent the logical structure of the software under test is covered  Intelligently add in test cases to increase the structural coverage up to some agreed level

Defects in Timing and Co- ordination  Deadlock and livelock Testing strategies: Testing strategies: Deadlocks and livelocks occur due to unusual combinations of conditions that are hard to anticipate or reproduce.Deadlocks and livelocks occur due to unusual combinations of conditions that are hard to anticipate or reproduce. It is often most effective to use inspection to detect such defects, rather than testing alone.It is often most effective to use inspection to detect such defects, rather than testing alone. However, when testing:However, when testing: Vary the time consumption of different threads. Vary the time consumption of different threads. Run a large number of threads concurrently. Run a large number of threads concurrently. Deliberately deny resources to one or more threads. Deliberately deny resources to one or more threads.

Example of deadlock B:ThreadA:Thread waiting to lock O: waiting to lockP: lock P: O: lock

Example of critical race A:ThreadData:B:Thread get set a) Normal A:ThreadData:B:Thread get set b) Abnormal due to delay in thread A

Software Lifecycle Customer Requirements Functional Requirements Design Implementation Unit Test System Test Acceptance Test