1

Application of UML within the Scope of new Telecommunication Architectures

Dr. Eckhardt Holz Humboldt-Universitt zu Berlin Institut fr Informatik A.-Springer-Str.54a 10117 Berlin - Germany [email protected]

Introduction

The telecommunication market is one of the fastest growing markets in the last years. Deregulation in the provider market, new techniques and user demands lead to more exibility but require also the coexistence of legacy telecommunication systems with new and more advanced technologies. Although being known conservative in the introduction of new technologies, the new requirements have forced the industry to increase the time-to-market for new services and to apply new reference architectures. This paper investigates, how the new object oriented modelling language UML (Unied Modelling Language) can be applied in this domain.

Telecommunication Systems

Telecommunication systems can be roughly divide into three main areas: Communication protocols, telecommunication services and telecommunication management systems. A fourth group, which will not considered here, comprises basic hard- and software (switches, routers) and customer premises equipment. Communication protocols include signalling protocols used to setup, control and tear down calls and connections and transport protocols used to transmit data between participants in a telecommunication system. Telecommunication services may be provided by the network operator (telecommunication company) or by 3rd parties. Typical current day examples include call-forwarding, voice-mail, video-conference etc. Management systems are used to control and administer telecommunication systems, Usual tasks here are authorization, authentication, subscription/unsubscription and billing. The last years witness an increasing fading of the traditional boarders between telecommunications systems and information processing distributed computer networks. Common reference models as ODP lead to similar domain specic solutions and standards. Two major players are OMGs CORBA and the public network operatorss TINA. Due to the fact that telecommunication systems of different network providers have to cooperate worldwide, standardization of protocols, interfaces and services is necessary. Examples for such standards resp. families of standards are ISDN (Integrated Services Digital Networks),

3 Modelling Concepts of RM-ODP and TINA

Broadband-ISDN, IN (Intelligent Network) or TMN (Telecommunication Management Network).

2.1 Reference Models and Description Techniques

Reference models serve as a framework for the development of telecommunication systems and standards. They provide an abstract architecture and a common terminology limiting thus the universe of discourse. The most recent result in the development of such reference models is the Reference Model of Open Distributed Processing (RM-ODP), which was a joint standardization activity of ITU-T and ISO. It clearly reects the shift of the focus away from pure protocols and services towards open systems of distributed objects. The abstract infrastructure dened here enables objects to interact at there interfaces with other objects. To cope with the complexity of distributed systems the concept of viewpoints and transparencies has been introduced. Two other standardization activities related to the RM-ODP are Common Object Request Broker Architecture (CORBA) by the OMG and Telecommunications Information Networking Architecture (TINA) by TINA-C. The purpose of these industry consortia is the employment of ODP to concrete application areas (distributed computer systems, telecommunication). For the formalization of the standards as well as for the development of applications a series of different description and specication techniques is applied. Most notably are here SDL (ITU-T Specication and Description Language ) and MSC (message Sequence Charts). Both are formal techniques developed by ITU-T and do nd an increasing use. However, plain english text is still extensively used.

Protocols

Management

ASN.1 SDL MSC

Estelle Lotos

PET
OMT

GDMO

Services
Figure 2.1 Description techniques for telecommunication systems

Modelling Concepts of RM-ODP and TINA

The development of the Reference Model for Open Distributed Processing (RM-ODP) is an ongoing joint standardization activity of ITU-T and ISO. It aims at a framework to organize services within autonomous systems in order to facilitate interworking of software components distributed into larger and larger systems. The RM-ODP provides:
I a general modelling approach and a set of general concepts I a method to divide a specication into ve viewpoints in order to simplify the specication process

Concepts

The RM-ODP standard is divided into four main parts:

1. 2. 3. 4. Part 1 - Overview and Guide to Use Part 2 - Foundations Part 3 - Architecture Part 4 - Architectural Semantics

A series of related standards dening languages and ODP components is currently under development, especially the ODP Trader and the Interface Denition Language (IDL). Although still in development the ODP standard has already inuenced major developments in the area of distributed and telecommunication systems. The Telecommunication Information Network Architecture (TINA) is strongly applying the concepts of ODP. The following sections will give a short introduction into ODP/TINA and its concepts.

