Object-OrientedObject-OrientedSoftware EngineeringSoftware Engineering

RevisionRevision

Paul J KrausePaul J Krause

Software LifecycleSoftware Lifecycle

Customer Requirements

Functional Requirements

Design

Implementation

Unit Test

System Test

Acceptance TestLecture 10

Lecture 11

Lectures 6/8/9

Most of the rest!

Lecture 18

Customer RequirementsCustomer Requirements

Customer Requirements

Functional Requirements

Design

Implementation

Unit Test

System Test

Acceptance TestLecture 10

Lecture 11

Lectures 6/8/9

Most of the rest!

Lecture 18

Why Requirements?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.…”

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

0%

5%

10%

15%

20%

Schedule Effort

Faster FirmsSlower Firms

Resources spent on Customer Requirements:

Tom on ‘Requirement’Tom on ‘Requirement’ Requirement: Requirement: Concept *026 November 8, 2001 22:16Concept *026 November 8, 2001 22:16

A requirement is a stakeholder-desired Target or A requirement is a stakeholder-desired Target or Constraint.Constraint.

Notes: Notes: 1. The constraints can apply to an engineering process, a design or an 1. The constraints can apply to an engineering process, a design or an

operational system.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 3. Requirements give information to the designer about the necessary nature

of their design. of their design. 4. Consequently the design, specification or implementation, can be judged 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 {Spec QC, review, test or in operation} in terms of how well it satisfies those requirements.requirements.

INTRO

Requirement Specification.Requirement Specification. Requirement Specification. Concept *508. November 8, 2001 1604Requirement Specification. Concept *508. November 8, 2001 1604

A requirement specification is the A requirement specification is the readable expression of a requirement readable expression of a requirement and any requirement background.and any requirement background.

Related Concepts: Related Concepts: requirement *026 the future state or constraintrequirement *026 the future state or constraint specification *137 the readable specification *137 the readable artifactartifact background *507 additional information about the requirementbackground *507 additional information about the requirement

Stakeholders: requirements Stakeholders: requirements sourcessources

‘‘Stakeholders’ are:Stakeholders’ are: Any person, group or thing whichAny 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 characteristicssystem performance characteristics system lifecycle constraintssystem lifecycle constraints

Stakeholders determine requirements!Stakeholders determine requirements! Systems engineers determine which requirements the Systems engineers determine which requirements the

stakeholders needstakeholders need• Even if the stakeholders are not currently conscious of those Even if the stakeholders are not currently conscious of those

needs!needs!

Non-functional RequirementsNon-functional Requirements

Functional RequirementsFunctional Requirements What the system should do - the services it What the system should do - the services it

should provideshould provide Non-Functional RequirementsNon-Functional Requirements

The constraints that must be adhered to The constraints that must be adhered to during developmentduring development

Performance, memory, reuse, usability, …Performance, memory, reuse, usability, … See Tom Gilb, and our Lecture 10See Tom Gilb, and our Lecture 10

Functional RequirementsFunctional Requirements

Customer Requirements

Functional Requirements

Design

Implementation

Unit Test

System Test

Acceptance TestLecture 10

Lecture 11

Lectures 6/8/9

Most of the rest!

Lecture 18

What are Actors and Use What are Actors and Use Cases?Cases?

Actors - users of the systemActors - users of the system external entities (people or other systems) external entities (people or other systems)

who interact with the system to achieve a who interact with the system to achieve a desired goal.desired goal.

Use Cases - what happens when Actors Use Cases - what happens when Actors interact with the systeminteract with the system by recording all the ways the system is used by recording all the ways the system is used

(“cases of use”) we accumulate all the goals (“cases of use”) we accumulate all the goals or requirements of the system.or requirements of the system.

Identifying ActorsIdentifying Actors

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

Examples of ActorsExamples of Actors

Customer

Clerk

ShippingCompany

Supplier

Use Case DiagramUse Case Diagram

Customer

Clerk ShippingCompany

Supplier

PlaceOrder

Get OrderStatus

CalculatePostage

SupplyProduct

DeliverPackage

Use Case: Place OrderUse Case: Place Order

Customer

PlaceOrder

Place Order: Flow of EventsPlace Order: Flow of Events

TriggerTrigger: The Customer selects a Product category: The Customer selects a Product category

1.1. The Customer browses the chosen Product category pageThe Customer browses the chosen Product category page

2.2. The Customer selects a specific Product to purchaseThe Customer selects a specific Product to purchase

3.3. The Customer adds the Product to their Shopping CartThe Customer adds the Product to their Shopping Cart

