Status-Oriented Telephone Service Specification: An Exercise in LOTOS Style

Bernard Stepien and Luigi Logrippo
Telecommunications Software Engineering Research Group
University of Ottawa
Department of Computer Science
Ottawa, Ont. Canada K1S 9B4
email: bernard{luigi}@csi.uottawa.ca

Motivation

The authors and other members of their group have already written some papers
and research re ports on specifying telephone call processing in LOTOS.  Two
such papers, where two differently organized specifications of the Plain Old
Telephone System service (POTS) were presented, were [FLS 90][FLS 91]. The
specification in the second paper was mainly in the constraint-oriented style,
while the one in the first was in a combination of constraint-oriented and
state-oriented style. We are now presenting yet another style of specifying
telephone systems, because we feel that this new style has some definite
advantages over the ones used in previous papers. In particular:

1. In the previous specifications, the identification of busy telephone numbers
   was done by includ ing such numbers in a set; in this specification, busy
   telephones directly inform others of their state  by offering the busy
   action only.

2. While in previous specifications a disconnection caused all the components
   of the connection (the two stations and the controller) to end up in a
   deadlock and thus to become "dead" and non- reusable, in this specification
   these components go back to initial state and are reusable in an other
   connection. 

3. Resource - oriented style:  specification modules more closely model
   software entities such as processes that control the individual phones and
   the individual connections.  Such processes can be dynamically created for
   an unlimited number of phones and connections.

4. In previous specifications, there was no mechanism for installing new
   stations.  We have such a mechanism here. 

Structurally, the main difference between this specification and previous ones are:

1. ACT ONE has almost disappeared from the specification (we are still using it
   to maintain the set of "installed" phones, a feature not present in previous
   specifications).

2. Control is realized by having processes exchange status information:
   therefore, we identify our specification style as a variation of the
   resource-oriented style, which we call status-oriented style.

This style is appealing, because it mimicks the way "black boxes" exchange
status information in a physical system. Also, at every step of simulation a
small number only of actions can be derived, in other words symbolic behavior
trees are narrow.  This is in contrast with the constraint-oriented style,
where symbolic behavior trees tend to include many unfeasible paths. As a
consequence, simulation, model-checking, and generation of test cases are
expected to be all easier.