Analysis

Conceptual model

Sequence diagrams

(chapter 13)

Use case

• contains typical course of events
• describes how actors interact with system
• actors are external to system
• system acts as a "black box"

When actors interact with system, they generate events to a system. These events require an operation by the system in response.

Sequence diagrams are used to illustrate the system operations and the actors who initiate them.

They are sequence diagrams - the events are in (time) order.
And they are tied to a use case.

Actor Action	System Response
Use case begins when a Customer arrives at POST checkout with items to buy.
Cashier records identifier of each item. If several of same item, Cashier can enter quantity.	Determines item price and adds item info to transaction. Description and price of current item presented.
On completion of item entry, Cashier tells POST that item entry is complete.	Calculates and presents the sale total.
Cashier tells Customer the total.
Customer gives Cashier at least enough cash.
Cashier records the cash received amount.	Shows change to be given to customer. Generates a receipt.
Cashier deposits cash received and extracts balance. Cashier gives change and receipt to Customer.	Logs the completed sale.
Customer leaves with items purchased.

Systems sequence diagram for BuyItems use case

System events and system operations

system event

external input event generated by an actor

initiates a responding operation by system

system operation

operation the system executes in response to system event

Constructing a systems sequence diagram from a use case

1. Draw a line representing the system as a black box.

2. Identify each actor that directly operates on the system. Draw a line for each such actor.

3. From the use case typical course of events text, identify the system (external) events that each actor generates. They will correspond to an entry in the rhs of the typical use case. Illustrate them on the diagram.

4. Optionally, include the use case text to the left of the diagram.

System operations

UML has a type System for recording system operations

may include parameters

Names

should be expressed as intent rather than physical input medium or widget

start with a verb

aim for highest level of intent

• No: enterAmountTended
• Yes: enterPayment
• Yes:makePayment

Contracts

Contracts describe system behaviour

• what a system does
• not how it does it

(Contracts will be applied to class methods later.)

Contracts are expressed using preconditions and postconditions.

Preconditions and postconditions are assertions.

Assertions

statements which are either true or false

they will be implemented as boolean expressions

Preconditions

assertions about

• state of system

• value of arguments

which are necessary for an operation to take place.

Postconditions

assertions about

• state of system

• (later) return value

which are necessary if an operation has been successful.
That is, if it has done what it is supposed to do.

Contract
Name	enterItem upc : text quantity : integer
Responsibilities	Enter (record) sale of an item and add it to the sale. Display the item description and price.
Cross references	Buy items use case
Notes
Output
Preconditions	UPC is valid; Qty > 0 UPC is known to system
Postconditions	If a new sale, a Sale was created If a new sale, the new Sale was associated with the POST A SaleLineItem was created The SaleLineItem was associated with the Sale SaleLineItem.quantity was set to quantity The SaleLineItem was associated with a ProductSpecification, based on UPC match

Contract
Name	Name of operation + parameters
Responsibilities	Informal description of the responsibilities of the operation.
Cross references	System function reference numbers, use cases.
Notes	Anything helpful (eg suggested algorithm)
Output	Non user interface output, such as messages sent out of system.

Most important are preconditions and postconditions.

Exceptions

If when a pre or post condition is not met there is a bug in the system and an exception should be raised. We will discuss this further later.

Writing contracts

1. Name and parameters from system sequence diagrams.

2. Write Responsibilites section.

3. Postconditions

4. Preconditions

Types of postconditions

• instance creation and deletion
  a Sale was created
• attribute modification
  SaleLineItem.quantity was set to quantity
• associations formed and broken
  SaleLineItem was associated with the Sale

Assertions

• Write as statements, not as instructions.
• You must be able to say "that is true" or "that is false" to them.
• It's a good idea to write them in the past tense.

Testing

(Somerville, chapter 22 + other material)

Verification and Validation. checking process that ensures software conforms to specifications

Validation

Are we building the right product?

Verification

Are we building the product right?

Validation

Are the specifications right?

Verification

Have they been implemented?

The key is the contracts

• Contracts confirm the specifications. They should be readable by domain experts.
• Implementation implements the contracts. Contracts should be testable in the code.

Testing process

Unit testing

A class is tested in isolation

Integration testing

Software components and / or hardware components are combined and tested to evaluate the interaction between them.

Should be incremental.

Leads to sub-system testing. Most common problems are interface problems.

Leads to system testing. Interaction between sub-systems. System must meet functional and non-functional requirements.

• functional: system operations
• non-functional: response time, memory usage

Acceptance testing

Testing with data supplied by customer

Probably by customer.

– – – Aside — — —

Acceptance testing is sometimes called alpha testing. Typically a single customer.

If software being sold on the open market, can use beta testing. Deliver system to a number of potential customers who agree to use it.

See also "The Cathedral and the Bazaar".

White box testing and black box testing

White box testing

Tester knows the code

1. Make up test cases based on execution paths in the code
   cover all statements,
   cover all branches,
   cover all paths.
   Covering all paths very good but there may be many paths.

2. Inspections and walkthroughs.
   Manual or computer assisted (CASE tools)
   Can be efficient at finding bugs early.
   Someone other than author should be involved.

Black box testing

Relies solely on specifications.

Generate data

• Randomly: Weak, but easy.
• Partition testing: Partition input (or output) to reduce number of cases.
• Focus on boundary conditions.

Do white box testing early

Tester and writer distinct.

• A tests B's code
• B tests C's code
• C tests D's code
• D tests A's code

Everyone has an understudy

• helps communication;
• reduces risk;
• helps management.

Black box testing

Simplest way is to use a debugger or lots of printlns.

• But doesn't scale up;
• requires too much intervention and interpretation;
• people don't redo after changes.

Computer assisted is better: Use a test framework.

black box (regression) testing

Each component should be tested.

Test data derived from contracts.

Test data constructed by someone other than the writer of the component.

Component should satisfy test data after writing
and after every change.

So...

• testing should be computer assisted and as automated as possible.

A test consists of an

Frameworks

• Collection of concrete and abstract classes and the interface between them.

• Semi-finished software architecture.

• A template

• When completed they often become subsystems.

• They are completed by writing concrete descendants of the abstract classes.

• eg. framework for cgi scripts (web applications).

JUnit

Test framework for Java written by Kent Beck and Erich Gamma.

ftp://www.armaties.com/TestingFramework/JUnit/

1. Simple test case

   public void testSimpleAdd {
       Dollars d10 = new Dollars(10);
       Dollars d12 = new Dollars(12);
       Dollars expected = new Dollars(22);
       Dollars result = d10.add(d12);
       assert(expected.equals(result);
   }
   // testSimpleAdd
   

2. Fixtures

   Tests need to be run against a set of known objects.
   This set of objects is called a fixture.
   (Spend more time writing code to set up fixtures than in actual testing.)

3. Test case

   Run a test case against a fixture.

4. Suite

   Run several test cases at once.

5. Test runner

   Allows tester to specify which suites to run.