Methodology for the development of distributed telecommunications services

Methodology for the Development Telecommunications Services Jean-Paul

of Distributed

Gaspoz

Swiss Federal Institute of Technology, CH-1015 Lausanne, Switzerland

This article ogy

for

proposes

the

tributed

combines

Processing)

concepts

systematic

Based

seamless

thread

then

when on

each models

Finally,

provided

that

we

motivait can be

propose

to the

ODP

should

performed

a

real-

system,

abstraction

information,

both graphical

the

levels.

We

are to be established

guidelines

model

the

as how

telecommunications

of the

and

with

by a secengineering

definition

related

enterprise,

rules

proposed

rules

observations,

dis-

Distributed

advocated

as well

problem

models

specifications

based level.

the

the

Mapping and

from

of the distributed

produce tional

on these

on hierarchically define

The

software

a combination

open

(Open

structuring

process

object-oriented

achieved. rzation

and

ODP

methodolof

fusion. We first examine

called

tions for such

design

services. the

development

generation

method

based

object-oriented and

telecommunications

methodology

ond

a new

specification

and

system are

under

provided

be built,

study. on

how

in particular,

at a higher and textual

to

computa-

abstraction notations

are

for most models.

1. INTRODUCTION Telecommunications systems are composed of a multitude of autonomous and geographically dispersed elements that have to cooperate to provide telecommunications or management services. In this respect, these services can be seen as distributed applications running on the multiple nodes of telecommunications networks. To relieve the service designers from the complexities introduced by distribution, distributed processing platforms are being developed that hide the heterogeneity and diversity of the communication and computing environment, as well as the actual degree of distribution of the

Address correspondence to Dr. Jean-Paul Gaspoz, TSA Telecom, ch. des D&es 9, CH-1013 Lausanne, Switzerland.

J. SYSTEMS SOFTWARE 1996; 33:253-271 0 1996 by Elsevier Science Inc. 65.5 Avenue of the Americas, New York, NY 10010

application (Rubin and Natarajan, 1994; Kelly and Mercouroff, 1995). A main benefit expected from such platforms is that the introduction of new services should be quicker and easier. A prerequisite for exploiting these benefits is that telecommunications services should be conceived in terms of application components suitable for distribution, that is, fulfilling well-defined. rules so that they can be more or less transparently distributed. Obviously, the specification of such components require models, rules, and concepts supporting and enabling such distribution. It also requires a methodological support assisting the specifiers and the designers from problem definition to the realization of the distributed system. As far as the conceptual background is concerned, the ODP (Open Distributed Processing) standards (ITU X.901-903, 1995) provide a reference model and powerful concepts to support the specification and design of distributed systems. Moreover, the use of different viewpoints advocated by ODP, each viewpoint representing a different abstraction of the original system, allows the inherent complexity of distributed systems to be reduced. However, apart from a few examples, ODP neither provides nor prescribes any methodological support that would help in applying the concepts and establishing the models corresponding to each viewpoint. Furthermore, the separation of concerns provided by the use of viewpoints is very useful to reduce the complexity of the system under study, but it may lead to inconsistent specifications, especially if the corresponding models are established independently. On the other hand, the object-oriented paradigm is gaining more and more acceptance in the telecommunications field as the best way to master complexity (ROSA, 1991; Barr et al., 1993). Object-

0164-1212/96/$15.00 PI1 SOl64--1212(96)00022-2

254

J. SYSTEMS SOFTWARE 1996: 33~2.53-211

oriented software engineering methods have existed for several years now and provide steps, models, and notations that assist the designer in capturing all aspects of a system in an object-oriented way. One of the most recent of these methods is called fusion as it combines and extends the best of several first generation object-oriented methods (Coleman et al., 1994). Although not the most popular yet, fusion is probably the most systematic and complete one, especially in terms of support of the overall development process. However, similar to the other current object-oriented software engineering methods, fusion has been conveived for sequential and centralized systems. Consequently, it is not very well suited to deal with the specification and design of distributed systems. The objective of the present methodology is to give an answer to the above-mentioned issues, namely, to provide an object-oriented methodology supporting the development of distributed telecommunications services and applications. Its aim is to help produce models conceptually consistent with the ODP reference model by taking advantage of the systematic development process advocated by fusion. In addition, the approach chosen is pragmatic and aims at reusing and combining the best of both worlds wherever possible. On the other hand, it is not the purpose of the present work to develop or provide a distributed processing infrastructure. Conversely, the existence of an ‘ideal’ environment supporting the corresponding ODP concepts and mechanisms will be assumed. Therefore, the main emphasis of the present methodology is to assist the identification and design of application components suitable for distribution and to provide some hints on how these components can be deployed and executed on an open distributed processing environment. 2. MOTIVATIONS Fusion is a second generation object-oriented analysis and design method developed by the HP labs in Bristol. This method combines and extends the best features of leading objects methods such as OMT (Object Modeling Technique (Rumbaugh et al., 1991)), Objectory (Jacobson, 19921, Booth (Booth, 19911, etc. Fusion adopts the division of the software development process into analysis, design and implementation and provides a rigorous treatment of each of these phases. One of its major strengths lies in the systematic and structured way in which analysis and design are performed. However, fusion has been developed for sequential and centralized systems.

J.-P. Gaspoz The application of this method to the specification and design of a distributed system has illustrated its limitations in this respect (Saydam et al., 1995). Moreover, the syntax and semantics prescribed by fusion within its models is in general not formal enough (in particular in the Operation Model) and may lead to ambiguous specifications. On the other hand, ODP is a major research and standardization initiative aimed at developing distributed processing systems based on open standards. The scope of ODP encompasses all potential applications of distributed processing systems, including telecommunications services. The ODP reference model provides powerful concepts and models to support the specification of distributed systems but intentionally does not provide any methodological support to facilitate the modeling inside each viewpoint or to enable the specifications to be linked in two different viewpoints. To reduce the complexity inherent to distributed systems, ODP standards recognize the need to consider the system from different viewpoints, each viewpoint representing a different set of abstractions of the distributed system (ITU X.903, 1995). The enterprise viewpoint focuses on the purpose, scope, and policy for an open distributed system. It describes the system in the context of the overall environment in which it operates, the interactions between the system and its environment, as well as the policies that govern these interactions. The information viewpoint defines the information semantics of an ODP system as well as the requirements for information processing in the system. As such, it focuses on the definition of information object types, together with their relationships, their states, and permitted state changes. The computational viewpoint is concerned with the processing functions and data structures which provide the distributed system function. It enables distribution through a functional decomposition of the system into objects interacting at interfaces. The engineering viewpoint focuses on the mechanisms and functions necessary to support the distribution of objects in the system. Finally, the technoZogy viewpoint is concerned with the realization of the system in terms of specific hardware and software components. The separation of concerns provided by the use of viewpoints allows the complexity of distributed systems to be dealt with. However, this separation may lead to inconsistent models and does not allow the relationship that may exist between entities specified in different viewpoints to be fully exploited. The question of how to prove consistency between different viewpoint descriptions is certainly still a research challenge at the moment. It is not the prime

Methodology

for Distributed

Services

J. SYSTEMS SOFIWARE 1996; 33:253-271

translation. Decisions at this level address the system does rather than how it does it.

concern of our study as it mainly relates to the validation area. Rather, our approach aims at promoting consistency by identifying possible mappings and information flows between models pertaining to different viewpoints. Thus, the existence of a correspondence between objects specified in different languages, even if it is not necessarily one-to-one, may be exploited during the system development process to help the designer in defining his models and in keeping them consistent. In summary, both approaches are not, at the moment, totally satisfactory for the designer of a distributed system. The idea advocated by this work is to combine the best of both worlds, namely, the conceptual richness of the ODP reference model with the power of the fusion method. The goal of the overall process will thus be to produce a specification and design conformant to the ODP viewpoints and related concepts by using the structuring and models advocated by fusion. The semantics behind the models will be the ODP one, whereas, fusion will be used as a guideline to derive the models and link the different viewpoints.

3. FUSION PHASES ODP VIEWPOINTS

WITH

Contrary

to the objects identified during the fuprocess, information objects are not only static data structures, but exhibit a behavior too. However, ascribing a behavior to individual information objects does not necessarily mean taking design decisions. On the contrary, we shall see in Section 4.2.4 that such an allocation can and even should be performed without constraining how the system achieves a given functionality. Therefore, the complete information specification still pertains to the analysis phase. The computational viewpoint is concerned with the logical partition of the function provided by the system into interacting objects. Its scope thus covers the design phase.

The main focus of the engineering viewpoint is to realize the interactions identified in the computational viewpoint and provide this latter with the transparencies it requires. Regarding distribution, the computational viewpoint specifies what can be distributed, whereas the engineering viewpoint states how this distribution can be achieved. In that sense, the scope of the engineering viewpoint can be considered as part of the design phase. However, it is important to stress that the engineering viewpoint has no counterpart in the fusion development process as the issue of distribution is not addressed in that method. Therefore, even if both computational and engineering viewpoints pertain to the design phase, they aim at solving different issues, namely, how a given functionality is achieved by interacting objects and how these objects can be distributed, respectively. In software engineering terms, the engineering viewpoint corresponds to a refinement, at a lower level of

RESPECT TO

In software engineering terms, viewpoint relates to requirements

the enterprise capture and

Table 1. Mapping Fusions’s Phases to ODP Viewpoints ODP viewpoints Ent.

Info

11

Implementation

I

Eng.

Comp

w

Requirements capture

what

sion analysis

Based on the previous descriptions, this section attempts to put ODP viewpoints and the software development phases postulated by fusion into perspective. The reason for this mapping is to identify which models advocated by fusion can be used to facilitate the specification of distributed telecommunications services and in which ODP viewpoint they can be used (Table 1). l

255

Vpt

Fusion Phases

I

I

I

Tech

256

abstraction, of the initial design, it takes into account issues (i.e., have been intentionally omitted In this respect, it can be seen as l

J.-P. Gaspoz

J. SYSTEMS SOFTWARE 1996; 33:253-271

in the sense that distribution) that in the first place. a detailed design.

By nature, the technology viewpoint addresses issues that are relevant to the implementation of the distributed system.

4. PROPOSED

METHODOLOGY

The objective of this work is to propose a methodology supporting the specification and design of distributed telecommunications and management applications and services. As any methodology, the present one aims at allowing to distinguish, order, and categorize concerns and handle categories of concerns in a step by step fashion. The scope of the work thus comprises the definition of a set of steps or phases that guide the developer from problem definition to the realization of the distributed system, the models to be defined in each step, as well as the syntax and semantics associated with these models, and the transitions inside or between the phases-in other words, how the output of one or more models can be used as an input to another model. The methodology proposed in this document is to use the software engineering phases advocated by fusion as intermediate steps to facilitate a smooth and seamless development process leading to a final ODP conformant specification. More precisely, the solutions proposed to the above mentioned issues are the following. The ODP reference model constitutes the conceptual framework of the methodology. It thus defines the semantic content of the models to be issued all along the development process. Of prime interest are the concepts supporting the definition of a distributed system (ITU X.902, 1995) as well as the way the specification of such systems should be structured, in particular, in terms of viewpoints and associated languages (ITU X.903, 1995). The phases of the methodology are those advocated by fusion, namely, requirements capture, analysis, design, and implementation. According to van Sinderen et al., (1993), only one category of concerns is dealt with in each phase, such as, ‘what is expected from the system’, ‘what it does’, ‘how it does it’, ‘how it is distributed’, and ‘how it is implemented’. Moreover, these phases represent hierarchically related abstractions levels in the sense that at each level, the goals achieved at previous abstraction levels are preserved.

The models to be developed in each phase, as well as the transitions between the models have been partly borrowed from fusion and partly proposed in this study. Indeed, to deal with the issue of distribution, enhancements to some of the original fusion models are needed. Graphical and textual notations are proposed for almost all models to improve their readability and to ensure a level of formalism sufficient to prevent any ambiguity A synthetic view of the overall development process advocated by this study and structured according to the ODP viewpoints is represented in Figure 1. To limit the “scope of this work, only the enterprise, information, and computational viewpoints have been considered so far. The dotted arrows and the Roman numerals on Figure 1 represent the ordering in which the models should be specified. The numbered arrows represent the information flows between the different models, that is, they illustrate the output of the models that should be used as input to other models. These information flows will be described at the same time as the models they influence. A reference to their associated number (e.g., (4)) will indicate such a description. The description of the different models illustrated in Figure 1, their associated notations, and the transitions between these models will be the purpose of the remainder of this section. 4.1 Enterprise Viewpoint 4.1.1 System objectives and scope. According to Section 2, the enterprise model should firstly specify the purpose and objectives of the ODP system under study. The corresponding-mostly general and informal-statements do not represent a model as such but allow the definition of the universe of discourse, whose identification represents the first step in any modeling process. Similar statements about the scope of the system allow the actual problem domain to be refined, within the universe of discourse. The definition of purpose, scope, and objectives of the system in general constitutes a prerequisite to the elaboration of all models of the present methodology.

4.1.2 Requirements. The enterprise viewpoint is directed to the needs of the users of the distributed telecommunications system. In this respect, a major issue is to capture and define what needs the system is intended to meet. This is expressed as a list of

Methodology for Distributed Services

J. SYSTEMS SOFIWARE 1996; 33:253-271

257

model notation

!ct Model grph

txt

: Fusion’s Object ~ Model Notation, ’ : ASN.l I

Operation txt

Overall

Interaction Model grph

: Computational Object Interaction Graphs, Computational Object

Model

: Fusion’s Operation Schema

Figure 1.

Computatior

Computational Object Template Txt : ODL

development process.

requirements, written in natural language and which define the functionality required from the system. The requirements represent a detailed yet still informal refinement of the system objectives, mainly from the user’s point of view. In a market-driven strategy, identification of needs may well occur first and actually determine the purpose of the system. However, the refinement of the requirement capture process can only be performed once the scope and objectives of the system have been clearly stated (1)‘. 4.1.3 Organizational model. The aim of the organizational model is to describe, based on its scope and objectives (3), where the system is placed and

‘This number refers to the corresponding information flows of Figure 1.

used within the enterprise. The ODP system and the environment in which it operates are represented as a community, that is, a configuration of enterprise objects formed to meet an objective. In addition to natural language, the fusion object-model notation (see Section 4.2.1.2 below) may be used to specify the organizational model. The resulting object model describes at a high level of abstraction the place of the system in the community, the roles it fulfills within the community, and the environmental constraints that affect it. As such, it is not a model of the information itself (this is the purpose of the object model in the information viewpoint) but a model of the universe of discourse about which the information is needed. 4.1.4 Policies. One of the main concerns of the enterprise viewpoint is to establish policy statements

258

J.-P. Gaspoz

J. SYSTEMS SOFTWARE 1996: 33:2.53-271

about the system. The concept of policy is widely used in the management and security areas, yet often with different semantics. It is thus not a surprise to find in the current literature almost as many definitions as references where the term is used (IS0 10181-1, 1991; SYSMAN, 1993; Wies, 1994). Although different in their formulation, these definitions share several characteristics from which the following pragmatic interpretation is derived. l l

l

l

l

l

l

l

I

pq input-event-1

p&q i :

time

j

input-event-2

2; j ,:

:;+ -output_event_3 - - - _I :

ii

Figure 2. Timeline diagram notation.

a policy consists of a set of rules a policy defines what has to be done to achieve a given goal a policy can express a permission, a prohibition, and an obligation a policy constrains the activities undertaken by the system

It is worth mentioning from the above statements that a policy is not a goal in itself but a means to achieve this goal. Examples of relevant goals are high-level system objectives (2) or requirements to fulfill (6). Moreover, a policy defines what the system has to accomplish but not how this is achieved. Finally, policies should be determined by the organization (8) rather than imposed on the organization by technology choices (Raymond, 1993). Policies are expressed using natural language. However, to ensure that sufficient and relevant information is present in policy specifications as well as to give them a uniform structure, the use of a policy specification template is recommended. This template, borrowed from (SYSMAN, 1993) and slightly modified to conform to the ODP policy concept, includes the following attributes. l

lriifq

a modality which expresses permission, tion, or obligation

prohibi-

an activity which defines a set of actions or permitted operations a subject which defines the entity that performs the activity a target which defines the entity or the set of entities affected by the activity constraints which apply to the activity

Note that both subject and target should refer to enterprise objects or roles identified in the organizational model. 4.1.5 Life-cycle model. Scenarios of usage allow the combined behavior of the system with its environment to be specified in terms of interactions between them (Figure 2). These scenarios are mainly

derived from the users’ expectations on the system expressed in the requirements (5). In addition, the communities identified in the organizational model as part of the system environment represent potential agents likely to interact with the system (9). Finally, policies may impose constraints-security constraints-for instance, on the way the system interacts with its environment (7). The system is considered as a black box, and the entities within the system are not visible at this level. In other words, the scenarios specify a system level interaction model (observable behavior), whereas the object level interaction model (internal behavior) is part of the computational viewpoint? The scenarios may be generalized and formalized into a life-cycle model that specifies the allowed sequence of interactions in which the distributed system considered may participate over its life-time. This model provides a high-level description of the interfaces between the system and its environment. The syntax used for that purpose is described in Figure 3.

4.2 Information

Viewpoint

4.2.1 Object model. The first part of the information model focuses on the static data structures and relationships existing within the system, The resulting object model describes what the system is in terms of entities that constitute it and the couplings between them. It represents a restatement, in a graphical notation, of the problem statement, such as that expressed in the requirements. Guidelines for establishing the object model (4) can be found in (Rumbaugh et al., 1991; Coleman et al., 1994). Using such guidelines leads to the definition of object models pertaining both to the system and to its

*The observable behavior is defined in terms of interactions between the system and its environment. The internal behavior defines how the system should be designed to accomplish the observable behavior (van Sinderen, 1993).

Methodology for Distributed Services

J.

SYSTEMS

1996;

life-cycle [Name :] Regular_Expression (localName

= Renulor_ExpressionJ

*

Regular_Expressions: Name

Any event name (system operation), local name or output event (the name of an output event is preceded by a #)

Sequence

Alternation

X-Y

Repetition Zero or more

X*

One or more

x+

Optional

XlY [xl

Interleavmg

II

Grouping

6)

Figure 3. Life-cycle model notation.

environment. The life-cycle model then allows this model to be restricted by considering the classes corresponding to the agents as outside the system (10). The main modeling concepts that define the semantics of the object model come from (ITU X.902, 1995). However, as the concept of relationship is not directly addressed in ODP documents, the corresponding definitions are derived from (Bapat, 1994). 4.2.1.1 Relationship modeling. A relationship is defined as an operational coupling between two object classes. The object class on which the attention is focused is called the subject. Each object participating in a relationship with the subject is called its relatant. Each object participating in a relationship is said to play a role in that relationship. Each role possesses a certain multiplicity that quantifies the number of instances of the object class playing a given role that may participate in a relationship, with each instance of the object class playing the other role. In its general form, the multiplicity is defined as the numeric range between a lower and an upper limit. If not explicitly specified, the multiplicity is by default equal to one. Although the limits of the relatant multiplicity are generally specified in terms of integer constants, they may also be expressed in terms of attributes of the subject. Such

Relationship

Class

SOFTWARE

expressions allow relatant multiplicity to be accurately specified, based on some capacity-related attribute of the subject. At the level of abstraction of analysis, only monotonic inheritance is considered, that is, each class inherits all properties defined for its ancestral classes, where properties also include the relationships in which the parent classes participate. A class may define additional characteristics of its own but, conversely, may not suppress any of the properties inherited from its parent classes. Finally, there are properties characterizing the relationship between two classes rather than the participant classes themselves. Such properties are most properly modeled as relationship attributes. 4.2.1.2 Graphical object model notation. The graphical notation introduced by fusion and based on Entity-Relationships diagrams will be used for information modeling purposes with a slight modification concerning the way the aggregation relationship is represented (see Figure 41. 4.2.2 Operation model. The operation model specified the overall fuctionality of the system and the effect each system operation has on the state of the system. As such, it defines the role of the system in the combined behavior of the system with its environment (van Sinderen et al., 1993). The operation model is part of the information viewpoint as the system’s behavior is expressed in terms of notions that pertain to this viewpoint, such as information objects, relationships, etc. Moreover, it allows the three kind of actions relevant to the information viewpoint to be specified, namely, object creation, object deletion, and the object’s state change (ITU X.903, 1995). The system operations captured in the life-cycle model (11) are individually specified in the operation model by using a textual template borrowed from fusion (Figure 51.

AggregationRdaficnship

Fl

class_2

5 1

m

ass

‘rp; ubClass

Figure 4. Graphical object model notation.

259

33:253-271

contains

-is M3

Class-3

260

J.-P. Gaspoz

J. SYSTEMS SOFIWARE 1996; 33:253-271

Operation:

OBJECT-CLASS::=CLASS

operation identifier

Description: Description of operation Reads:



estate components>

Changes:





Sends:



Assumes: Result:









&SpecializesFrom &Attributes

ObjectClassLabel ATTRIBUTES

&Actions &objectClassLabel

ACTIONS OBJECT IDENTIFIER

OPTIONAL, OPTI0NAL. OPTIONAL, UNIQUE

WITHSYNTAX

Figure 5.

Operation model notation.

The approach advocated by this document differs from the fusion method, however, in the sense that not all input events give rise to a system operation. Indeed, certain input events are actually the responses of request/responses types of interactions that are typical in telecommunications systems. The system behavior upon receipt of such a response is thus intimately bound to the state of the system when the corresponding request was issued. Such events are thus much more easily dealt with by considering them within the operation schema of the previous operation. In other words, such interactions are analyzed as if the response were received immediately after the request was sent (see ‘Result’ clause in Figure 16). 4.2.3 Formal notation. The object and operation models defined so far provide a clear understanding of what the system is about and what its underlying concepts are. However, the behavior specified in the operation model still pertains to the overall system and not to the individual information objects. Moreover, the graphical object model gives a high-level overview, especially meaningful to the human reader, and captures the essence of the model but not every detail about attributes and properties. Consequently, a formal modeling syntax is needed that allows the semantics of the information model to be precisely captured and specified. The notation retained to express the semantics of the information model is ASN.l (Abstract Syntax Notation One (Steedman, 1990; ITU X.680, 1994)) and makes use of the modeling constructs defined in (Bapat, 1994). ASN.l has the major benefit of being a widely used and well-established international standard notation. Furthermore, even if it is not object-oriented, it provides building blocks for creating constructs on which user-defined semantics can be imposed. The ASN.l structuring mechanism called ‘information object class’ is probably the most relevant in this context. Despite its confusing name, this construct has nothing to do with information

[SPECIALIZES-FROM [ATTRIBUTES

&SpecializesFroml &Attributes]

[ACTIONS IDENTIFIED-BY

&Actions] &objectClassLabel

Figure 6. ASN.l object class template.

objects in the ODP sense. It is merely a template that allows the packaging of a set of other types together in a single construct (ITU X.681, 1994). The templates retained for the time being allow the formal specification of classes, attributes, actions, relationships, and constraints. The templates for classes and relationships are presented in Figure 6 and Figure 7, respectively. The concept of action will be elaborated further in the following section. 4.2.4 Behavior of individual information objects. In accordance with fusion’s analysis phase, the objects captured so far are static data structures only and do not exhibit a behavior. However, according to ITU X.902 (19951, an object is characterized by its state and by its behavior. Considering only static objects in the information viewpoint would be a restrictive and incomplete interpretation of this definition and also would impair the modeling richness

RELATIONSHIP::=CLASS &subject &forwardRole

OBJECT-CIASS, PrintableString,

&subjectMultiplicity &relatant &reciprocalRole &relatantMultiplicity &Attributes &relationshipLabel

Multiplicity OBJBCT~CIASS, PrintableString, Multiplicity ATTRIBUTE OBJECTIDENTIFIER

OPTIONAL,

OPTIONAL, OPTIONAL, UNIQUE

WITHSYNTAX

( OBJECT-CLASS IN ROLE [WITH MULTIPLICITY RELATESTO OBJECT-CLASS IN ROLE [WITH MULTIPLICITY [ATTRIBUTES IDENTIFIED-BY

Figure 7. ASN.l

relationship

&subject &forwar&le &subjectMultiplicityl &relat_ant &reciprocalRole &relatantMultiplicityl &Attributes] &relationshipLabel

template.

Methodology

for Distributed

Services

J.SYSTEMSSOFTWARE 1996;33:253-271

provided by an object-oriented approach. Therefore, to be complete and really object-oriented, the information specification should also take the individual behavior of information objects into account. Most often, the dynamic behavior of an object is defined by allocating operations to the object. However, the issue whether operations should be ascribed to individual information objects is quite controversial as it actually represents a functional decomposition of the overall system functionality such as that described in the operation model. Doing so clearly implies design decisions that are much better taken in the computation viewpoint in the context of a complete interaction model. Design choices in the information viewpoint already should be avoided, as according to Linington (19921, the information viewpoint should not ‘prejudge any ofthe decisions which need to be taken in mouing from a global riew to a specific partitioning of functions in preparation for distribution’. Therefore, the behavior of an information object shall not be described in terms of operations that may be invoked on that object, but in terms of changes of the object state resulting from a given set of actions. Without entering in too much detail into the realm of mathematics and logic, which is beyond the scope of this work, the temporal logic of actions (Lamport, 1994) provides a precise definition of action that is particularly suitable in our context. Indeed, an action represents a relation between old states and new states, where a state is simply an assignment of values to variables. To capture the effect of each action a new special-purpose ASN.1 template has been defined (see Figure 8). In the proposed template, the action is expressed in terms of predicates. Optionally, one or more preconditions can constrain the (old) states in which the action may occur. The state of the object upon completion of the action is specified, using one or more postconditions. In case several postconditions

ACTION

::=CLASS

( &Parameters &Preconditions LPostconditions &actionLabel

PARAMETERS ComparedADEs ComparedALEs, OBJECT IDENTIER

WITHSYNTAX

( [PARAMETERS [PRECONDITIONS POSTCONDITIONS IDENTIFIED-BY

&Parameters] &Preconditions] &Postconditions &actionLabel

Figure 8. ASN.1 action template.

OPTIONAL, OrnIONAL, UNIQUE

261

are specified, the overall postcondition is the logical conjection of these predicates. Note that the type ComparedADEs is simply a pair of attribute-defined expressions, that is, an expression comprising mathematical or logical operations on attributes, with a comparator between them.

4.3 Computational

Viewpoint

The computational viewpoint focuses on the functional decomposition of an ODP system into structures suitable for distribution. These structures are expressed in terms of computational objects, internal actions of and interactions between computational objects. The infrastructure supporting these interactions is not visible in the computational viewpoint. It is described in the engineering viewpoint. 4.3.1 Computational specification. The computational specification starts by distributing the functional behavior of each system operation across objects in the system. This transition will be performed in a way similar to the design of object interaction graphs (Coleman et al., 1994), but individual method calls will eventually be replaced by interfaces invocations. As a first step, the information objects that are affected by the system operation to be distributed will be considered as pontential candidates for computational objects (14). As the actual mapping between information objects (10s) and computational objects (COs) is not necessarily one-to-one, iterative refinements of the initial model will be necessary to determine to COs needed to provide the required functionality. Moreover, actions are obvious candidates to become operations in the computational viewpoint, especially if the corresponding IO maps to one single CO. If a set of 10s are encapsulated in one CO, the actions ascribed to these 10s may be realized via internal actions or operations, depending on whether the corresponding behavior is to be visible outside the encapsulating CO. Finally, recall that relationships represent operational couplings between object classes. Therefore, the existence of a relationship between 10s either provides a good rationale for encapculating them together in the same computational object or indicates the need for a binding between interfaces of their corresponding CO. 4.3.1. I Computational object interaction graphs. Based on the previous guidelines, each system operation specified in the information viewpoint is designed into a computational object interaction graph

262

J.-P. Gaspoz

J. SYSTEMS SOFTWARE 1996; 33553-211

template

object inherita typedor attribut.8

from

operations initialization intsrfacss

required supported

intsrfac*s

babavior

iparent_object_template_name>

(n = sequence number)

Figure 11. Computational Figure 9. Notation

for computational

object template.

object interaction

graphs.

that determines how the COs interact, in terms of operations invocation, to provide the required functionality (15). The notation used for that purpose is shown in Figure 9. The arrows represent the invocation of the corresponding operation on the CO. Numbers define the sequencing of invocation. 4.3.1.2 Computational object type diagrams. Once each system operation has been designed into a computational object interaction graph, operations and attributes are allocated to CO instances, and the dependencies between these operations are defined. However, different operations may have been allocated to the same CO in different graphs, or the same functionality may have been assigned to different CO instances. The next step of computational modeling thus consists of collecting and harmonizing design decisions that have been taken in different contexts but pertain to the same entities. In particular, the attributes and operations allocated to the same CO in different graphs are collected to build up computational object types. The operations supported by each CO type are grouped into interfaces to provide a precise description of the services offered by the CO type (Figure 101.

not prescribe any formal template allowing all information pertaining to a computational object type to be captured. Therefore, the CO template used in the present document has been borrowed from the work of the RACE project PRISM (PRISM, 1994). Its general structure is shown in Figure 11. An overview of the computational modeling process is represented in Figure 12. This figure illustrates that, to achieve a functional decomposition of the system into interacting objects suitable for distribution, the computational model closely builds on the system analysis performed in the information viewpoint. Moreover, CO types are designed using a combination of top-down decomposition and bottom-up design, thus promoting consistency and reusability.

4.4 Engineering

Issues

At this point, the distributed application is specified in terms of computational objects that interact with

4.3.1.3 Notations for computational object types. Finally, computational object types may be defined individually in a more precise way through the use of a textual CO template. Unfortunately, ODP does

ComputationalObjectType_l attributes

attributes

required Interface __1

Figure

grams.

10. Notation

ComputationalObjectType_2

supplied interface

for computational

object type dia-

Figure

model.

12. Development

process for the computational

J. SYSTEMS SOFTWARE 1996; 33:253-271

Methodology for Distributed Services each other. Although the computational objects have been defined so that they are suitable for distribution, the description is still performed in distribution transparent terms. On the other hand, the engineering viewpoint focuses on the infrastructure required to provide and support selective distribution transparent interactions between objects. Ideally, if a distributed platform were to support all engineering functions and mechanisms defined in (ITU X.903, 1995) a distributed application could be deployed and executed without the application programmer having to take account of the potential diversity of hardware and communication mechanisms in the underlying network and also without having to care about the degree of distribution of the application (ANSA, 1993a). Currently, a considerable work is being performed towards the realization of such platforms, for instance, AnsaWare (ANSA, 1993b), DCE (Distributed Computing Environment), TINA-C DPE (Distributed Processing Environment (Kelly and Mercouroff, 1995)), OMG CORBA (Common Object Request Broker Architecture), etc. None of them so far is totally consistent with the ODP engineering concepts and mechanisms. However, as already mentioned, it is not the purpose of this work to address infrastructure related issues. Rather, we merely assume that an ODP compliant platform will exist in a close future and provide a run-time environment to computational objects. Note that a complete distribution transparency such as that mentioned above is not always desirable. Indeed, hiding distribution issues also prevents control to be exercised on this distribution. For instance, to achieve a good availability of a given service, it may be necessary to replicate the server object providing this serice. If reliability is to be ensured as well, it may be necessary to exert a certain control over the location of the servers to ensure that they are not all on the same machine. That is why we previously used the term ‘selective’ distributed transparent interactions. In summary, the previous statements show that the mapping between computational and engineering specifications mainly depends on the selected transparencies and will mostly be supported by the distributed infrastructure. Because the set of concepts necessary and sufficient to provide such transparencies is well defined and quite limited, the use of compilers and tools, such as AnsaWare PREPC (ANSA, 1993b) seems well adapted to perform such a mapping. Therefore, the provision of a strong methodological support is less crucial at this level.

5. EXAMPLE: BANDWIDTH

5.1 Enterprise

263

AN OPEN DISTRIBUTED VPN MANAGEMENT SERVICE Viewpoint

The previous methodology is now applied to the specification and design of a simple bandwidth management service offered as an enhancement to a virtual private network (VPN) service. A VPN is a telecommunications service that provides corporate networking between customer premises using shared public switched network infrastructure instead of dedicated network resources. The logical connectivity between any two VPN sites is associated with a given bandwidth that represents a guaranteed capability, that is, this bandwidth is always at disposal of VPN users although it may not be used totally all the time. Unused bandwidth is shared with other users, but VPN users are given a higher priority in critical situations. If the bandwidth demand from VPN users exceeds the guaranteed capability, VPN users have to compete for the available resources as in any public switched Service. 5.1.1 Requirements. The basic VPN service described above may be unsatisfactory for the customer. Indeed, if the reserved capacity has been statically allocated on service provision, it may not be accurate, and the actual VPN usage may continually or repeatedly exceed the reserved capacity. Such a situation has two main consequences, first, the bandwidth-and thus the success of a call attempt -is no more guaranteed, and second, the supplementary bandwidth will be charged according to (higher) normal public service tariffs. .4s a consequence, the VPN customer requires

the ability to monitor the actual resource usage and therefore detect continuous or repeated overload/underload situations; the ability to increase or decrease the bandwidth allocated between any two VPN sites. 5.1.2 Purpose of the system. The bandwidth management service considered in this example aims at fulfilling the previous requirements, that is, at giving the VPN customer the ability to adapt the guaranteed communication resources between two sites according to their actual usage. For the sake of brevity, the capability to monitor resources usage will not be considered in this example. 5.1.3 Organizational

enterprise

model. An important step in modeling consists of identifying the orga-

264

J.-P. Gaspoz

J. SYSTEMS SOFTWARE 1996; 33:253-271

Cl C2 C3

: Customer Organization Community : VPN Bandwidth Management Community : Network Provider Community

Vpl VP Bw

: Virtual Private Line : Virtual Path : Bandwidth

CPN : Customer Premises Network VASP : Value Added Service Provider NP : Network Provider

Figure 13. Enterprise specification of the bandwidth management service.

nizational structure of the enterprise in terms of communities, enterprise objects, and roles these fulfill in the communities. At the highest level of abstraction, the VPN bandwidth management system and its environment are represented as enterprise objects in a community. The internal structure of both the system and its environment can be described by decomposing the initial enterprise objects into more detailed ones. The initial enterprise objects can thus be represented as a community at the new level of abstraction. The resulting organizational model comprises several enterprise objects, namely, the different actors, the bandwidth management services they provide or subscribe to, as well as the resources-logical or physical-affected by these services (Figure 13). This model illustrates that the VPN bandwidth mangement service is provided in a one-stopshopping way, that is, the customer only makes use

of the management service provided by the VASP that represents its single point of contact. The fact that this service is based on lower-level management services provided by one or more network providers is transparent to the customer. 5.1.4 Policies. Bandwidth management policies express in terms of a set of rules what the system has to do to achieve given goals. One of these goals is to meet customer requirements, that is, to provide the customer with the ability to modify the bandwidth allocated to the virtual private lines composing its VPN. Another goal is to make sure that the customer does not reserve more resources than the overall system can provide. Policies relevant in the present context are represented in Table 2. Although not formal, this policy specification template contributes to increase the degree of completeness and precision of the policies.

Table 2. Examples of Bandwidth Management Policies Subject

Modality

Activity

The customer

must

identify

a VPL

The customer

may

specify

the bandwidth amount to be added to/deducted from the VPL

The system

must

notify

the reasons of a bandwidth request rejection

The system

must

reject

a bandwidth

Constraints

Target that belongs

increase

request

to the community

if the bandwidth of any virtual path supporting the VPL cannot be increased

Methodology for Distributed Services

J. SYSTEMS SOFIWARE 1996; 33:253-271

5.1.5 Life cycle model. Scenarios of bandwidth management usage are now derived from the previous descriptions. Each of the communities constituting the environment of the system (see Figure 13) interacts with the system and may thus be represented as an agent. Obviously, any bandwidth update request affecting a given VPL has to be reflected on all virtual paths supporting that VPL. Consequently, customer requests to modify the bandwidth of a VPL have to be forwarded to each relevant network provider community. For the sake of brevity, the scenarios are directly represented using life-cycle expressions (Figure 14).

5.2 Information

Viewpoint

The first phase of information modeling aims at capturing the static data structures and relationships existing within the VPN bandwidth management system. The existence of a logical connectivity between two CPNs (Customer Premises Network) is modeled by the concept of a virtual private line. Two kinds of access points have been defined, each one being identified by a public network address. The mapping from overall VPN topology to the connectivity offered by the individual networks is performed, thanks to the concept of segment. Each segment represents a trail (ITU G.803, 19931, and its scope is limited to one single public network. The object model corresponding to the previous descriptions is represented in Figure 15. 5.2.1 Specialization associations. From the definitions of the entities that compose the abstract VPN model, different specialization associations may be identified. First, the class AccPt is a generalization of the two classes Cap and Icap. Further, a VPL is just a specific kind of segment that links two specific access points and spans over one single logical network, namely, the VPN. As a class inherits the relationships of its superclass, the previous specializations in fact give rise to implicit relationships that do not appear on the previous object model, e.g., a vpl implicitly has a bandwidth through its specialization association with the class segment. : (bw_increase

5.2.2 Operation model. The operation model allows the functionality that the customer expects from the VPN bandwidth management system to be specified. The operation schema for the system operation inc_vpl_bw is represented in Figure 16 and describes the effect this system operation has on the objects, attributes, and relationships defined in the object model, as well as the output events it generates. The specification is performed in a declarative way using pre- and postconditions. A special emphasis has been made on the use of relationships to track relatant instances. A specific and informal notation has been used for that purpose. Access to a relatant instance, knowing the relationship in which it participates and the subject instance, can be expressed as follows (name_of_object> relatant of (subject-role) (subject-name)

5.3 Computational

I bw_decrease)* I concurrent_enquiry)

=

inc_vpl_bw

bw_decrease

=

dec_vpl_bw

(#dec_bw_req)+

sequential-enquiry

=

#inc_bw_req

[inc_bw_resp

concurrent_enquiry

=

#inc_bw_req+

. inc_bw_resp+

life-cycle.

Viewpoint

The first step of computational modeling consists of identifying relevant computational objects and in

VplBandwidthUpdate

management

in (relationship_label)

5.2.3 Formal information specification. The final step of information modeling consists of giving a detailed and formal specification of the classes and relationships captured in the previous models, using the different ASN.l templates defined for that purpose. For the sake of brevity, and as the mapping from the graphical notation to the textual one is quite straightforward, only illustrative examples have been reproduced here (Figure 17).

bw_increase

Figure 14. VPN bandwidth

:

The input event inc_bw_resp has not been considered as a system operation in this specification. Indeed, this event is seen as the response in a request/response type of interaction initiated by the output event inc_bw_req. Concretely, this means that a synchronous type of interaction is assumed between the system considered and its lower level counterparts. Such an approach is especially appropriate when output events are sent concurrently to several agents.

Life Cycle

(sequential-enquiry

((#inc_bw_conf+

265

#vpl_bw_inc)

I (#Iinc_bw_disc+

#vpl_bw_rej))

#vpl_bw_dec #inc_bw_req]*

inc_bw_resp

266

J.-P. Gaspoz

J. SYSTEMS SOFTWARE 1996: 33:253-271

Operation Description Reads

inc_vpl_bw

: :

request the bandwidth of a vpl to be increased by a given amount. supplied supplied

:

s_cap_addr,

d_cap_addr:

E164address

/* source, destination

addresses

amount : INTEGER ,supplied resp_i : Boo1 (i = l..n) sourceCap : Cap with sourceCap.addr = s_cap_addr destCap : Cap with destCap.addr = d_cap_addr theVp1 relatant of node : {source-cap,dest_cap) in links (seg1, . . , seg_n) relatant of composite : theVp1 in contains trail-i relatant of lowerLevel : segi in maps-to (i = l..n) pubNw_i relatant of component : trail-i in contains (i = l..n) nms_i relatant of managed : pubNw_i in manages (i = I..n)

Sends

:

Figure

15. Object

[nms_i : inc_bw_req (i = l..n)], {customer : vpl_bw_inc, vpl_bw_rej)

:

Assumes Result

vplBw relatant of link : theVp1 in has segBw_i relatant of link : segi in has (i = l..n)

:

Changes

theVp1 exists

:

inc_bw_req (trail_i, amount) has been sent to nms_i (i = I..n) the responses inc_bw_resp (resp_i) from nms_i have been collected (i = l..n) If (resp_1 and resp_2 and ... and resp_n) then vplBw.peak has been increased by amount segBw_i.peak has been increased by amount (i = l..n) inc_bw_conf (trail-i) has been sent to nms_i (i = l..n) vpl_bw_inc has been sent to customer Otherwise inc_bw_disc (trail-i) has been sent to nms_i (i = l..n) vpl_bw_rej has been sent to customer

model for VPN topology.

defining how these objects interact to provide the desired system behavior specified in the operation model. As a starting point, a one-to-one mapping is assumed between information and computational objects. Based on this initial mapping, the behavior of the virtual path bandwidth management subsys-

tern upon reception of the inc_vpl_bw system operation has been distributed into a set of interacting objects (Figure 18). The sequence labels are Dewey Decimal numbers and have been derived from Coleman et al., (1994). Operations invocations labeled with the same se-

Nms

ti

c)

contains

Figure

16. Operation

schema

for ‘inc_vpl_bw’.

Cpn : Customer Premises Nemwork : Customer Access Point bP IcaP : Inter-Carrier Access Point AocPt : Access Point PubNw: Public Network : Virtual Private Network 2; : Virtual Private tine

Methodology for Distributed Services

Bandwidth

J.SYSTEMSSOFIWARE 1996;33:2.53-271

OBJECT-CLASS::=

links RELATIONSHIP

t

267

: :=

( ATTRIBUTES ACTIONS IDENTIFIED

OBJECT-CLASS IN ROLE WITH MULTIPLICITY RELATESTO OBJECT-CLASS IN ROLE WITH MULTIPLICITY IDENTIFIED BY

peak (k6vIncreased, bwD@XXaSed) bandwidthLb1

BY

I

bwDecreased

PARAMETERS PRECONDITIONS POSTCONDITIONS IDENTIFIED BY

AccPt node 2 links-1

1

::=

ACTION

s-t link 1

~alncum {Bandwidth.peakisgreaterOrEqualToamount) ((Bandwidth.peak)' =Bandwidth.peak-amount) ImDecreasedLbl

)

Figure 17. Example of class, relationship,

and action specifications.

quence label occur in an unspecified order. Letters appended to a sequence number define mutually exclusive alternatives. For instance, the operation discard_hw (1.2.2b) will not be invoked if operation cnf irm_bw (1.2.2a) is invoked and vice versa. Based on this computational objects interaction graphs and on a similar one for the converse operation dec_vpl_bw, a computational object type diagram can be issued. The interfaces offered and required by the different COs types are illustrated in this diagram (see Figure 19). It is interesting to note how relationships captured in the information viewpoint are represented in the

Customer‘

, ----f

__

btianager

previous diagrams. A few of them explicitly appear by means of a CO attribute identifying the computational counterpart of the relatant of its own information object counterpart in the original relationship. An example of such attributes is the attribute trailId of the CO type Segment, resulting from the existence of the relationship maps-to in the information viewpoint. Most relationships, however, result in the existence of a binding between selected instances of two computational object types. As relationships represent an operational coupling between two objects, it is pertinent that the existence of such a coupling in the information viewpoint gives rise to

vnTopology

Inc_vpl_bw 1.I Fn s-cap, d-cap, ---+ amount ; oul success : @ml)

search_vpl C s-cap, d-cap outtheVpl)

-

1.2.1

;

seg_l trail-id

1.2.1.1

nms_l >

) reserve_nw_bw (in amount ; out accepted : BooI) 1.2.2a.l -,-~~.------------I-,--’ 1.2.2a + mnr_bw_conf (ln trail-d) > ccnfirm_bw ()

th eVpl nbOfNetworks

1.2 -z

1.2.2b.l

1.2.2b * discard_bw ()

* inc_bw_disc @ trail-id)

increase_bw nms2 1.2.1.1 > inc_bw_req * resetve_nw_bw (in trail-id, amount ; on amount ; outaccepted:Bool) out accepted : @ml)

1.2.2a.l

__._._.............

Figure 18. C’omputational

object

interaction

graph for ‘inc_vpl_bw’.

1.2.2b.l

-. -.

-. -. -,--,-

.

_._._. _.

+ inc_bw_conf (In tra~l_ld) p inc_bw_disc (ln trail-id)

268

J.-P. Gaspoz

J. SYSTEMS SOFIWARE 1996: 33:253-271

1 Vpl -_1

ufxhteBwinieti increase_bw decrease_bw

Segment updateNwBwlnterl + reserve_nw_bw release_nw_bw 1 menegeReservhterf wnfirm_bw discard_bw

Nms manageTmilBwinted inc_bw_req dec_bw_mq inc_bw_conf inc_bw_disc

VplBw 1 setPeakBwlntell increasegeak reducegeek Figure 19. Computational

object type diagram

for VPN bandwidth management.

operational interactions between the corresponding objects in the computational viewpoint. Finally, CO types may be defined individually in a more precise way through the use of a textual CO template. An example of such a template is provided in Figure 20.

telecommunications services. For this purpose, the system is studied and described at hierarchically related abstraction levels, with the main benefit that at each level the goals achieved at higher levels of abstraction are preserved and can be used as a starting point to the definition of lower level abstraction models. In addition, the use of the objectoriented paradigm is advocated all along the development process. Consequently, this methodology combines the benefits of an object-oriented modeling, in particular, in terms of scalability and reusability with those provided by a top-down approach.

6. CONCLUSION The present methodology provides an architectural framework and a step-by-step approach from problem definition to the realization of distributed

object

template

attributes

Segment ident trailId

operations

void reserve_nw_bw(in INTEGERamount,out BOOLEANaccepted); void release_nw_bw (in INTEGER amount); void confirm_bw 0; void discard_bw (); initialization void init (in manageTrailBwInterf required

interfaces

refl , out UpdateNwBwInterf

ref2, out manageReservInterf

ref3);

templates

manageTrailBwInterf supported interfaces updateNwBwInterf manageReservInterf

templates = reserve_nw_bw, release_nw_bw = contikn_bw, discard_bw

behavior “An instance of this object template provides operations to manage bandwidth reservation and release of the trail it represents in the underlying network. On instantiation, this object receives a reference to the trail bandwidth management interface (manageTrailBwInterQ and instantiates its interfaces ‘updateNwBwInteff and ‘manageReserv1nkx-f’ and returns them as a result to its creator “ Figure 20. Computational

object template

for the segment

CO.

Methodology for Distributed Services Indeed, a top-down approach tends to decouple the specification and design of a service from its underlying infrastructure (Hall and Magedanz, 1993). Moreover, because its emphasis is on services and service requirements, such an approach ensures a high level of confidence that the users’ expectations on the system will be met. On the other hand, as the functionality of the system is not decomposed into elementary functions but actually distributed across interacting objects, the proposed approach avoids major top-down flaws such as neglecting data structures or not supporting the evolution of the system (Meyer, 1988). This methodology does not only combine state of the art approaches in the field of object-oriented software engineering and open distributed systems; it also makes use of recent developments in the domain of policies and object-oriented network information modeling. In addition, the best-suited notations-either graphical or textual or both-have been selected in each viewpoint to promote readability and formalism of the models to be developed. These notations form the basis upon which a CASE tool supporting the whole development process will be based. This tool, currently under development, will enable a syntatic validation of the models and consistency checks between different models. This includes, for instance, the verification that each output event identified in the life-cycle model is present in the Sends clause of at least one operation schema. In the same way, state changes described in the operation schemata should only involve entities specified in the object model. More comprehensive verification procedures, for instance, allowing behavioral validation of the specification, extend beyond the scope of this study. Such aspects have been addressed in Etique et al., (1995) as far as the fusion analysis phase is concerned. Due to its long-term perspective and generic nature, which makes it applicable to arbitrary application domains, the ODP reference model defines very general and abstract concepts whose scope and use are sometimes difficult to fully grasp. A significant part of this work has thus been devoted to the clarification and interpretation of these concepts in a telecommunications perspective. Moreover, ODP is not very prescriptive about the enterprise and information models because they have little impact on distribution. This does not mean that these models are less important. On the contrary, their definition is curcial to achieve a good understanding of the problem domain without which the identification of suitable solutions is fairly questionable. In addition, this solution provides more latitude for propos-

J. SYSTEMS SOFlWhRE 1996: 33:253-271

269

ing guidelines, models, and possible interpretations, and this methodology has thus quite naturally laid emphasis on these viewpoints. The framework of abstractions defined by ODP provides an approach to modeling but does not represent in itself a methodological support that can be used when specifying a distributed system. Moreover, ODP does not prescribe any ‘thirdparty’ methodology either. Actually, there is no well-established methodology supporting the development of ODP conformant specification and, precisely, the major aim of the present work has been to fill this existing methodological gap. Hence, there is not predominant methodology in the particular domain of distributed service engineering with which a thorough comparison could be performed. However, the same issue has been recently identified and addressed in Cornily et al., (1995). This article provides a methodology for the specification of transport network management services using the ODP framework. The proposed approach also advocates a top-down process, starting with the enterprise viewpoint, followed by the information viewpoint and finally the computational viewpoint. Textual notations are defined for each viewpoint but, similarly to our approach, a formal notation, namely Z, is proposed for the information viewpoint only. Fundamentally, both approaches are quite close and in particular rely on similar interpretations of the scope of the ODP viewpoints. For instance, the specification of behavior in the information and computational viewpoint is performed in the same way, namely, in terms of permitted state changes and computational objects interactions, respectively. The main difference comes from the resort to the fusion development process that confers on the present methodology a more consistent thread from problem definition to the realization of the distributed system. The methodology has been applied to the realization of a simple VPN service on top of DCE. Although this environment is far from fully realizing the promises of ODP, it has quite a similar computational model. As a consequence, the distributed application such as designed using our methodology could be deployed and executed in a quite straightforward way on DCE. It is worth mentioning, however, that the distributed application retained was quite simple and did not make an extensive use of advanced ODP mechanisms and transparencies. Thus, the access and location transparencies supported by DCE were sufficient in that context. The use of the C programming language to implement clients and servers on DCE did not make possible to

270

J.-P. Gaspoz

J. SYSTEMS SOFlWARE 1996; 33:2.53-271

fully exploit the benefits provided by the use of an object-oriented approach in the specification and design phases. Moreover, the present approach tends to give rise to fine-grained computational objects while DCE ‘objects’ are generally large-grained processes. In terms of granularity, DCE was probably not the best-suited environment to implement our computational model. The engineering and technology viewpoints have not been considered as an integral part of the present study because they are mainly aimed at defining the infrastructure providing selective distribution transparency. According to the assumption that such infrastructure as well as of compilers and tools allowing application components to be deployed and executed in an automated way will be available in a near future, the methodological support provided by this document has been focused on the enterprise, information and computational viewpoints. An important open issue would be to formalize the transitions between the different models advocated by our methodology. Indeed, the correspondence rules and guidelines are at the moment mostly informal. Adding formalism would improve the methodology be providing objective means to check the various models for completeness and consistency as well as a basis to automate some of these transitions. However, although beneficial, such a formalization is far from being a trivial work and has been left for further study. ACKNOWLEDGMENTS The author

would

for his support,

and Dr. Pierre-Alain article,

as well

helpful

comments.

the

framework

funded

like to thank

Professor

Professor

Tuncay

Jean-Pierre

Saydam,

Etique for the fruitful

as Dr. Staale

Wolland

Part of this work

of the

RACE

by the ‘OfficeFederal

project pour

Hubaux

Dr. Simon discussions

from

Telenor

has been PRISM

I’bducation

Znaty, on this for his

performed and

has

in

been

et la science’,

Switzerland.

REFERENCES ANSA, DPL Programmer’s Manual, ANSA Technical Report, APM Ltd., Cambridge, UK, 1993a. ANSA, An Overview of AnsaWare 4.1, APM Ltd., Cambridge, UK 1993b. Bapat, S., Object-Oriented Networks: Models for Architecture, Operations and Management, Prentice-Hall, 1994. Barr, W., Boyd, T., and Inoue, Y., The TINA Initiative, IEEE Communications Magazine, 70-76, (March 1993). Booth G., Object-Oriented Design with Applications, Benjamin Cummings, 1991. Coleman, D. et al., Object-Oriented Development: The Fusion Method, Prentice-Hall, 1994.

Cornily, J.-M. et al., “Guidelines for the Specification of Transport Network Management Services Using the Reference Model for Open Distributed Processing (RM-ODP)“, in Proceedings of TZNA ‘95, Melbourne, February 1995. Etique, P.-A., Saydam, T., Gaspoz, J.-P., and Hubaux, J.-P., Validation of an Object-Oriented Service Specification for the Intelligent Network, in Proceedings of TINA ‘95, Melbourne, February 1995. Hall, J., and Magedanz, T., Uniform modelling of management and telecommunication services in future telecommunication environment based on the ROSA Approach, in IFIP Transaction on Integrated Network Management III, North-Holland, 1993. IS0 10181-L Security Frameworks Overview, IS0 committee draft 10181-1, 1991. ITU G.803, Architecture of Transport Networks Based on the Synchronous Digital Hierarchy (SDH), ITU Rec. G.803, March 1993. ITU X.680, Information Technology-Abstract Syntax Notation One (ASN.l)-Specification of Basic Notation, ITU Rec. X.680, 1994. ITU X.681, Information Technology-Abstract Syntax Notation One (ASN.l)---Information Object Specification, ITU Rec. X.681, 1994. ITU X.901, Open Distributed Processing-Reference Model-Part 1: Overview, ITU Draft Rec. X.901, 1995. ITU X.902, Open Distributed Processing-Reference Model-Part 2: Foundations, ITU Rec. X.902, Feb. 1995. ITU X.903, Open Distributed Processing-Reference Model-Part 3: Architecture, ITU Rec. X.903, Feb. 1995. Jacobson, I., Object-Oriented Software Engineering, Addison-Wesley, 1992. Kelly, E., and Mercouroff, N., TINA-C DPE Architecture and Tools, in Proceedings of TINA ‘95, Melbourne, February 1995. Lamport, L., The Temporal Logic of Actions, ACM Transactions on Programming Languages and Systems, vol. 16, (April 1994). Linington, P. F., Introduction to the ODP Basic Reference Model, in Proceedings of ICODP’93, Berlin, 1993. Meyer, B., Object-Oriented Software Construction, Prentice-Hall, 1988. PRISM, Reports on Selected Areas of the Service Management Reference Configuration, RACE project R2041 PRISM Deliverable 8, September 1994. Raymond, K., Reference Model of Open Distributed Processing, in Proceedings of ICODP’93, Berlin, 1993. ROSA, The Specification of IBC Services Using ObjectOrientation, RACE project R1093 ROSA, Deliverable 1, April 1991. Rubin, H., and Natarajan, N., A Distributed Software Architecture for Telecommunications Network, IEEE Network, Jan-Feb. (1994).

Methodology for Distributed Services Rumbaugh, .I. et al., Object-Oriented Modeling and Design, Prentice-Hall, Englewood Cliffs, 1991. Saydam, T., Gaspoz, J.-P. Etique, P.-A., and Hubaux J.-P., Object-Oriented Design of a VPN Bandwidth Management System, in Proceedings of ISINM’95, May 1995. van Sinderen, M., et al., Design Concepts for Open Distributed Systems, position paper on Architectural Semantics, in Proceedings of ICODP’93, Berlin, 1993.

J. SYSTEMS SOFTWARE 1996: 33:253-271

271

Steedman, D., ASN.1: The Tutorial and Reference, Technology Appraisals, The Camelot Press, 1990. SYSMAN, Domain and Policy Service Specification, ESPRIT III SysMan Deliverable MA2V2, October 1993. Wies, R., Policies in Networks and Systems Management -Formal Definition and Architecture, Journal of Network and Systems Management 2, 63-84 (1994).