3.1 Concepts
Objects and actions are the most basic modelling concepts of ODP. An object as a model of an entity is characterized dually by its behaviour and its state. A change in an objects state can only occur as a result of an internal action or an interaction with its environment (encapsulation). Such interactions with the objects environment occur at interaction points. Interfaces form partitions of the interactions of an object, they are abstractions of the behaviour of objects consisting of a subset of the interactions together with a set of constraints on when they may occur. Informally, objects are said to perform functions and offer services. A service specication captures e.g. data representation, transport protocol, location etc. To hide the aspects of a system that arise through its distribution an ODP infrastructure supports a set of distribution transparencies. Developers of applications can concentrate on the design of their application without addressing distribution aspects. Some important distribution transparencies are:
Access Transparency Location Transparency Migration Transparency.

The management of the large amount of information usually involved in the complete specication of a complex distributed system is addressed by the concept of viewpoints. Viewpoints are separations of concern. They give a partial view of the complete system specication. Five different viewpoints are identied in the RM-ODP:
I I I I I

Information viewpoint Enterprise viewpoint Computational viewpoint Engineering viewpoint Technology viewpoint.

Each viewpoint is associated with a viewpoint language expressing the rules which are relevant to the respective universe of discourse. To verify the conformance between real implementations and specications and the compliance between two specications the RM-ODP introduces the concept of reference points. Reference points are selected interaction points serving as potential conformance points. Four different classes of reference points have been introduced:
Programmatic Reference Points Perceptual Reference Points Interworking Reference Point Interchange Reference Point

3 Modelling Concepts of RM-ODP and TINA

Additional information required when testing an implementation of an ODP specication is called Implementation eXtra Information for Testing (IXIT). Those information relate Implementation Conformance Statements (ICS) - i.e conformance points, required behaviour etc. to their realization in an implementation. In order to test the conformance of an implementation under test the tester has to provide sets of IXITs and ICS relating the concepts and structures of the enterprise, information and computational specication of the system to its engineering specication and a set of IXITs and ICS relating the concepts and structures of the engineering specication to the implementation choices made in the technology specication/implementation. The RM-ODP denes concepts and common functions of distributed systems in a generic manner. Renements and specializations of this model are explicitly encouraged and are currently under way (e.g. TINA-C). Standards for the realization of common functions, so called component standards, ll out the framework and are providing a base for the development of ODP applications. The Trader standard is one of the central component standards. It has reached the status of an International standard.

3.2 ODP Viewpoints

The viewpoint concept is essential for the whole RM-ODP. Each viewpoint is focusing on a subset of the properties of the system (cf. Table 1). The viewpoint concept can be applied at Viewpoint
Enterprise viewpoint
purpose scope policies

Focus on

Information viewpoint

semantics of information information processing

Computational viewpoint

functional decomposition objects interacting at interfaces

Engineering viewpoint

mechanisms/functions required to support distributed interactions between objects choice of technology Table 1: ODP viewpoints and their focus

Technology viewpoint

large at the whole system or at a different level of abstraction to individual components of the system. The RM-ODP does not dene a general mapping or correspondence between every pair of viewpoint languages, however, special relationships between the computational and information resp. the computational and engineering viewpoint are identied. The RM-ODP does also not prescribe any chronological order for the development of specications for the different viewpoints, on the contrary - it favours a parallel development of the specications. Nevertheless, a development process starting with the enterprise specication, followed by (possibly interleaved) specication of information, computational and engineering viewpoints and con-

ODP Viewpoints

cluded by the technology specication seems to be an adequate way for the development of ODP systems. Part 3 of the RM-ODP contains the abstract denition of the viewpoint languages. A concrete syntax for these languages is not given, the language denitions contain only the concepts and rules for the specication from the selected viewpoint. This allows to use existing or evolving languages/notation techniques as concrete viewpoint languages. The languages envisaged here range from natural languages over programming languages to formal description techniques (FDT). Mappings between the computational and information languages and the standardized FDTs SDL-92, LOTOS, Estelle, Z and ACT.ONE are given in Part-4 of RM-ODP.

