API for a Supermarket Controller: Development Process
Document Number: E01
Date of Issue: 4 October 2004
Author: John B. Wordsworth
J.B.Wordsworth@ex.ac.uk
Copyright: © J. B. Wordsworth 2004
Preface
This document defines a process for developing software
in a style similar to that taught on COM2404 Design and Method.
It is intended as teaching material for COM3403 Information Systems Design.
- Overview of the process
- Analysis
- Specification
- Design
- Test planning
- Implementation
- Testing
The process defined below is used to produce application programming interfaces (APIs) for various kinds of businesses.
The interfaces are implemented in Java.
It is a modified waterfall process with the following activities:
- Analysis examines the business area for which the API is required.
It establishes the conceptual model of the business area,
and the kinds of interaction that have to be supported.
It produces a conceptual model and specifications of use cases that interact with it.
- Specification produces a specification of a back end interface that can be used as an API for programming
applications in the selected business area.
- Design defines Java classes that can be used to implement the back end.
- Test planning defines the tests that are to be used
to test each class when it has been implemented.
- Implementation produces Java code for the classes.
- Testing executes the planned test on the Java code
to make sure it meets its specification.
The following diagram illustrates the activites and their dependence on on another.
The following diagrams illustrate the documents produced and their relationships to the activites.
The process description describes each stage under the following headings:
- Entry criteria are the conditions that must be satisfied for the stage to beentered.
These are in terms of the availability of certain documents,
or of the certified completion of certain preceding stages.
- Inputs are documents and other information supplied for this stage.
- Method is an indication of suitable, or mandatory, ways of producing the outputs from the inputs.
- Outputs are the documents produced by this stage.
- Exit criteria are the conditions that must be satisfied for this stage to be ended.
These are expressed in terms of the reviews to which the outputs must be subjected.
Entry criteria
Requirements statement signed off by business area experts,
who should include potential customers.
Inputs
- Business area requirements statement
- Additional information about the business area, as required
Method
Use vocabulary analysis to identify actors, objects, classes, relationships, and use cases.
Outputs
- An analysis document containing:
- Description of the business area
- Conceptual model expressed as a UML class diagram
- List of use cases and their intended effects in terms of the conceptual model
Exit criteria
Validation of the analysis document against the requirements statement by an inspection
that includes experts in the business area.
Back to the table of contents.
Entry criteria
Analysis document signed off by inspection moderator.
Inputs
Method
- Identify the basic sets from which the specification will be constructed.
- Define sets, functions, and relations to represent the data in the conceptual model.
- Define the invariants for the data.
- Define an initial situation, and check that it satisfies the invariants.
- Define functions that create each of the types of the conceptual model,
and express their action in terms of the specification model.
- Define functions to modify information in the specification model,
as required by the use cases.
- Define functions to extract information from the specification model,
as required by the use cases.
- For each use case that lists information from an aggregate,
define a "get first" method and a "get next" method.
- Define functions that remove information from the specification model.
- Write pseudoprograms that use the back end functions to implement the use cases.
Outputs
- A specification document containing:
- Precise specification of a back end interface
- Justification of the back end in terms of
the specification of the desired machine behaviour in the analysis document
Exit criteria
Validation of the specification against the analysis document by inspection.
The inspection checklist includes the following points:
- The specification is written in an approved notation.
- The specification is consistent.
- The concepts of the object-oriented model of the analysis document are recognisable in the specification.
- The specification defines a set of back end functions.
- There is a suggested implementation for each use case that uses only the back end functions defined in the specification.
- The suggested implementations of the use cases are correct.
Back to the table of contents.
Entry criteria
Specification document signed off by inspection moderator.
Inputs
Outputs
- A document containing:
- Specification of the Java classes to be implemented
- Specification of the abstraction function that relates the Java classes to the back end specification
- A correctness argument for each function in the back end interface
- Descriptions of the responsibilities and collaborations of the classes
- Sequence diagrams of the principal operations of the back end interface
Exit criteria
Validation of the design document by inspection.
The inspection checklist includes the following points:
- The specifications of the Java classes are in an approved notation.
- The classes specified form a consistent set.
- There is a nominated class that includes the back end interface among its public methods.
- The responsibilities and collaborations of the classes agree with the specifications and the sequence diagrams.
- Every message in a sequence diagram corresponds to a method in the definition of the receiving class.
- The sequence diagrams correctly implement the back end functions according to
the specifications of the operations that they use.
- The abstraction function relates every set of the specification to a Java type.
- The case by case verification of each of the back end functions is correct.
Back to the table of contents.
Entry criteria
Design document signed off by inspection moderator.
Inputs
Method
For the public methods of each class,
devise a scheme of tests that will cause each method to return each return code.
Outputs
- A test plan containing:
- List of test cases for each of the Java classes
- Justification of correct coverage of the test cases
Exit criteria
Validation of the test document by inspection.
The inspection checklist includes the following points:
- The test are organised by Java class.
- For each class:
- The tests exercise all the constructors.
- The tests exercise all the return codes of all the methods.
- The expected output of each test is correct acording to
the specification in the design document of the method being tested.
Back to the table of contents.
Entry criteria
Design document signed off by inspection moderator.
Inputs
Outputs
- The Java code of the classes
Exit criteria
Validation of the implementation document by inspection.
The inspection checklist includes the following points:
- The Java code is written in accordance with local style guidelines.
- For each class defined in the design document:
- The java code for the attributes agrees with the definition.
- The signature of each method agrees with the definition.
- The code of each method implements the specification of that method in the design document.
- The Java code for the methods that provide the back end interface agrees with
the sequence diagrams for those functions.
Back to the table of contents.
Entry criteria
Design document signed off by inspection moderator.
Test plan signed off by inspection moderator
Inputs
Method
Execute the test cases,
starting with the classes at the end of the reference tree.
Refer each failing test case to the author of the code.
Repeat until all the tests succeed.
Outputs
- A document containing a log of all the tests,
showing them to have completed successfully
Exit criteria
All tests successful.
Back to the table of contents.
Document history
4 October 2004
First issued.