4.4. The Customer may repeat events 1, 2 and 3 to add additional The Customer may repeat events 1, 2 and 3 to add additional items to their Shopping Cartitems to their Shopping Cart

5.5. When ready, the Customer requests that the Order be commited When ready, the Customer requests that the Order be commited toto

6.6. The Credit Company is notified to authorise the Customer’s credit The Credit Company is notified to authorise the Customer’s credit ratingrating

7.7. If the credit rating is positive, the Order will be placedIf the credit rating is positive, the Order will be placed

Nouns as Candidate ClassesNouns as Candidate Classes

TriggerTrigger: The : The CustomerCustomer selects a selects a ProductProduct category category

1.1. The The CustomerCustomer browses the chosen browses the chosen ProductProduct category page category page

2.2. The The CustomerCustomer selects a specific selects a specific ProductProduct to purchase to purchase

3.3. The The CustomerCustomer adds the adds the ProductProduct to their to their Shopping CartShopping Cart

4.4. The The CustomerCustomer may repeat events 1, 2 and 3 to add additional may repeat events 1, 2 and 3 to add additional items to their items to their Shopping CartShopping Cart

5.5. When ready, the When ready, the CustomerCustomer requests that the requests that the OrderOrder be commited be commited toto

6.6. The The Credit CompanyCredit Company is notified to authorise the is notified to authorise the CustomerCustomer’s credit ’s credit ratingrating

7.7. If the credit rating is positive, the If the credit rating is positive, the OrderOrder will be placed will be placed

DesignDesign

Customer Requirements

Functional Requirements

Design

Implementation

Unit Test

System Test

Acceptance TestLecture 10

Lecture 11

Lectures 6/8/9

Most of the rest!

Lecture 18

Identifying classesIdentifying classes

Think about general properties of the Think about general properties of the domain in which you are workingdomain in which you are working

Identify the nounsIdentify the nouns These form candidate classesThese form candidate classes

A A PublisherPublisher produces and markets a produces and markets a BookBook

A A CustomerCustomer purchases a purchases a BookBook

An An AuthorAuthor writes a writes a BookBook

Publisher

nameaddresswebSite

Book

bookNumbertitleunitPrice

Customer

nameemailshippingAddress

Author

nameaddresswebSite

Publisher

nameaddresswebSite

Book

bookNumbertitleunitPrice

Customer

nameemailshippingAdd

Author

nameaddresswebSite

R1 R3

R2

is producedand

marketedby

producesand

markets

purchases is sold to

wrote

was written by

Publisher

nameaddresswebSite

Book

bookNumbertitleunitPrice

Customer

nameemailshippingAdd

Author

nameaddresswebSite

R1 R3

R2

is producedand

marketedby

producesand

markets

purchases is sold to

wrote

was written by

1 0..* 1..* 0..*

1..*

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

nameaddresswebSite

BookProduct

bookNumbertitleunitPrice

Customer

nameemailshippingAdd

Author

nameaddresswebSite

R1 R3

R2

is producedand

marketedby

producesand

markets

is apurchase

of

is sold as

wrote

was written by

1 0..* 1..* 0..*

1..*

1..*

Order

quantitysalePricedate

makes 1..*

is made by 1

Interaction DiagramsInteraction Diagrams

These are used to model the dynamic These are used to model the dynamic aspects of a software systemaspects of a software system

Typically, a class diagram and Use Cases Typically, a class diagram and Use Cases are used as inputs to the development of are used as inputs to the development of interaction diagramsinteraction diagrams

In UML there are two kinds of interaction In UML there are two kinds of interaction diagramdiagram Sequence diagramsSequence diagrams Collaboration diagramsCollaboration diagrams

Sequence DiagramSequence Diagram

ATMCustomer

ATM Card ATM ControlCustomerInterface

BankServer

Card Inserted

Get Pin

PIN Prompt

PIN Input

Card Request

Card Data

PIN Entered

Validate PIN

Order Item: Flow of EventsOrder Item: Flow of EventsTriggerTrigger: The Customer selects an item: The Customer selects an item

1.1. A new Order is createdA new Order is created

2.2. The selected item is addded to the OrderThe selected item is addded to the Order

3.3. The Customer selects “check out”The Customer selects “check out”

4.4. A charge is made to the Customer’s Credit CardA charge is made to the Customer’s Credit Card

5.5. Approval for the Credit Card Charge is requested from the Credit Approval for the Credit Card Charge is requested from the Credit Card CompanyCard Company

6.6. The Customer is notified when the Credit Card Charge has been The Customer is notified when the Credit Card Charge has been approvedapproved

7.7. Once the Credit Card Charge has been approved, then Shipment Once the Credit Card Charge has been approved, then Shipment is approved …is approved …

