Interface specificationl

Almost all software systems must operate with existing systems that have already
been implemented and installed in an environment. If the new system and the existing
systems must work together, the: interfaces of existing systems have to be precisely
specified. These specifications should be defined early in the process and
included (perhaps as an appendix) in the requireme:nts document.
There are three types of interface: that may have to be defined:
1. Procedural interfaces where existing programs or sub-systems offer a range of
services that are accessed by calling interface procedures. These interfaces are
sometimes called Application Programming Interfaces (APls).
2. Data structures that are passed from one sub-system to another. Graphical data
models are the best notations for this type of description.
If necessary, program descriptions in Java or C++ can be generated automatically
from these descriptions.
3. Repr,esentations ofdata (such as the ordering of bits) that have been established
for an existing sub-system. These interfaces are most common in embedded,
real-time system. Some progranuning languages such as Ada (although not Java)
support this level of specification. However, th,e best way to describe these is
probably to use a diagram of the structure with annotations explaining the function
of each group of bits.
Fonna notations, discussed in Chapter 10, allow interfaces to be defined in an
unambiguous way, but their specialised nature means that they are not understandable
without special training. They are rarely used in practice for interface specification
although, in my view, the:y are ideally suited for this purpose. A
programming language such as Java can be used to describe the syntax of the interface.
However, this has to be supplemented by further description explaining the
semantics of each of the defined operations.

In this case, the interface is the procedural interface offered by a print server. This
manages a queue of requests to print files on diffen~nt printers. Users may examine
the queue associated with a print1er and may remove their print jobs from that
queue. They may also switch jobs from one printer to another. The specification in
Figure 6.15 is an abstract model of the print server that does not reveal any interface
details. The functionality of the interface, operations can be defined using structured
natural language or tabular description.