Some of the work reported here is being undertaken by the FORMOSA project -
a collaboration between British Telecom (BT) and the University of Stirling,
described in 
issue 0. Andreas Vogel (University of Montreal,
vogel@iro.umontreal.ca) also maintains an email exploder for discussion
related to architectural semantics for ODP.
The aims of the FORMOSA project are briefly to accelerate the progress of international standards for Open Distributed Processing (ODP) by interpreting the concepts and structuring rules of the Reference Model for ODP (RM-ODP) in Formal Descriptive Techniques (FDTs). The FDTs of primary concern in the FORMOSA project are LOTOS and Z.
The RM-ODP is an architecture through which distribution, interworking and portability can be achieved between non-heterogeneous, multi-vendor systems. It is based upon precise concepts derived from current distributed processing developments and, as far as possible, on the use of FDTs to specify the architecture. The RM-ODP uses an object based approach, where an object may be regarded as an identifiable encapsulated aspect of some real world entity. This allows for the easier development of systems where inessential details of objects may be ignored.
To reduce the inherent complexity of ODP systems, the RM-ODP identifies five viewpoints which are useful when considering an ODP system. These are:
Each of these viewpoints represents a different abstraction of the same original system. Using a viewpoint results in a consideration of the system focusing on a particular concern. Different viewpoints address different concerns, however, there is likely to be some common ground between them. Each of these viewpoints has its own associated language through which the concepts and entities identified from the viewpoint may be dealt with, along with rules for their structuring.
The advantage of using formal methods to interpret the concepts and structuring rules of the RM-ODP are that a precise and mathematically sound collection of concepts and their associated structuring rules can be generated. These may then be used unambiguously by ODP standards writers.
At the time of writing, the architectural semantics work is at a crucial transformation period. Initially the more basic concepts and structuring rules of Part 2 of the RM-ODP were interpreted. This work consisted of interpreting, in different FDTs, the most elementary of concepts. Some examples which are action, interaction point and object. However, it was noted that in order to be really useful, the architectural semantics work should deal with the more prescriptive concepts contained in Part 3 of the RM-ODP. This is necessary as the relation between Part 2 and Part 3 of the RM-ODP may be seen as a specialised relation. Thus a given Part 3 concept may be seen as a specialisation of a more basic Part 2 concept. For example, one concept contained in Part 3 which may be considered a specialisation of Part 2 concept is that of a stream interface, which is a specialisation of the Part 2 concept of interface. The problem with only considering the Part 2 interpretation in the FDTs, is that often there is no interpretation of the Part 3 specialisation of the concept. An example of this is an interface in LOTOS (Part 2) may be interpreted, but a stream interface (Part 3) may not be directly interpreted in LOTOS, although an abstract representation of this concept may be achieved.
Thus the relationship between the Part 2, Part 3 and their interpretation in FDTs may be shown as:
is specialised as
Part2 ------------------> Part3
concept concept
is || || is
interpreted || || interpreted
by || || by
\/ is specialised as \/
FDT -------------------> FDT
interpretation interpretation
Ideally the user of the architectural semantics work should be able to specify a system from the different viewpoints (languages). Thus the bottom right corner is the ideal.
The current architectural semantics work is on the left hand side of this rectangle, however. As shown in the above example of interfaces in LOTOS the bottom line may not always exist. Where this is the case it should be noted and conclusions drawn.
The next question that arises from this is which of the viewpoint languages
is to be dealt with. Ideally all of them, but realistically only the
computational, information and engineering languages will be addressed in
the time allowed
. Thus there should be a rectangle as above for these viewpoint
languages and for each of the FDTs. It is expected that the FDTs LOTOS, Z
and SDL will be used to interpret the viewpoint languages. Other FDTs
(Estelle, RAISE etc) may also be used if member bodies are prepared to make
contributions (and the FDT is very well known or standardised). If no
contributions are received then it is likely that other FDTs will be rather
left behind in the ODP architectural semantics work.
It has been agreed that to try to overcome the time problem, the use of Email discussions will be made. Indeed at the time of writing, the architectural semantics discussion group is actively interpreting much of Part 3 of the RM-ODP. Initially work is being focussed on the computational language, as this appears to be most stable. An architectural semantics for the computational language in SDL'92 has recently been completed. Proposals for the different possible approaches of the LOTOS computational language are also actively being discussed.
For more information regarding the current state of the architectural semantics work and access to the discussion group, please contact:
