paul@frigga.pttrnl.nl (Paul Tilanus) (04/02/91)
Stepwise from an informal text to LOTOS
=======================================
P.A.J. Tilanus
PTT--Research
The problem
-----------
Once someone learnt LOTOS (the language constructs), learnt about styles
(Monolithic or Constraint, Resource, Object or State oriented), did some
exercises on relatively small examples, and saw a number of large examples,
there comes a moment when the whole lot has to be applied on some new system.
All examples, well-presented showed the result of the specification process,
but did not show the sweat, the various attempts, and the struggle to find the
right way to specify the various parts of the system. All the `natural'
choices (the right language constructs in the right style) for each of the
subsystems in the examples are not that natural in the new system to be
specified. The next thing the fresh specifier does is looking for literature
on a good method for specification development (in LOTOS), but what is found
are books of at least 250 pages with more well-presented examples.
In the past few years a number of people in a situation as described above
came to me and asked for advice. Instead of giving advice I started to
specify the system with them, and they found out how to approach the problem,
when to try (and backtrack when the attempt is not successful), and when to
stay with a decision made earlier.
I found out that, given the knowledge of the language and the various common
styles in LOTOS, the method I use can be described in a small book. However,
writing that book is useless: explaining the steps taken means showing a
series of examples which will be well-presented, and a reader will have the
same problems after reading that book as he had before reading it. It is like
reading a book (manual) on a rather complex software packet: after reading it
you need the reference card to find out what commands can be given at what
point to get to the desired result.
A solution
----------
What could be needed by the users of a method for the production of LOTOS
specifications is a reference card for that method. A first attempt for such
a reference card for my personal method resulted in a document of two pages A4
with a series of steps to be taken. Those two pages were distributed within
the institute where I work, and I received a number of positive reactions,
together with suggestions for modifications (generalisations, refinements,
...).
- 1 -
Encouraged by these results I asked for the personal method of some real
experts, which led to conclusion that all experts forget to write down
important steps.
More personal methods required
------------------------------
Depending on the kind of system an expert gained his/her expertise from, some
steps are obvious. E.g., a believe that `data takes care of itself; don't
worry about data' leads to ignoring development of data in the early phases of
the specification development. Obvious steps are `forgotten' in the personal
method of an expert. In order to make a rather general reference card that
can be applied for many kinds of systems, several specification experts with
experience in specifying all kinds of systems should contribute.
I would like to receive as many reference cards for personal methods as
possible. I will merge these into a general reference card, trying to keep
that general reference card as concise as possible. The result will be
distributed to all who contributed to it.
As an example you find my personal method at the end of this document. You
can give it a quick look, but don't study it in detail before writing down
your personal method (to avoid `pollution').
Send your personal method as soon as posible, together with the information
asked in the next section, to
Paul A.J. Tilanus
PTT--Research e-mail: PA\_Tilanus@pttrnl.nl
P.O.Box 421 telefax: +31 70 332 64 77
2260 AK Leidschendam
The Netherlands
- 2 -
Additional information
----------------------
In order to determine the background of the persons contributing their
personal method I would be pleased if you could give me the following
information in addition to your personal method. Part of the information is
to let you share the resulting `general reference card for LOTOS development'.
Name:
E-mail address
Institute/company
Address
Country
---
LOTOS specification you wrote/contributed to (1)
Application area/name of the specification
---
LOTOS specification you wrote/contributed to
Application area/name of the specification
---
LOTOS specification you wrote/contributed to
Application area/name of the specification
---
.
.
.
--------------------
(1) Indicate size (approximately) with/without comments, and the number of
persons that contributed to it.
- 3 -
My personal method
------------------
1. Give the system a name and determine what is _inside_ and what is
_outside_ the system.
2. Give examples of interactions between the system and its environment.
Message Sequence Charts (arrow diagrams) and/or dataflow diagrams are an
appropriate means to achieve this. (2)
3. Identify the communication partners of the system in the environment.
Multiple communication partners of the same type should be treated as
one, using a plural noun to identify them. (3)
4. Identify the interaction points (gates) of your system with the
environment. Usually one per communication partner will do. It should be
possible to allocate each of the examples of step 2 to one of the gates.
5. Identify {\em all} interactions for each gate; do not worry about data
(yet).
6. Identify the data to be transfered in each interaction --- these will be
parameters of the LOTOS events.
(a) Identify for each parameter the `direction of flow' (4), and
(b) consider grouping of parameters with the same direction of flow into
larger structures so as to reduce complexity of events.
(c) For each communication partner in the environment that is a collection
of communication partners of the same type, there should be one
parameter that serves as an identification of the members of the
collection.
7. Find out in which of the following cases you are. The earlier you find
a match in the following list, the better.
(a) If there is a `natural' division of events in phases, then identify a
process with each phase. E.g. connection phase, data phase,
disconnection phase.
* The natural composition between the phase processes is the
enabling (and sometimes disabling).
* Identify the data transfered bertween the phases.
* For each phase process start at step 4 considering the phase process
as the system to be specified.
(b) If there is a `natural' division of events over roles the system can
play, then identify a process with each role. E.g.\ master role
(initiator), slave role (responder).
* The natural composition of the role processes is the choice.
* Check that the initial events of the roles are distinct (otherwise
you might select, by accident, the wrong role).
* For each role process start at step 7 considering the role process as
the system to be specified.
(c) If there is a `main flow of data', influenced by other interactions
(regulating events), then follow the constraint oriented approach, and
identify the `main stream process' and the constraint (regulating)
processes.
* The natural composition uses the parallel operators without hiding of
gates.
* Start at step 7 for the `main stream process' considering this
process as the constraintless system to be specified. In general
this is reflected in many `?'s, a limited number of `!'s and hardly
any premiss in the events of this process.
- 4 -
* Order the constraint (regulating) processes by the number of gates,
small numbers first. Try to decompose constraint processes with more
than two gates.
* For each listed constraint process, start at step 7 and consider the
constraint as the system to be specified.
The specification of each of the constraints should be followed by a
check that the constraint does not block (deadlock with) the main
stream process and the constraints specified before.
(d) If there is a `natural' division of the system into components that
manage recources, then follow the resource oriented style.
* Go through step 3 to 6 for each of the components, considering the
component processes as the system to be specified and the other
components and the system environment as the communication partners.
* The natural composition uses the parallel opreators with hiding of
the communication between the components.
* For each of the components start at start at step 7, considering the
component as the system to be specified.
(e) If you think the system `naturally' divides into `states', then think
harder: it's almost certain that case 7a applies. Providing a
state-nextstate diagram can be helpful (and is almost always a good
thing in the documentation).
(f) You are in trouble! Contact a real expert --- not only for a
solution, but also for the way (s)he gets to that solution.
--------------------
(2) Note that only examples are needed to guide the following steps; there is
not yet a need to give an exhaustive list of interactions.
(3) E.g. all telephones in the environment of an exchange are treated as a
single communication partner `telephones'.
(4) `Value generation' is a valid `direction of flow'.
- 5 -