3.2.1 Enterprise viewpoint

An enterprise specication presents an ODP system and its environment as a community. The community is specied in terms of roles played by the objects of the community, the policies governing interaction, creation/deletion and conguration and the activities undertaken by the system. Fullling a role implies for an object that it becomes subject to permissions, obligations and prohibitions.

3.2.2 Information viewpoint

The main concept for the description of the semantics of information and informationprocessing is the scheme. Three different kinds of schemes are dened for the information language:
Invariant Schema Static Schema Dynamic Schema.

A template of an information object references to all three of these schemes. The invariant schema is a set of predicates constraining the possible states and state changes of an object. The static schema species a state of an information object and the dynamic schema the allowable state changes of that object. Schemes may apply to a single object or to a set of objects. Information object templates may be atomic (lowest level of abstraction) or are represented as a composition of other information object templates. An information specication needs not be apt for distribution.

3.2.3 Computational viewpoint

The computational viewpoint species the functional decomposition of an ODP system. ODP applications and functions are dened in terms of computational objects interacting at interfaces. Computational interfaces are divided into stream interfaces (continuous information ows between producer and consumer) and operational interfaces (support of announcements and interrogations). A computational object may have multiple interfaces. In order for two computational object to interact, both objects have to provide the appropriate complementary interfaces and a binding between these interfaces must exist. Each attempt for interaction at an unbound interface fails. The computational language distinguishes between primitive binding and compound binding. Primitive binding enables the binding between two interfaces whereas compound binding connects a set of interfaces. In the latter case special binding objects support the binding. The computational language denes rules for the structure of a computational specication, for the interactions, the binding as well as failure and portability rules. Computational objects are potential candidates for distribution.

4 Viewpoint Specification with UML

3.2.4 Engineering viewpoint

In the engineering viewpoint an abstract infrastructure is dened to support the distribution of an ODP system. The specication is expressed in terms of engineering objects, activities within these objects and interactions between them. The engineering languages imposes a structuring of the conguration of engineering objects into clusters, capsules and nodes. The atomic objects are the basic engineering objects (i.e. objects that require the support of a distributed infrastructure).

E E

E CLM
CLM

Basic Engineering Object Cluster Manager Capsule Manager Nucleus Cluster

CLM CPM

CLM

CLM CPM

CPM N

Capsule Node
Figure 3.1 Structure of an engineering specication

Channels provide the means for the binding of interfaces of basic engineering objects. A channel is structured in stubs, binders protocol objects and interceptors.
Client Server

Control Interfaces Stub Binder Protocol O. Interceptor Protocol O. Stub Binder

Figure 3.2 Engineering channel

3.2.5 Technology viewpoint

A technology specication expresses how the specications of an ODP system are implemented (e.g. programming language, infrastructure etc.) and denes the information required for testing from an implementors view (IXITs).

Viewpoint Specification with UML

The specication and description of telecommunication systems can serve different purposes, which strongly inuence the style of the specication. Standards and public specications (i.e. specications to be submitted to 3rd parties) have due to competition grounds a very descrip-

Enterprise viewpoint

tive nature. They do not prescribe any concrete implementation and hide technical solutions. Design specications on the other side are prescriptive and will nally lead to an implementation. Within this paper mainly standard specications will be considered. Object oriented analysis and design techniques (OOAD) have been applied successfully for the development of large applications. Their advantage is that the object oriented paradigm is consistently applied through all stages of the design up to the implementation. The development of UML has now also adopted some key concepts for the development of distributed systems, e.g. interface and exception. This leads to the question whether UML is suited as a concrete viewpoint language for some or all viewpoints. First attempts to apply OOAD for the specication of viewpoints have been made by ODP and TINA-C, however this is restricted to the information viewpoint only. In both cases only the class diagrams of OMT, one predecessor of UML, have been used. The remaining part gives an outline, how the different models of UML can be applied within different viewpoints and how those viewpoint specications can be related. The Trader is used as an example to explain the chosen approach. This example was selected due to the existence of a complete and standardized specication in the enterprise, information and computational viewpoint and its importance for distributed systems. The Trader allows server objects to advertise their services and client objects to nd services they need. This supports the concept of openness in distributed systems by enabling the dynamic introduction, removal or modication of servers and clients.

