Speci cation and Implementation in ODP Peter F. Linington1 and William F. Frank2 1
University of Kent, Canterbury, Kent, CT2 7NF, UK, 2
[email protected]
Community Integration Technologies, USA,
[email protected]
ODP speci cations are normally produced as one step in the process of planning and implementing real systems, but the detailed sequence of events di ers depending on the methodology and intended scope of the speci cation. This can lead to divergences of opinion about how speci cations are to be interpreted. This paper reviews some of the issues and argues that there need not be a problem if ODP speci cations are interpreted in terms of a exible conformance architecture. It looks at the interplay between speci cation and testing, and reviews the conformance aspects of the RM-ODP to see how it is able to provide the necessary exibility for the creation of long-lived and reusable enterprise speci cations. Abstract.
1 What is ODP? The Reference Model of Open Distributed Processing (RM-ODP) has been created by the International Standardization Organization and the ITU-T to provide a framework for a family of open standards. The aim is to support the creation of object based systems, and to deal with a variety of system aspects from business processes and requirements capture to supporting infrastructure and technology [1] [2]. The full family of standards is still being developed and extended, partly within ISO and partly by adoption of standards from industry consortia, such as the OMG. The aim was to create a framework that would be exible enough to last a long time, helping to manage the evolution of systems, possibly through a number of changes in technology and facilitating reuse of components. Features have been included to simplify the federation of independently developed systems, such as those developed and operated by di erent organizations. One of the main structuring principles used in the framework is to divide the speci cation of a system into a number of distinct viewpoints, each concentrating on a speci c area of concern and linked to each other by the declaration of a set of correspondences. There are ve such viewpoints in the RM-ODP, called the Enterprise, Information, Computational, Engineering and Technology viewpoints [3], [4]. The tools used in system construction will draw on material from all the viewpoints, and will check during maintenance to ensure that changes do not violate any aspect of the speci cation [5].
This paper is motivated, in particular, by the current work within ISO on the Enterprise Language [6]. The Enterprise Language takes a high-level view of the information system and, as such, is likely to have a longer life and a broader range of interpretations than in the other viewpoints.
2 Speci cation and the Real World Because ISO is a standardization body, it is concerned with the publication of speci cations that will be taken up by many organizations and used in the construction of many di erent types of system. However, this is by no means the only way that speci cations can be created and used. They may equally be intended to support the creation of a limited family of systems, or indeed of a single bespoke system. A single system may mix open standards and bespoke speci cation fragments, and so we need to explore a range of interpretations. Because of this wide variety of areas of application, it is necessary to spend some time clarifying some of the basic assumptions underpinning the process. Experience in drafting de nitions for the basic concepts used in describing ODP systems has shown that di erent people use them in di erent ways. They put subtly di erent emphasis on some of the concepts, based on their backgrounds and concerns, and while these can be reconciled once identi ed, they can cause quite deep-seated misunderstandings if not appreciated. The problem is centered on the concept of occurrence | and of the distinction between type and instance. There are two parts to this problem, which we will deal with in turn. These are concerned with: 1. the relationship between terms in the speci cation and entities in the real world, between the speci cation and the things speci ed; and 2. the relationships within a speci cation, or within a family of speci cations, that link di erent speci cation constructs. For example, there will be relationships between type de nitions and speci cation elements, such as objects, whose properties are constrained by those types. There will also be relationships between type de nitions and the use of those types as part of the de nitions of further types.
2.1 Link to the Real World There are, of course, many ways of talking about the real world. In ODP, we concentrate on descriptions that can be tested by experiment | that is, by observation. This places the emphasis on describing behaviour made up of actions, which model things that happen in the real world1 . Objects, modelling realworld entities, emerge in this framework as a descriptive tool for organizing the expression of behaviour. 1
This does not discount, of course, the validity of other kinds of desription in other circumstances. One can abstract away from the testing process and describe state as primitive, or go even further and work entirely in terms of universals. However, for discussion of implementation and testing, observation of actions is key.
However, we still have to decide whether the discovery of patterns of behaviour is the starting point of description, or a descriptive tool. Are we placing emphasis on types and categories of action or on occurrences of actions? The distinction has been the basis of debate between the realist and idealist schools of philosophy for hundreds of years (see, for example, summaries in [7]). The issue is no less relevant for that. To indicate the range of possibilities for the interpretation of technical speci cations, let us pick a few examples: 1. there may be just one implementation, that executes exactly once; the actions in the speci cation can be considered, for most purposes, as describing a number of individual occurrences at speci c times. 2. there may be one implementation, but the behaviour described is prototypical (the speci cation says something like \a customer makes a booking, and a receipt is issued ...", but there is generally more than one customer). The actions in the speci cation are intended to represent pieces of behaviour that will be repeated many times for di erent actual customers. 3. there may be many implementations from the same speci cation. It may be a speci cation to be used by the producer of some shrink-wrapped software intending to ship millions of units, all of which should conform. The speci cation for an EJB session bean might be an example. 4. the speci cation may be written to codify important behaviour of a legacy system that already exists. The creation of the speci cation is an important step in the legacy migration strategy, but in the event of inconsistency, the speci cation is wrong and reality has got it right! Clearly, whatever the ODP standard says should be applicable to any of these; they are all legitimate objectives in creating a speci cation. Indeed, the extent to which the writer of a speci cation should be able to restrict the way the speci cation is used is itself an interesting question. Any speci cation will have a scope, relating to the expected set of implementations that are to arise from it (zero, one or more, freshly built or pre-existing and identi ed as conformant, and so on). But is there any reason, in principle, why I should not be able to take the speci cation of a bespoke system and make a million shrink-wrapped copies that are consistent with it? This raises issues of conformance that we will return to below. The touchstone for the correspondence between speci cation and the thing in the real world being speci ed is observation. A real-world thing corresponds accurately to its speci cation if and only if any observable sequence of events in the real-world (a trace) corresponds to one of the behaviours required in the speci cation. However, the word \corresponds" hides a great deal of complexity. It involves an ill-de ned degree of interpretation and quanti cation, and it is here that the problem lies. Where is the ambiguity? It lies in the scope of any claim of correspondence made, and hence in the conformance model being used. Consider one action within the speci cation | say, for example, the input of a date by a user in some initialization dialogue. The claim about the correct input of the date may be applied to:
{ some particular historical trace, in which a single observation was made at
a certain time and place. This is commonly the case when debugging from a record of execution. The action occurs exactly once, and is associated oneto-one with a single term in the speci cation. { a trace in which a series of observations correspond to a single term in the speci cation as a result of iteration or recursive process de nition within the speci cation. { a trace in which a number of observations results from a number of concurrent processes, created by behaviour within the speci cation, each of which has its own copy of the behaviour leading to the action of interest. { a trace in which a number of observations result from the interleaved activity of a number of di erent systems, each of which individually corresponds to the behaviour speci ed. { an assertion that a particular system will be observed to behave in the speci ed way once. { an assertion that, whenever certain preconditions are set, the system will be observed to behave in a certain way, either in sequence or concurrently. { an assertion that any one of arbitrarily many systems to which the speci cation applies will be observed to behave in a certain way whenever the preconditions apply. Thus we have speci cations that apply to large groups of similar systems (such as all copies a particular model of mobile 'phone). Other speci cations apply to many uses of unique systems (such as all customer-handling on a bespoke telephone enquiry system). A few speci cations apply to one speci c use of one speci c system (such as the system that will control the sequence of events during the opening of the Olympic Games). We also have to distinguish historical observation and claims of conformance for future behaviour. One might expect a general-purpose speci cation technique to be able to cope with all of these di erent cases. It is important to be clear exactly what interpretation of the correspondence between speci cation and real world is intended, because in practice speci cations are neither static nor monolithic. This adds a further potential complication when speci cation fragments are reused or changed during a system's lifetime, and it is here that speci cation in terms of policy becomes involved. One of the reasons for identifying speci c policies, particularly in enterprise speci cations, is to tailor generic speci cations to the speci c, dynamically changing, situations in which they are to be used. Thus a policy is a named place-holder for a piece of behaviour used to parameterize a speci cation in order to facilitate response to later changes in circumstances. The behaviour of systems satisfying the speci cation can be modi ed by changing the policy value, subject to constraints associated with the policy in the original speci cation. If policy is interpreted in this way, the general approach to conformance and interpretation of speci cations can also be seen as parameterized by the speci c policy being applied, and the correspondences with the real world may change if a policy is changed.
2.2 Di erent Parts of a Speci cation In programming languages, a type represents a collection of values, and to say that something, such as a variable or a function \has" a type is to say that it can have any of the possible values in the collection, and no others. When we consider types of objects, the possible values can involve both state and behaviour. Part 2 of the ODP Reference Model assumes that the essential properties of the collection of values can be expressed by some predicate, and so de nes a type as being that predicate. The predicate is true of all values from the collection represented by the type. Within the speci cation, we can de ne types as a short-hand for the common properties of other elements | to establish a classi cation. A speci cation can de ne a type | a date-type, say | and then declare a number of objects as being instances of this type. Considering the speci cation on its own, one can then talk of these objects as being instances of the type, and say that the object \myBirthDay" and the object \yourBirthDay" are di erent occurrences of use of the type \date". This is distinct from the relationship between the speci cation and some real-world object that implements it, which is, in a di erent sense, an occurrence of it. In this sense the speci cation as a whole can be seen as de ning a type, which in the context of the possible execution environments has instances wherever and whenever the speci cation is applied. The idea of abstract implementation as a relationship between speci cations is basic to the idea of re nement. One speci cation is an abstract implementation of another if all the possible behaviour of the more re ned speci cation is consistent with the original speci cation, but some behaviour will generally be excluded. The distinction between type and value needs to be distinguished from the use of types to de ne other types. In hierarchical type de nitions, one type is de ned in terms of other types. Thus, for example, a record type can be de ned as consisting of a pair of integers, or a server object type can be de ned to imply behaviour which is a sequential composition of the behaviour of a generic authentication object and that of an application-speci c service. This is not the type-value relationship. It is another kind of internal relationship that helps structure the type speci cation. There will, in general, always be some attening process that would transform the hierarchical type speci cation into a single type with a single, somewhat complicated, collection of values. Although the steps in the de nition hierarchy are not related as types are to values, speci ers often use similar vocabulary, leading to the impression that a similar mechanism is in use.
3 Speci cation Epochs The two kinds of relationship overlap when speci cation occurs in a number of stages. This may simply involve hierarchical speci cation of the kind discussed above, where types de ned in one speci cation are drawn upon by reference
in a later speci cation as characterizing objects or in further type de nitions. However, it may also involve requirements that speci c, pre-existing real-world entities having the prede ned types should be used. One example of this was found in the speci cation of standards for the directory services and protocols, where ISO and ITU-T published parallel main texts, but with di erent conformance requirements. The ISO 9594 text de ned a collection of service types, capable of instantiation any number of times to support any number of directory spaces, but the ITU-T X.500 Recommendation required implementations to be tied to the speci c global root for their name space. Thus although the protocol de ned was the same, the declared scopes were di erent, and the consequences of using the two speci cations were signi cantly di erent. There are clearly many possibilities for inconsistency here, and reuse of components in an environment de ned using reuse of their speci cation will lead to problems unless the speci cations are in some way immutable, either absolutely or by virtue of some strong version control system. Indeed, one of the main responsibilities of the formal standardization bodies is to manage fair and non-disruptive change control.
4 Roles in Communities The ODP Enterprise language is based on the de nition of communities whose behaviour is speci ed in terms of roles that are lled by speci c objects. The speci cation of composite behaviour based on the lling of roles in community types2 yields a number of overlapping communities with mutually dependent behaviour, and is a particularly powerful way of structuring such speci cations [8], [9].
4.1 What is a role? What, then, is the concept of a role? The ODP concept of community is expressed in terms of
{ a set of roles, { behaviour involving these roles, and { constraints on the way these roles may be lled by objects when creating speci c communities.
Attempts to t roles into the same framework as objects and to speak of role instances (see, for example, [10]) have required modi cations of the ODP concepts in ways that seem to the current authors to miss the essential function 2
In ODP, a type is any named predicate that applies to things in a model. A template is a speci cation with suÆcient detail to allow an instantiation. Thus, O-O programming language classes are templates. Types can only be involved in testing when determining whether they apply to instances or not; templates can be used to create instances.
of a role as linking di erent parts of the speci cation. We do not believe that roles are instantiated, but that they link parts of the speci cation dealing with community templates and the role- lling objects that are then all involved in instantiating the community as a whole. Let us, therefore, examine these ideas in a little more detail. The metaphor on which role is based is theatrical. The text of a play is expressed in terms of lines and actions associated with various roles, which are declared initially in a cast-list. Putting the play on involves assigning actors to the various roles, although one actor may play several minor roles, and the actor playing a role may change during the run of the production. Identifying the roles rather than the actors obviously makes the script more reusable. In the same way, specifying a community type in terms of roles allows the community type speci cation to be reused as often as needed, with di erent associations between roles and the objects that ll them. One object can ll a number of roles and the object lling a role can change during the lifetime of the community. This is a familiar situation when extracting common elements from a speci cation, and there are parallels with, for example, the speci cation of procedures or functions in most programming languages. The procedure call is expressed in terms of a number of formal parameters of stated types, which are associated with actual values or variables of the corresponding type when the procedure is called. The formal parameters are used within the body of the procedure to express the algorithm to be performed. The roles can be seen as the formal parameters of the community type, which are used as place-holders in specifying the community behaviour, or, conversely, as the names of those pieces of the behaviour that the objects lling them are to be responsible for performing. This is what part 2 of the RM-ODP means when it refers to a role as an identi er for a behaviour. There is some support for the view of role as a formal parameter in [11]. Roles in ODP are either un lled or lled by exactly one object at a time. This may seem limiting, but provides a clear interpretation. In some circumstances, where a community has many similar roles, or a group of roles whose size varies dynamically, speci cations can be compressed by the introduction of speci c notations, but these can always be attened to give the underlying ODP concept. Thus, for example, a committee may be expressed as having a chairman role with cardinality one and a member role with cardinality n, where n varies with time. The interpretation of this is that the member role is, in fact, a short-hand for a set of roles, which are created or deleted as necessary as members join or leave, with one underlying role for each existing member.
4.2 Is a Role an Object? One of the commonly asked questions about roles is how they relate to other speci cation concepts. Is role a subtype of object? How does it relate to the speci cation type system? The answer is not straightforward. At a basic level, a role is not an object, but it does share some of the characteristics of an object:
Roles, like formal parameters, have domain types (the types of the values that can be assigned to the parameters), and these types are closely related to object types. However, the type so associated with a role is related to the type (or a super-type) of the potential objects that would be able to ll the role; it is not the roles themselves that are instantiable; roles can be lled by objects, as long as their type is satis ed, but they cannot be instantiated, as the role looses its meaning when separated from its community type or template. What is instantiated is the entire community template, which is then an instance of the community type. Of course, roles could be associated with any numbers of other types that one likes, such as roles that are diÆcult to perform, roles that have a cardinality of one, and so on. The instances of these types are the roles themselves. If roles are just formal parameters, one might expect them only to be involved within the speci cation, without run-time visibility. So, are roles visible in the object interactions observed in the system in operation? Often, they are not, but in some cases they are. Consider a system using role-based access control. In such a system role names will be communicated with an operation invocation, because the access decision may need the information. If one object lls two roles it must either indicate the role it is currently playing, or have all its actions assessed based on the union of the role permissions, giving it too much freedom and weakening the access control policy. In general, systems that make roles visible at run-time can exhibit this kind of exibility, providing it by a level of indirection, or an abstraction between an object and its behaviours. One way of expressing this is to say that those speci cations that involve behaviour determined by the role in some non-trivial way are precisely those speci cations that involve some degree of re ection. Asking what role an object is playing is equivalent to asking how it came to be part of the community, (that is, which formal parameter it actualizes in performing a given action).
5 Conformance The ODP Reference Model de nes a conformance framework that relates speci cation, implementation and testing. These are, in essence, the roles in a community representing standards creation and use. The division of responsibility between these roles is: 1. the speci er constructs a model of the expected system behaviour and of that required of its environment for its correct operation. They also specify the logical locations within the speci ed con guration that are to be conformance points | points at which observation must be made possible in a conforming implementation. If the speci cation is structured, so that one part draws on another, the more abstract framework may de ne a richer set of reference points, only some of which are selected as conformance points when the framework is re ned 2. the implementor states which speci cation has been implemented, where the conformance points are located in the implementation (i.e. how testing can
be performed), and how the observations are to be interpreted to identify the actions de ned in the speci cation. The rules for interpretation can take many forms. They may be expressed by reference to other standards, or they may be speci c to this particular implementation. 3. the tester observes the implementation at only those points identi ed by the implementor, and uses the interpretation given by the implementor to analyse the observation. If the interpretation fails, the system is not conformant. If it succeeds, then an action de ned in the speci cation has been identi ed, and the speci cation is then checked to see if the action is valid in the circumstances, and hence that the implementation is conformant. If the speci cation is comparatively concrete, the interpretation is generally quite straightforward. However, if the speci cation is of some abstract procedure, such as a transaction mechanism, the implementor must specify the form of messages that represent the abstract actions in the transactional behaviour. If the speci cation is drawing on a complete suite of protocols from a single communication architecture, this may all be handled by reference to the conformance clauses in the respective standards. However, incorporating some ad hoc piece of activity into a general transactional structure requires its interpretation to be documented in detail. Note here that observation is the essence of the conformance process. It is not the same as the process of demonstrating that one speci cation uses another speci cation that it references in a consistent way; this is not conformance, but what ISO calls compliance, and takes place when the standards are written, not when they are implemented. The observations made can be of many kinds. One can observe messages on a network, interactions between software components or physical stimuli on or displays from the system under test. To cover the options, the ODP Reference Model de nes four kinds of reference point. These are:
{ interworking reference points, where observation is of signals on some communications medium;
{ programmatic reference points, where observation involves interactions at
software interfaces, either between application components or at a kernel or middleware boundary; { perceptual reference points, covering the whole range of externally observable actions, whether initiated by the system or its environment, ranging from screen and keyboard interactions to process control sensors and robotic actuators; { interchange reference points, covering information interchange using removable media, such as discs or ash memory.
What does this conformance structure imply for a multi-viewpoint speci cation? Conformance points may be declared in some viewpoints, if they describe the system structure in suÆcient detail to make the localization of boundaries and points reasonable. In other cases, the description may be in terms of organizational or logical structure, with no direct expression of locality. In such cases,
the process of testing and interpretation may involve more than one viewpoint, and may rely on viewpoint correspondences. Consider, for example, the expression of conformance to speci cations in the Enterprise Language. The Enterprise Language speci cation might de ne a security community in which managers are required to authorize purchase requests above a certain value made by their sta . The reference points involved may be points associated with the internal network supporting a work ow system, but they are likely to be de ned in terms of the business logic of the work ow | in a computational speci cation. The interpretation of exchanges within the work ow system in organizational terms is likely to depend on elements of both information viewpoint and enterprise viewpoint speci cations; these must be established before a step in the work ow can be categorized as being both a purchase and as authorized. To do so, the purchaser and manager roles must be identi ed. All this must happen before the enterprise constraint can be checked. Even if the reference point can be localized in the computational speci cation, information from the engineering speci cation is still likely to be involved in decoding an observed physical interaction or bit-stream in terms of object interactions. The constraints in the enterprise speci cation are likely to be expressed as universals or invariants. Testing is therefore likely to take the form of continuing monitoring for correctness, and failure demonstrated by discovery of a counterexample to the rule. The conformance framework has been outlined here in terms of third-party testing, and can generally be seen as such without loss of generality. Indeed, the third party style is the natural one to adopt in a standardization framework, where there are clear distinctions, and, often, con icting objectives associated with speci er and implementor. However, this does not help in interpreting questions of scope. To return to an issue raised earlier, does an implementation that follows the prescribed behaviour, but which is out of scope, conform to the speci cation? For example, is a watch build from the plans of a well-known manufacturer by a counterfeiter the real article? It is indeed a real watch, but not a Rolex! This reduces to deciding whether there is a scope-check performed by the tester before starting to observe behaviour, and so depends on the brief given to the tester. If we wish to make the decision process clear, we need to introduce a fourth role, that of customer or system-owner, who instructs the tester. The scoping decisions can then be explicitly represented as a balance of obligations between the owner role and the speci er, implementor and tester roles related to the testing process.
6 Self Reference So far, we have considered the system speci cation and the system implementation as distinct domains. However, this is itself a simpli cation. The adoption of more powerful supporting tools for system generation and maintenance, and the structuring of speci cation into a number of linked viewpoints leads naturally
to a well integrated tool-chain or tool-mesh. A number of specialized design and management tools cooperate via some form of distributed, shared repository, like the OMG Meta-Object Facility. Once the speci cation and its supporting tools are seen as playing a continuing role in the system's lifecycle, it becomes natural to assume that there will be yet more cross linkages of information about the system: 1. changes in organizational structure can be used to derive modi ed con guration management policies directly; 2. measurement of actual system performance can be fed back into re nement and optimization of design, selecting the most appropriate engineering mechanisms to use dynamically to match changing loads and behaviour patterns; 3. proposed changes in policy or business process can be assessed by tools using current information and shadowing real activity to check for unforeseen consequences. In this style of system, the speci cation repository and associated tools become fully integrated components of the system, and so the speci cation must, at some level, model itself and its own behaviour and lifecycle. The speci cation has become re ective and self-referential. The longer-term implications of this for software engineering are profound. Just as the cell maintains and copies its own DNA, the system manages and maintains its own speci cation. This implies that the assumptions about the relationship of speci cation to implementation become just part of a wider system view. It will no longer be sensible to talk about either aspect in isolation. An implementation without access to its speci cation will be stagnant, and a speci cation divorced from its implementation will become a mere description.
7 Conclusions This paper has discussed some of the ways in which speci cations are related to real-world implementations or to other speci cations, and has illustrated the need for a exible interpretation of these relationships if the full potential of the speci cations is to be realized. It has identi ed, in particular, the importance of the use of policy to structure evolving sets of speci cations throughout the lifetime of large systems. Most speci ers would agree that, in some sense, the expected purpose of an ODP model is to model some particular system, which is some real thing that someone has built, will build, or at least imagines building. However, taking either speci cation or implementation in isolation leaves some ambiguity about the tightness and cardinality of the speci cation-implementation relationship. It is only by modelling the wider process of speci cation, implementation, testing and ownership or use that the full situation can be expressed, and the creation of a more formal conformance framework is one of the steps in this process.
Acknowledgment The authors would like to acknowledge the work of many ODP experts who have been involved in investigating and tackling the problems of enterprise speci cation. Although the views in this paper are the authors' responsibility, they could not have been formulated without many hours of detailed discussion within ISO on speci cation techniques and system requirements.
References 1. ISO: ISO/IEC IS 10746-2, Open Distributed Processing Reference Model | Part 2: Foundations, January 1995 2. ISO: ISO/IEC IS 10746-3, Open Distributed Processing Reference Model | Part 3: Architecture, January 1995 3. Linington, P.F.: RM-ODP: The Architecture. In: K.Raymond and E.Armstrong, editors, Open Distributed Processing: Experience with Distributed Environments, pages 15-33. IFIP, Chapman and Hall, February 1995. 4. Bowman, H., Boiten, E.A., Derrick, J., and Steen, M.: Viewpoint consistency in ODP, a general interpretation. In: E. Najm and J.-B. Stefani, editors, First IFIP International Workshop on Formal Methods for Open Object-Based Distributed Systems, pages 189-204. Chapman and Hall, March 1996 5. Linington. P.F.: An ODP approach to the development of large middleware systems. In: Proc. DIAS99, Helsinki, June 1999. 6. ISO: ISO/IEC FCD 15414, Open Distributed Processing | Enterprise Language, July 2000 7. Audi, R. (editor): The Cambridge Dictionary of Philosophy, Cambridge University Press, 1999. 8. Linington, P.F, Milosevic, Z. and Raymond K.: Policies in Communities: Extending the ODP Enterprise Viewpoint. In: Proc. 2nd International Workshop on Enterprise Distributed Object Computing (EDOC'98), San Diego, USA, November 1998. 9. Linington, P.F.: Options for Expressing ODP Enterprise Communities and Their Policies by Using UML. In: Proc. 3rd International Conference on Enterprise Distributed Object Computing (EDOC'99), Mannheim, Germany, September 1999. 10. Genilloud, G. and Wegmann, A.: A Foundation for the Concept of Role in Object Modelling. In: Proc. 4th International Conference on Enterprise Distributed Object Computing (EDOC'00), Makuhari, Japan, September 2000. 11. Kilov, H.: Business Speci cations: The Key To Successful Software Engineering. Prentice Hall, December 1998.
