Comparative Case Study in SDL and UML

Philippe Leblanc1 Ileana Ober1,2

1Telelogic Technologies Toulouse150, r. Vauquelin, BP 1310

31081 Toulouse Cedex, FranceE-mail: {philippe.leblanc, ileana.ober}@telelogic.com

2Institut National Polytechnique de ToulouseLaboratoire d'Informatique et Mathématiques Appliquées

2, rue Camichel – BP 712231071 Toulouse - France

Abstract

Choosing the right modeling language for developing a system may be a difficult task,which might influence on the cost and quality of the whole subsequent development process.UML and SDL are two of the most widely used modeling languages. The purpose of thispaper is to help the modeler decide which of UML and SDL is more appropriate for theparticular problem he has to solve, depending on its characteristics. This paper is rooted ina case study, a simplified switching system that we have modeled in SDL-96, UML and SDL-2000. The three models developed in parallel offer a basis for comparing the threelanguages. The SDL-2000 case study presents an additional interest, since it is one of thefirst examples of a recently released standard and no example is provided to illustrate it.Based on the parallel case studies we discuss the fitness of SDL-96, UML and SDL-2000 forspecific application domains.

1. Introduction

UML, the Unified Modeling Language [6, 9] is a language for modeling object-orientedsystems, specified by the Object Management Group (OMG). UML is a general-purposevisual modeling language, which offers a convenient graphical notation and some generalconcepts for modeling and documenting software systems. UML is broadly used in themodeling of all kinds of systems and there are a large number of tools that support thislanguage. Up-to-date and complete information about UML can be found at the OMG officialweb site: www.omg.org.

SDL, the Specification and Description Language [4], is a formal and visual modelingtechnique standardized by the International Telecom Union (ITU), intended for unambiguousspecification and description of telecom, distributed and embedded systems. The language ismainly based on the concept of extended finite state machines and includes concepts forbehavior and data description, for complex system structuring, a visual action language andan execution model. SDL-96, benefited from an extended support of commercial software

0-7695-0731-X/00 $10.00 � 2000 IEEE

tools and is now widely used for the engineering of real-time systems, providing applicationdesigners with capabilities for model testing and autocoding.

The latest version of the SDL, called SDL-2000 [5], has been delivered by the ITU inNovember 1999. It includes most of the state-of-the-art OO modeling concepts, similar tothose specified in the UML, Statechart concepts such as composite state, entry, and exitactions. The data model has been updated in order to include concepts such as class,inheritance, and polymorphism. Structuring mechanisms have been extended with theintroduction of interfaces and the generalization of the concept of agent type (which is theSDL-2000 equivalent of the active class). Additionally, SDL-2000 integrates the UML visualrepresentation, each time it is relevant, e.g. for agent and data class.

This paper is addressed to people that have some knowledge in the field of systemmodeling and are interested by a comparative case study of SDL-96, SDL-2000, and UMLand a discussion on the appropriateness to use each of them when specifying a systemdepending on the domain it refers to.

As SDL-2000 is a quite new standard and, as far as we know, no examples are available,the section describing the example in SDL-2000 may be interesting by itself. Moreinformation on SDL and references to introductory materials can be found at the SDL forumweb site: http://www.sdl-forum.org.

Section 2 of this paper contains a description of the example we will use. The descriptionrefers to its structure and to its expected behavior given through a sequence diagram.

Section 3 contains the actual modeling of the considered example. It presents the SDL-96model (3.1.), the UML model (3.2.), and the SDL-2000 model (3.3.). Each of these sectionscontains a larger discussion on the benefits and drawbacks of using that approach. In Section4 we discuss the relationship between the modeling language to be used for a system and thecharacteristics of that system. We present some final remarks and conclusions in Section 5.

2. The LSB example

The example we will use to illustrate the application of SDL-96, UML, and SDL-2000 toreal-time software engineering is a Local Switch Board (LSB) (a complete SDL modeling ofan LSB variant is detailed in [3] and its UML and SDL-2000 modeling can be obtained fromthe authors).

2.1. LSB specification