4.1 Enterprise viewpoint

In the engineering viewpoint a trading system is seen as a community which references 5 difCommunity Trading Community

ROLE Service Offer

ROLE Exporter

ROLE Importer

ROLE Trader

ROLE Trader Administrator

Trading Community Service Export Exporter

Trader Service Import Importer

Figure 4.1

ferent roles which objects can play within the community. These roles are Exporter/Importer, Service Offer, Trader and Trader Administrator. Objects participating in a trader community may play more than one role, i.g. an exporter of some services may be importer for some other services, a trader itself may be an importer of another trading community. For administrative or technical reasons a trader community can be subdivided into other trader communities. The

4 Viewpoint Specification with UML

different activities of the trading community are reected by use cases. The behaviour of the
ServiceExport Exporter CreateService exportService(description) ServiceOffer newEntry importService(description) nd(description) serviceOffer Service::foo() withdraw(offerID) delete importService(description) nd(description) noMatchingService
Figure 4.2

ServiceImport Trader Importer

offerID

verifyPolicies authorized

single use cases may be specied by sequence charts as shown in Figure 4.2 or by collaboration diagrams.

4.2 Information viewpoint

An information specication is given as a conguration of information objects. A template for an information objects references invariant, static and dynamic schemata. The static and invariant schemata are represented in UML by classes and objects, the dynamic schemata are additionally reected by a set of state diagrams. A Trading systems consists of a conguration of interconnected nodes, which are used to parti{Invariant Scheme}

Trading System

* nodes Node 1 partition *

offers

ServiceOffer

Initialize { Static Scheme card(offers) = 0, card (nodes) = 0 }

edges Edge_properties
Figure 4.3

Type Set

tion the set of service offers. Each service offer belongs to exactly one node. Initially a trading system does not have nodes or service offers (static scheme initialize). In Figure 4.3 an exam-

Computational viewpoint

ple for a dynamic scheme is given in form of a collaboration diagram. It shows, how the state of the trading system is changed by the operation export. The OCL notation has been applied to formulate constraints and conditions. A Trader object template will reference a series of

:Trading Community

:Trading System updated offers new newOffer:ServiceOffer 2.1/A2: updateOffers(newOffer) new partition

exporter: Exporter

1:offer_id:=export(newOffer) Exception [offers->exists(o| o=newOffer)] 2.2:ExportError myTrader:Trader nodes node:Node 2.1/A1: createPartition(newOffer) [not offers->exists(o| o=newOffer)] 2.1: node:=detect(node)
Figure 4.4

such collaboration diagrams (dynamic schemes), one for each trader operation. Alternatively activity diagrams or state diagrams may be used.

4.3 Computational viewpoint

In the computational viewpoint the system is divided into objects which are potential candidates for distribution. These objects may interact at their interfaces. The object behaviour and the interactions are governed by contracts. Consequently the computational object template for a Trader references the trader behaviour, an environment contract and a set of templates for trader interfaces. The different kinds of trader interfaces can be classied using a generalizaCO Template TraderObjectTemplate 1 TraderBehaviour 1 EnvironmentContract * TraderInterfaces

Interface TraderInterfaces ... Interface SupportAttributes ...

Interface TraderComponents

Interface LookUpInterface

Interface RegisterInterface

Figure 4.5

tion/specialization hierarchy. In Figure 4.6 one concrete realization of the trader template, the FullServiceTrader, is shown. It provides all different Trader Interfaces, some of them may have multiple interface instances (e.g. OfferIterator). By attaching the stereotype Implementation

TraderObjectTemplate

Implementation Class FullServiceTrader LookUp Register Admin Link Proxy * * OfferIterator OfferIDIterator LookUpClient *

LookUpInterface implementation class RegisterInterface AdminInterface LinkInterface FullServiceTrader ProxyInterface OfferInteratorInterface OfferIDIteratorInterface uses Interface LookUpInterface
Figure 4.6