: Customer

: Order

: Credit Card Charge

: Shipment

: Credit Card Company

: Shipping Clerk

1: newOrder

2: addSelection

3: checkOut4: makeCharge

5: requestChargeApproval

6: chargeProcessed7: paymentApproved

9: requestShipment10: packShipment

11: packed

8: chargeApproved

TestingTesting

Customer Requirements

Functional Requirements

Design

Implementation

Unit Test

System Test

Acceptance TestLecture 10

Lecture 11

Lectures 6/8/9

Most of the rest!

Lecture 18

The Drive for Software QualityThe Drive for Software Quality

Low Defect Rates

High UserSatisfaction

But Testing is:-But Testing is:-

Time consumingTime consuming writing test caseswriting test cases executing test casesexecuting test cases

Error proneError prone

But Testing is:-But Testing is:-

Time consumingTime consuming writing test caseswriting test cases executing test casesexecuting test cases

Error proneError prone

Errors, defects, failuresErrors, defects, failures

ErrorError DefectDefect FailureFailureIntroduces a May result in one or more

Effective and Efficient TestingEffective and Efficient Testing

To test To test effectivelyeffectively, you must use a strategy that , you must use a strategy that uncovers as many defects as possible. uncovers as many defects as possible.

To test To test efficientlyefficiently, you must find the largest , you must find the largest possible number of defects using the fewest possible number of defects using the fewest possible testspossible tests Testing is like detective workTesting is like detective work::

• The tester must try to understand how programmers and The tester must try to understand how programmers and designers think, so as to better find defectsdesigners think, so as to better find defects..

• The tester must not leave anything uncovered, and must be The tester must not leave anything uncovered, and must be suspicious of everythingsuspicious of everything..

• It does not pay to take an excessive amount of time; tester It does not pay to take an excessive amount of time; tester has to be has to be efficientefficient..

InspectionsInspections

An inspection is an activity in which one or An inspection is an activity in which one or more people systematicallymore people systematically Examine source code or documentation, Examine source code or documentation,

looking for defects. looking for defects. Normally, inspection involves a meeting...Normally, inspection involves a meeting...

• Although participants can also inspect alone at Although participants can also inspect alone at their desks.their desks.

Black-box testingBlack-box testing

Testers provide the system with inputs and Testers provide the system with inputs and observe the outputsobserve 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 Any of the design documentation describing the

system’s internalssystem’s internals But they But they cancan see: see:

• Requirements documents and/or specificationsRequirements documents and/or specifications

Glass-box testingGlass-box testing

Also called ‘white-box’ or ‘structural’ testingAlso called ‘white-box’ or ‘structural’ testing

Testers have access to the system design Testers have access to the system design They can They can

• Examine the design documents Examine the design documents

• View the codeView the code

• Observe at run time the steps taken by algorithms and their internal Observe at run time the steps taken by algorithms and their internal datadata

Individual programmers often informally employ glass-box Individual programmers often informally employ glass-box testing to verify their own codetesting to verify their own code

But they are testing what is implemented,and not necessarily what is required!

Recommended PracticeRecommended Practice

Use Black Box techniques for initial test Use Black Box techniques for initial test designdesign Check all requirements are coveredCheck all requirements are covered

Analyse the code or design to see to what Analyse the code or design to see to what extent the logical structure of the software extent the logical structure of the software under test is coveredunder test is covered

Intelligently add in test cases to increase Intelligently add in test cases to increase the structural coverage up to some agreed the structural coverage up to some agreed level level

Defects in Timing and Co-Defects in Timing and Co-ordinationordination

Deadlock and livelockDeadlock and livelock Testing strategiesTesting strategies: :

• Deadlocks and livelocks occur due to unusual Deadlocks and livelocks occur due to unusual combinations of conditions that are hard to combinations of conditions that are hard to anticipate or reproduce. anticipate or reproduce.

• It is often most effective to use It is often most effective to use inspectioninspection to detect to detect such defects, rather than testing alone.such defects, rather than testing alone.

• However, when testing:However, when testing: Vary the time consumption of different threadsVary 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 threadsDeliberately deny resources to one or more threads..

Example of deadlockExample of deadlock

B:ThreadA:Thread

waitingto lock O:

waitingto lock P:

lock

P:O:

lock

Example of critical raceExample of critical race

A:Thread Data: B:Thread

get

set

a) Normal

A:Thread Data: B:Thread

get

set

b) Abnormal due to delay in thread A

Software LifecycleSoftware Lifecycle

Customer Requirements

Functional Requirements

Design

Implementation

Unit Test

System Test

Acceptance Test