The LSB purpose is to connect users locally, with each other. External calls, i.e. calls notbetween local users, are out of the scope of this example. A user interacts with the LSBthrough his/her phone. The LSB is a simple one, where phone lines and phone numbers areallocated statically at the system startup in a permanent way.

Static requirementsLSB supports up to 9 local lines, numbered from 1 to 9. The signals passed from user

phones to LSB are: OffHook, OnHook, and DialedDigit, while the signals passed from LSBto user’s phones: DialTone, BusyTone, RingTone, and ConnectTone.

When an action is expected from a user, he/she must react within maximum 15 seconds.

Behavioral requirements with Sequence diagramsTo exemplify the expected behavior we could use either UML or SDL sequence diagrams.

Since the two contain virtually the same amount of information, we present the SDLSequence diagrams only. Figure 1 exemplifies what happens when the user U1, connected to

0-7695-0731-X/00 $10.00 � 2000 IEEE

1calls2_then_stops

OffHook

DialTone

DialedDigit(2)RingTone

RingTone

OffHookConnectTone

OnHookBusyTone

OnHook

U1:User

conversation_1_2conversation_1_2

myLSB:LSB

conversation_1_2conversation_1_2

U2:User

free

conversation_1_2

Figure 1. U1 calls U2, and U2 is free and answers the call

2busy

OffHook

DialTone