Class it is indicated that FullServiceTrader is candidate for implementation as a single object within a distributed system. The behaviour of the object can be specied by statecharts, its behaviour in relation to other objects by collaboration diagrams or (as shown in Figure 4.7) by
FullServiceTrader::LookUpInterface::Query(ServiceType, Constraints, Policies,...) Exporter FullServiceTrader LookUp Query VerifyPolicies [follow_link] [NOT follow_link] OfferIterator CollectResults OfferIterator Query Link LookUpClient Trader

Figure 4.7

activity diagrams with swimlanes. It is clearly visible here, how the export operation is propagated to the FullServiceTrader and from there to other Traders of the community.

Conclusions

As an object oriented modelling language UML is well suited for the specication of object oriented systems. The direct reection of many concepts, the variety of models supported and the semantics make it to one candidate for the specication of viewpoints in the telecommunication domain. By applying the same technique to different viewpoints, the specications will be better understandable and the learning effort will be decreased. At the same time the transition between different viewpoints will be eased. The extension features of UML (e.g. stereotypes) make it possible to tailor the language to the application area, gaining more compact specications. This could be supported by libraries/ packages of predened concepts. Tool support is a must for the specication and development of large systems. Currently a series of companies have started to develop tools for UML, supporting not only the specication development, but also code generation and reengineering. Especially the last two topics are of increasing importance. The pure generation of pure code skeletons is not sufcient, code generation for the behaviour parts is required too (and supported by non-UML tools used in the telecommunications industry). Nevertheless, the use of UML in the telecommunication domain is not without problems. Most of them stem from differences in the semantics of concepts. Whereas in UML interfaces are a pure typing concepts, ODP and TINA support interfaces as a more structural concept. They may be instantiated, deleted and addressed. Interactions between complementary interfaces (client/server) requires a dynamic binding of interfaces, what is also not supported by UML. This binding concept is an important feature for the specication of distributed and telecommunication systems. It abstractly models the different communication relations (calls, connections) and enables the dynamic reconguration and the evolution of such systems. Other important features missing in UML are models for continuous data communication (streams), which are needed for multimedia systems. This comprises not only different connectivity kinds (one-two-one, one-to-many or multipoint-to-multipoint) but also bundling of stream ows, synchronisation or splitting of streams.

Related Work

The application of oo techniques in the telecommunications industry is still in its introduction phases. Some important directions are the object oriented extensions to SDL (SDL-92, SDL-96), standardized by the ITU-T and combinations of SDL and OMT. These efforts do increase the importance of SDL in this application domain and make this language to a strong competitor to UML. However, it can be expected that UML will be used instead of OMT. Another development concerns object and interface denition languages. The language IDL, developed by OMG, is now a joint standard of ITU-T and ISO, the language ODL (Object Definition Language, developed by TINA-C is expected to become an ITU standard in near future (1998/1999).

References

ITU-T Rec. X.901 | ISO/IEC 10746-1: Open Distributed Processing - Reference Model Part 1: Overview, ITUT 95 ITU-T Rec. X.902 | ISO/IEC 10746-2: Open Distributed Processing - Reference Model Part 2: Descriptive Model, ITU-T 95 ITU-T Rec. X.903 | ISO/IEC 10746-3: Open Distributed Processing - Reference Model Part 3: Prescriptive Model ITU-T 95 ITU-T Rec. X.904 | ISO/IEC 10746-4: Open Distributed Processing - Reference Model Part 2: Architectural Semantics, ITU-T 95 ISO/IEC CD 14750Open Distributed Processing - Interface Denition Language, ISO/ITU-T DIS 96 ITU-T Rec. X.950 | ISO/IEC 13235: Open Distributed Processing - Reference Model ODP Trading Function ITU-T 95 ITU-T Rec. Z.100: ITU-T Specication and Description Language, ITU-T, 1992 Rational: UML Semantics V1.1, 1997 Rational: UML Notation Guide V1.1, 1997 TINA-C Overall Concepts and Principles of TINA, TINA-C 1994 TINA-C:Object Denition Language - Manual Version 2.3, TINA-C, 1996 TINA-C:Computational Modeling Concepts, TINA-C, 1996