DialedDigit(2

BusyTone

OnHook

U1:User myLSB:LSB U2:User

busy

Figure 2. U1 calls U2, and U2 is busy

the 1st line, calls the user U2, connected to the 2nd line and U2 is free and answers the call.Figure 2 exemplifies what happens when the user U1, calls the user U2, and U2 is busy.

2.2. Design choices

We choose to design the system in an object-oriented manner: each communication ishandled by a specific object, each phone line is handled by a specific object, and there is asupervisor object allocating communication objects to phone line objects according to users’inputs.

The OO design must be flexible enough to allow several object distributions on the targetplatform, and to make further evolution easy (for instance adding new services to the LSB).

2.3. Running system

Figure 3 below shows the system running. 1 has initiated a communication with 2, 3 with5, and 8 is about to start a communication.

3. Modeling techniques

In this section we will describe the actual modeling of the LSB using SDL-96, UML, andSDL-2000. We will not present all the details of the models, but we will try to choose themost illustrative features. On the other hand the example is not intended to illustrate all thefeatures of SDL-96, UML, and SDL-2000.

3.1. Modeling in SDL-96

In SDL-96 the topmost hierarchic entity is the system, which can be hierarchicallydecomposed into intermediate entities called blocks. A block can further contain other blocksor processes (leaf entities). Each process contains a state machine that describes its behavior.Entities communicate with each other by exchanging signals, which are conveyed bychannels, that can connect various entities.

0-7695-0731-X/00 $10.00 � 2000 IEEE

ConnAgent(1)

ConnAgent(2)

ConnAgent(3)

Manager

aLine(1)

aLine(2)

aLine(3)

aLine(4)

aLine(5)

aLine(6)

aLine(7)

aLine(8)

aLine(9)

1 calls 2

3 calls 5

8 offhook

Local Switch Board

Figure 3. A running configuration: the following pair ofconnections exist: (1,2), (3,5), and 8 prepares to call

signal PhoneId, PhoneNb (Digit);signal ConnReq, ConnFree, ConnBusy, ConnEstablish, ConnEnd;signallist ConnSig = ConnReq, ConnFree, ConnBusy, ConnEstablish, ConnEnd;

signal DialTone, RingTone, BusyTone, ConnectTone;signallist Tone = DialTone, RingTone, BusyTone, ConnectTone;

signal OffHook, OnHook, DialedDigit(Digit);signallist PhoneEvt = OffHook, OnHook, DialedDigit;

Figure 4. The signals used in the SDLspecification of LSB

A possible SDL-96 modeling of the LSB is the one described in Figure 5, the used signalsare defined in Figure 4. The LSB system has two blocks one to model the switch and one tomodel the line handler. An SDL block is a structural entity that may contain processes(active entities) or other blocks. The two communicate by mutually exchanging messages andthe line handler also exchanges messages with the environment. The line handler blockcontains a process, line that describes the reactive behavior of a line, through a state machineand three procedures: called, connected, and calling. The switch block describes the actualbehavior of the switch. Concretely, it is composed of connection agent that monitors a localcall and connection manager that receives connection requests from users and allocatesconnection agents accordingly. Figure 6 depicts the line handler’s state machine using thetypical SDL-96 visual notation.

DiscussionNote that in SDL-96 we can work directly at instance level to describe both the structure

and the behavior of the system. As we will see in the sequel, this is not the case in UML.SDL-96 offers the means to describe very precise details about the run-time system, like

the initial configuration of objects, or the channels that link the different entities and know,without further implication of the designer, how to route signals from one entity to another.

In SDL-96 the system description gives all the possible combinations of instances thatmay exist at run time (their number, all possible communication paths, etc). Once a system isdefined, instances can only behave in the strict manner they have been specified at systemlevel. Whereas in UML, an object can virtually communicate with any object and can createobjects based on all the classes it can see.

Although not noticeable in the presented diagrams, SDL-96 offers precise means to dealwith time duration, which makes it appropriate for domains that emphasize timing aspects,such as real-time systems.

This precise instance-level description is doubled by a precise semantics of all the SDL-96concepts, which is used by the advanced features that exist in most SDL-96 tools: simulation,formal verification, and automatic test generation and execution.

The behavior is described by flat state machines. Unlike in UML or SDL-2000, there areno composite or concurrent states within a state machine. SDL-96 procedures offer somemeans of structuring a state machine.

0-7695-0731-X/00 $10.00 � 2000 IEEE

system LSB_basic

USE Defs; USE Line_pack; USE Switch_pack;

/* Requirements */

connLink

ConnReq,(Tone)

(ConnSig)

initLink

PhoneNb

PhoneId

phoneLines(Tone)

(PhoneEvt)

switch:Switch_t

USSI

lineHandler (NbOfLines):LineHandler_t

UC

LH

IC

Figure 5. Basic structure of the LSB system

VIRTUAL process type Line_sm

TIMER tUser := T_15s;DCL myPhNb Digit;DCL agentId Pid := Null;

imported procedure CreateAgent;fpar in Digit;returns Pid;

ICPhoneNb

PhoneId

UC ConnReq,(Tone)

(ConnSig)

LH(PhoneEvt)

(Tone)

virtualCalling

virtualCalled

virtualConnected

virtual

PhoneId

init

PhoneNb(myPhNb)

idle

idle

virtualOffHook

Calling

agentId := Null

idle

virtualConnReq

agentId := Sender

Called

Figure 6. State machine diagram of process line

While SDL-96 offers powerful modeling constructs instance level its expressing power attype level is quite limited. Although most of the instance-level constructs have correspondingtype-level concepts (system type, block type, process type, and state type) and inheritancerelationships can be defined among these types, the type level concepts are different fromwhat they usually are in OO models (a type must explicitly be defined as inheritable,inheritance is not an “is a” relation, etc.).

As a consequence, SDL-96 offers limited means to describe taxonomic hierarchies. Thefact that SDL-96 is unfriendly at type level makes reuse equally difficult and does not coverthe early phases of the analysis and design.

In the case when the type level modeling is important and one needs reuse andextensibility capabilities, a “more” object-oriented modeling language should be considered.

3.2. Modeling in UML

The LSB description in UML is focused on the type level; therefore the main classdiagram (see Figure 7) contains the classes that describe the LSB and the relationships thatconnect them.

The UML notation offers a clearer view of the classes composing the system, by making iteasier to understand the relationships that exist between the entities of a system. Besides,using UML means to use a widespread modeling language with all the not quantifiableadvantages it brings with: better trained people, a greater diversity of tools supporting it, etc.

The described system needs to handle some signals, as described in the class diagram inFigure 7. Signals Tone, PhoneEvt, and ConnSig are abstract signals that are specialized intoactual signals. The signal DialedDigit has a parameter digit, which models the dialed digit.

Unfortunately, UML offers weak means to go from type to instance level. Unlike in SDL,it is almost impossible to specify the communication inside the system or with theenvironment (there is no notion of environment in UML). There are means only to specify

0-7695-0731-X/00 $10.00 � 2000 IEEE

<<Signal>>Tone

<<Signal>>ConnReq <<Signal>>

ConnSig

<<Signal>>ConnFree

<<Signal>>ConnBusy

<<Signal>>RingTone

<<Signal>>ConnEstablish

<<Signal>>ConnEnd

<<Signal>>DialTone

<<Signal>>RingTone

<<Signal>>PhoneEvt

<<Signal>>OnHook

<<Signal>>DialedDigit

<<SignalOffHook>>

+Digit

<<Signal>>PhoneNb

+<<signal>> Tone

User

-CurPhoneNb-PhoneIdList

+<<signal>> PhoneId

Manager

<<Signal>>BusyTone

<<Signal>>ConnectTone

-<<signal>> PhoneEvt

LSB

-myPhoneNb-agentId-tUser

+<<signal>> PhoneNb+<<signal>> ConnReq+<<signal>> Tone+<<signal>> PhoneEvt

LineHandler

+<<signal>> PhoneID+<<signal>> ConnSig

Switch

-callerId-calledId

+<<signal>> ConnSig

ConnAgent

1

1

1

1

11

1

*

1

*

Figure 7. UML class diagram of LSB

that a class can handle a certain signal. However there are no means to specify that a classcan send a certain signal or what happens if several classes can handle the same signal. Forinstance, both LSB and LineHandler can receive the signal PhoneEvt. It is not clear which ofthe two will actually handle that signal or who could possibly send it. No communicationpaths can be described. Actually UML uses a different communication paradigm. An object

H*

wait4OffHookH

connected

entry tUser.set();exit tUser.reset();

wait4digit

onHook

entry tUser.set()exit tUser.reset()

wait4connection

entry: create(tUser Timer(15))

Calling

Connected

Called

entry/agentId=NULL

idle

wait4onHook

wait4connRepl

wait4onHook

H

entry: create(tUser Timer(15))

connectTone/ phoneLine.ConnectToneconnectTone/ phoneLine.ConnectTone

connReq/ sender.BusyconnReq/ sender.Busy

/ agentId.ConnFree;phoneLine.ringTone/ agentId.ConnFree;phoneLine.ringTone

BusyToneBusyTone

connReq/ sender.ConnBusy;connReq/ sender.ConnBusy;

OffHook/ agentId.ConnEstablish

OffHook/ agentId.ConnEstablish

busyTone/phoneLine.BusyTone

busyTone/phoneLine.BusyTone onHookonHook

onHook/agentId.connEnd

onHook/agentId.connEnd

connReq/ sender.ConnBusy

connReq/ sender.ConnBusy

OnHook/ agentId.ConnEndOnHook/ agentId.ConnEnd

onHook/ agentId.ConnEndonHook/ agentId.ConnEnd

phoneLine.BusyTone;phoneLine.BusyTone;

OnHookOnHook

self.lH.phoneLine.dialToneself.lH.phoneLine.dialTone

onHookonHook

timeOut(tUser)timeOut(tUser)

/agentId:=createAgent(toPhNb)/agentId:=createAgent(toPhNb)

[agentId/=NULL] BusyTone[agentId/=NULL] BusyTone[agentId=NULL][agentId=NULL]

BusyToneBusyTone

timeOut(tUser) agentId.connEndtimeOut(tUser) agentId.connEndBusyToneBusyTone

ringToneringTone

OffHookOffHookConnReq/ agentId:=SenderConnReq/ agentId:=Sender

Figure 8. LineHandler state machine

0-7695-0731-X/00 $10.00 � 2000 IEEE

can send signals to any known object, no channel or signal connection exists between them.This kind of communication also exists in SDL-96, if the system relays on the implicitconnections (a process can send a message to another process, which it knows by PID).

The class User models the users of the switchboard; its role was played in the SDL-96model by the environment. The classes LineHandler, Switch, ConnAgent, Manager model thehomonym concepts from the SDL-96 model, while LSB models the whole local switchboard.

In UML the actual behavior of a class is described through a state machine or through anaction that can be described in the to be determined action language. Currently, some work isdevoted to defining semantics of actions, as a response to the [2] issued by OMG.

The state machine behavior description is most suitable for reactive systems (therefore forour LSB too), while the second needs to use the action language that is under work. ClassesLineHandler, Switch, ConnAgent, and Manager also have behavior described through statemachines. The state machine that describes the line handler is described in Figure 8. Unlikein SDL-96, where in order to structure the behavior description we needed procedures, inUML we can do this using hierarchical states which ensure a better readability.

DiscussionWhile UML state machines have a more readable notation and the possibility to

hierarchically describe behavior, they have the drawback of not having a precise semanticsand of providing no means to describe the actions on transitions.

The presented examples show that the UML offers a good support for the type levelsystem description and therefore extensibility and easy reuse. It also offers some support forthe early stages of system design, essentially through use cases, much more important thanthe support offered by SDL-96, although perfectible, as shown by some of the responses tothe UML 2.0 RFI (Request For Information) asked precisely for a better coverage ofpreliminary phases [8].

However, UML is less powerful than SDL when it comes to:• Communication. In UML it is possible to specify that a certain class can process a set

of signals, but there are no means to specify which signals it could send, what happensif more than one class can process a same signal, which of the several runninginstances of a class actually process a signal, the communication route between twoinstances. It is also impossible to specify structural containment, in the way SDL-96allows it (i.e. the contained entities receive signals only through their container).

• Behavior description. The behavior of an operation and the actions to be performed ona transition or in a state is described informally. Therefore, there is no standard way tosend a signal or to call an operation, which reduces the expressing power of behavior.

• Predefined data system. UML has no data system. There is one UML package thatmight be considered as a tentative data system: Data Type package of the CommonBehavior package of the UML meta-model. We consider that this is too weak to beconsidered a data system, it also appears to have been designed mostly to use datatypes internally for the meta-model. The data type package contains a very limitednumber of basic data types and no support for collection definitions or other types ofdata type definitions. A minimal solution would have been to provide a data-typepackage (at model, not at meta-model level) that contains the basic data types. SDLprovides a whole data type and data type definition mechanism.

• Semantics. This means that there is no sound basis for tools that may performadvanced operations on an UML model, such as correctness checking, test, andsimulation. Albeit a tool may define its semantics and do it in a sound form, thiswould still be halfway, because when exporting the same UML system to another tool

0-7695-0731-X/00 $10.00 � 2000 IEEE

this could behave differently. This is one of the most “classical” UML problems,which has been signaled several times [1].

One of the solutions to overpass some of the UML deficiencies is provided by [7]. Theauthors of the paper adapt ROOM [10] and define it as an UML profile. ROOM offers acoupling between statecharts and structure diagrams, based on the concept of port andcapsule. This solution solves most of the problems described above, but it has the drawbackof being a proprietary solution, non-standardized and uses some non-standard UMLextensions.

3.3. SDL-2000 modeling

Many efforts [11] were devoted to combine UML generality and type-level power withSDL rigor and precise communication specification. SDL-2000 is the outgrowth of theseefforts. It represents the latest SDL version that contains UML-inspired object-orientedconcepts adapted to the SDL particularities and an alternative UML inspired notation for theSDL type concepts. These concepts and the alternative notation co-exist with the SDL nativeconcepts.

New concepts and alternative graphical notation in SDL-2000The SDL-2000 model of LSB has both a type level system description, which is mostly

focused on describing the system structure, that contains the relationships that may existbetween its constituents and some behavior specification, and an instance level, that offersmore precise information about the static structure of the system and about its behavior.

Using the SDL-2000 the analyst can use type level concepts. SDL-2000 offers typeconcepts practical to use, such as:

• type concepts for describing the active part of a system: agent types (system type,block type, process type, composite state type);

• type concepts for describing communication patterns: interfaces;• type concepts for describing data: value and object types.The SDL-2000 types can be interrelated using three basic kinds of relationships:

containment, inheritance, and association. That makes the expressing power of SDL-2000comparable to that of UML.

From the notation point of view, besides the SDL graphic notation, SDL-2000 providesthe user with symbols and diagrams UML lookalike. Although not a goal per se, the UMLlook has the advantage of being known, which means a small learning curve for UML trainedpeople, and an easy passing from UML to SDL-2000 and vice-versa. They can capture theproperties of the entities they represent in a more compact form, which can lead to anincreased readability. All these additions make the SDL-2000 object-oriented and a usefullanguage even when acting at type level.

The type level constructs co-exist with the instance level concepts inherited from SDLwith slight changes. This means that an analyst who uses SDL-2000 can focus the SDL-96part of it. This represents only a small gain (compared with the use of the “old” SDL), but itis still a valid choice.

The most interesting approach while using the SDL-2000 is to start working at type level,by identifying all the needed types, their properties and the relationships that may existbetween them. These type structures could be added to libraries or simply reused whiledescribing other systems. After describing the system at type level, the user may specialize itto get to the instance level.

0-7695-0731-X/00 $10.00 � 2000 IEEE

The concepts that SDL-2000 offers for instance level corresponding to all type levelconcepts, plus additional features to precisely describe the inter-agent communication. Thepurpose of the instance level description is to precisely describe the kind and the number ofthe instances that exist at runtime, their actual relationships - in the case of associationswhich are run-time established - and the way they communicate with each other.

SDL-2000 model of LSBFigure 9 contains one of the SDL-2000 UML-like type level diagrams of the LSB

description.One can easily notice the similarity that exists between the SDL-2000 diagram and the

same diagram in UML (compare figures 9 and 7). The class User existing in UML hasdisappeared as the user’s role is played in the SDL-2000 modeling by the system’senvironment. Another difference between the SDL-2000 and the UML model is the createline that occurs in the SDL-2000 diagram which although not existent in UML can beinterpreted in UML terms as a dependency that has the semantics of the create line.

Figure 10 contains the description of block Switch. This diagram resembles to thecorresponding SDL diagram (compare figures 10 and 5), excepting the communication that ismodeled in SDL-2000 using interconnected interfaces, whereas in the SDL-96 model (figure5) we used gates and channels.

The actual behavior is described in SDL-2000 using composite states, which are moreexpressive than the simple SDL-96 states, possibly used in combination with procedures,which also exist in SDL-2000.

The SDL-2000 state machines are easier to use and more expressing than the ones in SDL-96. Their look is not the same as the one known from Statechart, but the expressing powerthat can be obtained by coupling agents and state machines in SDL-2000 is the same as inStatecharts. Although not in the SDL-2000 standard, a Statechart inspired graphical notationcould be used instead of the current SDL-2000 hierarchical state machine representation. In

PhoneEvt

<<block>>Switch

- callerId- calledId

<<process>>ConnAgent

- curPhoneNbList- phoneIdList

<<process>>Manager

<<system>>LSB

1

11

- myPhoneNb- agentId- tUser

<<process>>LineHandler

0:NbOfLines

1

1

1

Tone

PhoneId

[PhoneNb]

ConnSig

ConnReq,Tone

PhoneId

PhoneNb

Tone

PhoneEvt

PhoneId

PhoneNb

ConnSig

ConnReq,Tone

ConnReq,Tone

ConnSig

system LSB_basic

0:MaxCalls

Figure 9. SDL-2000 class diagram of LSB

ConnReq,Tone

PhoneNb

Block Switch

ConnSig

PhoneId

manager(1,1):Manager

connAgent(0,MaxCalls):ConnAgent

PhoneId

PhoneNb

ConnReq,Tone

ConnSig

Figure 10. SDL-2000structure diagram of block Switch

0-7695-0731-X/00 $10.00 � 2000 IEEE

this case, the SDL-2000 textual representation of actions (the SDL-2000 algorithmiclanguage) could be used to describe the actions performed on the transitions or in the states.

DiscussionThe SDL-2000 combines type level system design with precise instance behavior

description, doubled by the fact that it is based on a formal definition. All of these lead tosystems whose performance (in terms of expressiveness and efficiency) is virtually the sameas in SDL-96.

SDL-2000 can be seen as a real UML profile. The details of this profile are described inan annex to the SDL-2000 standard, called Z.109 [12]. Z.109 could serve two basiccomplementary purposes. First, SDL-2000 viewed as a UML profile could address UMLusers that need the basic UML features, but would benefit from the SDL-2000 rigor andexpressing power at instance level, in the area of communication and time semantics. On theother side, [12] offers an UML interpretation for the major SDL concepts.

Z.109 represents the foundation on which the tools could offer real inter-operability,possibly with some restrictions, between UML and SDL-2000 models.In spite of all these real powers of SDL-2000, one should not understand that SDL-2000 isthe panacea language suitable for any solution, which could replace both UML and SDL-96.There are indeed some situations when SDL-2000 is more appropriate than other modelinglanguages. The next section discusses on the relationship between the problems we try tosolve and the actual modeling language to use.

4. Domain suitability

This section is motivated by the need to clarify which domains the three languages wehave discussed here (UML, SDL-96, and SDL-2000) address more naturally. None of thethree languages is at the same time general enough and precise enough to address all thedomains well enough and therefore to preclude the use of the others. For that reason in thissection we will analyze the relationship between the design language to be used and thedomain in which it is applied.

One of the reasons for which UML is so popular is its simplicity. It is close enough to themajor concepts encountered in most of the programming languages (at least its “basic” parts,which are also the ones most used and supported by tools). It is also general enough, so thatat a certain point it is considered as addressing all domains. This is actually true only to alimited extent. As we have seen in section 3.2. the major areas where the use of UML posesproblems are: the behavior and communication specification, and the time.

UML does not offer means to precisely specify behavior as its state machine semantics isnot precisely defined and currently the actions on a transition or describing the body of anoperation are specified informally.

In UML we can only specify the signals a class can receive and we can not describecommunication paths, or what happens if two classes can treat a same signal. Finally, theconcept of time has no semantics and it is unclear how it could be actually used.

Essentially these tree areas, behavior, communication and time specification, represent theweak points of UML. Consequently, the domains in which the use of UML is mostlyappropriate are those where the importance of these areas is reduced.

This is the case of systems mostly oriented towards data modeling such as data basesystems. Another case is that of systems that are purely reactive (i.e. event driven systems,the behavior of which can be described using state machines, but the object distribution andtime concerns are not vital), so the state machines are good enough to fully specify their

0-7695-0731-X/00 $10.00 � 2000 IEEE

behavior, but that contain very primitive ways of communication, since UML is not strong atcapturing communication.

On the other hand UML, in its current standard form, is less adapted to systems that useintensively communication and for which the notion of time is crucial.

To be applicable on real-time systems UML needs some specific adds to solve thedomains we have mentioned before (precise behavior specification, precise communicationspecification and adapted notion of time). It is expected that the current OMG UMLextensions (see the OMG UML 2.0 RFI responses at the OMG web site) will tune UML forthe real-time world. Until then, other solutions should be adopted for this kind of problems.

SDL is a language mainly designed for describing protocols and more general distributedsystems. As presented in section 3.1. it is mainly focused on describing the structure,behavior, and communication of a system while focusing at instance level. Therefore SDL isappropriate for describing protocols and systems where the communication and precisebehavior are important, such as real-time systems and reactive systems. On the other hand, tojustify the instance-focus of the language, it should be used for describing systems that areunique enough so that the reuse or library design is less important. Although this may seemrestrictive, the practice shows that there are a lot of systems where it could be applicable.

SDL-2000 tries to satisfy both the need for a precise description of the instance level,behavior and communication, and the need for a typed framework for system description.

This makes it suitable for all the cases SDL-96 would be suitable, but SDL-2000 offersadditional support for reuse and extensibility.

While describing communication protocols some system patterns may tend to occurfrequently, using SDL-2000 they could be organized into libraries that would contain boththe structural description and the actual behavior. Actual protocols that describe realsituations could be described by reusing or refining one of the protocols of the library.

By having precise concepts that handle the communication and the basic time aspects,SDL-2000 is also suitable for designing all kinds of real-time or reactive systems.

By having precise semantics for all of its concepts, SDL-2000 makes possible theexistence of some advanced tools to support the system modeling which can not exist in theabsence of a precise semantics. It is the case of model checkers, simulators, testing tools andcode generators.

5. Conclusions

In this paper we have considered a simple example, the LSB, that has been described usingthree modeling languages: SDL-96, UML, and SDL-2000. Space reasons prevent us topresent the three examples to their very detail; therefore we had to extract some meaningfulpieces of them to help the reader get our message. Nevertheless, a complete version of theseexamples can be obtained directly from the authors of the paper.

The SDL-96 model reviled powerful mechanisms to describe behavior andcommunication, doubled by the advantage of having a precise semantics. As SDL-96 is weakwhen it comes to type level, it proves not to be a good solution if reuse, extensibility andgeneral typing are needed.

UML proved to be a good choice while modeling the main concepts of the consideredexample and the relationships among them. However, it proved not to be a good solutionwhen trying to capture communication-related information, such as specifyingcommunication routes or communicating instances. The behavior specification has also someweaknesses mainly due to the imprecise action specification and to the lack of a precisesemantics that would actually give a unique and meaningful sense to all the concepts.

0-7695-0731-X/00 $10.00 � 2000 IEEE

SDL-2000 proved to be a solution for unifying both the advantages of UML and of SDL. Ithas precise means to specify in detail model communication and it has a formal semantics forall the concepts and for the behavior description. In addition to this, it offers hierarchicalstate machines and object-oriented support, which offer elegant and powerful means to dealwith types, using UML notation.

Besides helping us to analyze the applicability of SDL-2000, the example presents theinterest of illustrating SDL-2000, whose specification is about to be published and noexample is currently provided to exemplify it.

In section 4 we present a discussion on the opportunity to use each of these languagesdepending on the kind of systems to be modeled. The most general conclusion that can bedrawn is that none of these languages is a magic potion that fits well all the possible domainsand that a wiser approach would be to choose the modeling language after a careful analysisof the problem to be solved.

13. References

[1] Evans A.S., France R.B., Lano K.C., Rumpe B., “The UML as a formal modeling notation.” In UML'98 -Beyond the notation, LNCS 1618, Springer, 1998[2] Object Management Group (OMG), “Action semantics for UML Request for Proposal”, OMG Documentad/98-11-01 ftp.omg.org/pub/docs/ad/98-11-01[3] SDL'99 (9th SDL Forum), “Tutorials”, Montreal University, SDL Forum Society and Nortel Networks editors,1999[4] ITU-T, Recommendation Z.100, “Specification and Description Language” (SDL), http://www.itu.ch -Electronic Bookshop, Geneva, 1996[5] ITU-T, Recommendation Z.100, “Specification and Description Language” (SDL), http://www.itu.ch -Electronic Bookshop, Geneva, 1999[6] Rumbaugh J., Jacobson I., Booch G., “The Unified Modeling Language Reference Manual”, Addison Wesley,1999[7] Rumbaugh J., Selic B.:” Using UML for Modeling Complex Real-Time Systems”[8] Softeam, “Softeam UML 2.0 RFI Response, Consolidation of UML for a better coverage of preliminaryphases”, OMG Document ad/99-12-04[9] Object Management Group (OMG), “UML 1.3 Documentation Set”, ftp.omg.org/pub/docs/ad, 1999[10] Selic B., Gullekson G., Ward P., “Real-Time Object-Oriented Modeling”, John Wiley & Sons, 1994[11] Verschaeve K., Ek A., “Three Scenarios for combining UML and SDL-96”, in R. Dssouli, G. v. Bochmann,Y. Lahav (Eds.) SDL’99, Proceedings of the 9th SDL Forum, Montreal, Canada, 21-25 June 1999, pp. 209-224[12] ITU-T, Draft document, “SDL-UML”, SG.10 Q.6, Editor Birger Moller-Pedersen, 1999

0-7695-0731-X/00 $10.00 � 2000 IEEE