Modelling SDL, Modelling Languages

Michael PIEFEL Institut für Informatik, Humboldt-Universität zu Berlin Unter den Linden 6, 10099 Berlin, Germany [email protected] and Markus SCHEIDGEN Institut für Informatik, Humboldt-Universität zu Berlin Unter den Linden 6, 10099 Berlin, Germany [email protected]

ABSTRACT Model Driven Architecture (MDA) [11], a method with increasing popularity, uses models in various levels of abstraction to drive Today’s software systems are too complex to implement them and the process of software development from early analysis to a fully model them using only one language. As a result, modern soft- implemented and deployed ready-to-use system. In the MDA, the ware engineering uses different languages for different levels of important details that you abstract from in higher level design abstraction and different system aspects. Thus to handle an in- phases are platform dependency, performance issues, real-time creasing number of related or integrated languages is the most aspects, etc. Of course you have to use different languages for challenging task in the development of tools. different levels of abstraction; you use languages that are special- ized and made for the depth of detail needed at a certain point in We use object oriented metamodelling to describe languages. Ob- the development process. ject orientation allows us to derive abstract reusable concept defi- nitions (concept classes) from existing languages. This language Therefore complex software systems force you to use many lan- definition technique concentrates on semantic abstractions rather guages because you model different system aspects with different than syntactical peculiarities. We present a set of common con- languages and model the system in different levels of abstraction, cept classes that describe structure, behaviour, and data aspects of using different languages. But as matter of fact, the integration high-level modelling languages. Our models contain syntax mod- between languages is usually poor, and most languages have more elling using the OMG MOF as well as static semantic constraints commonalities than differences. This provides a big motive for written in OMG OCL. a technique that allows to relate languages and thus promotes a better integrated use of languages and allows the reuse of their We derive metamodels for subsets of SDL and UML from these language concepts and implementations. common concepts, and we show for parts of these languages that they can be modelled and related to each other through the same We think that metamodelling is the technique that is needed. Meta- abstract concepts. modelling allows object-oriented decomposition of languages by finding abstractions. Metamodelling offers different concepts to Keywords: Metamodel, MDA, SDL, MOF, OCL, UML relate the concepts of languages and reuse via inheritance hierar- chies. In this paper we want to exemplify how metamodelling can 1. INTRODUCTION be used to build a common model for SDL [8] and UML. Section 2 gives an introduction into metamodelling; it explains Increasing demand for more and more complex software requires the idea of common concepts, the reusable core of our models; it that software engineering itself becomes more and more complex. shows how common concepts are identified, modelled and used. Informal problem analyses, crude design techniques, and ad-hoc In Sect. 3 we present a common structural, behavioural and data program writing cannot fulfil modern software engineering needs. model. This model is used in Sect. 4 as the common base for an For that reason the building block of today’s quality-conscious real- SDL and an UML model. We demonstrate this common model by izations of extensive software projects have to be formal analyses, applying it to an SDL model and UML model of the same simple complex design models, generated program code, and automated example system. Here we show: How the common model relates development tasks within standardized software engineering pro- structural, behavioural and data concepts to each other and how cesses. the common concept correlates SDL and UML concepts with each The mere size of today’s software system forces you to break other, and how these concepts are reused in the two different lan- down its complexity. One way (horizontal separation) is to break guages. Section 5 will finally draw some conclusions and present the complexity down into multiple views on the system. The ideas for further work. various aspects of a system are modelled in separate views. A common partitioning is into a structural, a behavioural and a data view. Following this principle, you use different languages that are 2. METAMODELLING, OBJECT-ORIENTATION AND specialized for the modelling of different system aspects. Often COMMON CONCEPTS those languages are related, and they build a family of languages, like the UML [14] or the collection of ITU-T languages, called Before we present the result of our efforts to build common models, ULF. we want to give an introduction about what metamodels are, what concepts are, what makes concepts common, and how does the Vertical separation is the other way to deal with complexity; a overall idea of metamodelling for language integration/alignment system is modelled by using different levels of abstraction. The and language reuse work.

ISSN: 1690-4524 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 1 61 Metamodelling they have to be related to each other. Their concept spaces overlap. The building blocks of metamodels are concepts. Concepts are The concepts in this intersection are common concepts. modelled as classifications of language entities of the same kind. Examples for concepts are variables, data type, procedures etc. As an example, take a parameterized procedure call. The param- Those classifications (concept classes) can be related to other con- eter’s type is in the domain of data modelling; the procedure call cepts: they can inherit from more abstract concepts; they can that uses the parameter falls into the structural view; the proce- aggregate other concepts; they can associate with other concepts, dure’s behaviour may access the parameter and uses operations and finally they can contain other concepts: structural features, defined by the data type of the parameter. So all of the three like attributes or references to other concepts, and behavioural views, and their respective languages, must have the same syntac- features, like methods. Meta-models are usually notated using tical and semantic idea about what a data type/parameter is; they UML class diagrams. must share this common concept. Here the shared concepts often form a direct relation between languages that can be utilized for Semantically a concept is an idea or a notion that we apply to an integrated use of languages. things, or objects in our awareness. A concept applies or does not apply to an object [10]. When you transfer this common def- How does metamodelling allow the shared use of common con- inition to the metamodelling domain, a concept is an idea or a cepts? Well as laid out earlier metamodels are simply object- notion that applies or does not apply to an element of a model or oriented models and their entities can be composed (reused) to a program. more concrete concepts. We mentioned two metrics that influ- A good introduction to metamodelling can be obtained fromAtkin- ence the applicability of a concept for reuse. In summary there son [1, 2] or the MOF standard [12]. are three properties that a concept must fulfil in order to be a common, and more importantly a reusable concept: Concepts 1. A common concept must be common; it must be applicable to The nature of object-orientation is to compose a larger system the entities of different languages. from smaller parts or to decompose a larger system into smaller parts. Of course you can do the same with concepts; you compose 2. It must have high cohesion in order to be freely and flexible more expressive concepts from less expressive concepts. combinable without the ballast of unnecessary or unwanted There are two forms of composition; the specialization of concepts concept features. using inheritance and structural composition using concept rela- tions like aggregations or associations. This is known as object- 3. It must have low coupling; this is needed to prevent conflicts oriented (de)composition [3], the (de)composition with abstrac- when the concept is used for composition. tions as key; you compose less abstract concepts from more ab- stract ones. Sources for Common Concepts There are two important metrics that describe the applicability of The overall nature of a set of common concepts is that this set concepts for further composition. These metrics are cohesion and is evolving. As languages evolve, new concepts and techniques coupling [4]. A concept has a high cohesion if it describes a sin- are invented and used, the set of common concepts must adopt gle, atomic characteristic. A concept NamedElement whose only and evolve over time. In other words, the common concepts must characteristic is the property name is highly coherent. A concept continuously adopt to their sources. What are these sources, how has low coupling if it does not depend on other concepts. The do we find them? We identified three different sources that can be concept NamedElement has low coupling; it only depends on the used to identify concepts that are common to considered languages, primitive data type String. and that will probably be common to other languages: These metrics describe the capability of concepts to be the basis 1. Concepts that already exist, are well known. These are con- for composition. A concept with high cohesion and low coupling cepts of the object-oriented paradigm, concepts taken from is easy to use without getting characteristics you do not want (high abstract type systems, or abstract computational models like cohesion) or dependencies you can not handle (low coupling). state automata, algebraic expressions, etc.

Common Concepts 2. Object-oriented decomposition of concepts of existing lan- As a matter of fact, languages have more commonalities than dif- guages into smaller, more abstract, and potentially common ferences. The languages that are made to model the same system concepts. aspects, but on different levels of abstraction, often share many concepts – because they are meant to model the same things, but 3. By direct integration of languages and straightforward com- just with a different level of detail. parison of the related concepts in different languages. For example eODL [9], SDL, and even implementation languages (like Java) incorporate the concept of generalization, they support Source 2 would be the most desirable. It describes the object ori- structural features like attribute, or they have data typed elements ented method that we use in daily software development and that such as variables. Here the shared concepts form a direct align- is known to lead to flexible and reusable artefacts. However, it is ment between languages and allow easy derivation of translation also the most problematic source, because it is unlikely that two processes to convert models between the different abstraction lev- abstractions gained independently from two languages will be the els. same. Therefore a direct comparison of languages is inevitable and the integrated use of source 3 and 2 would be the method of On the other hand, languages that are made for modelling at the choice. Of course, also the ideas taken from source 1 must be same abstraction level, but for the modelling of different aspects, taken into account. Those known concepts reflect the common basically use more different concepts. In the end, those languages knowledge about languages and only this knowledge makes a set are used to model only one consistent system, and for that reason of common concepts applicable for future languages.

62 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 1 ISSN: 1690-4524 +contents +body Bodied ModelElement Contains * 0..1 1 +bodiedElement BodiedElement +container 1

NamedElement Container +type Type name : String 1 Contains

0..* +parameterizedElement +parameters Namespace ParameterizedElement Parameter 1 Parameters {ordered}

+instance 1 Expression (from CommonData) Type TypedElement determineType() GeneralizableElement * {ordered} * +arguments +supertype Arguments 1 +specialtype

1 +argumentedElement GeneralizableElementSupertype ArgumentedElement (from CommonData)

Figure 1: Common Structure

3. THE COMMON MODEL The usefulness of BodiedElement is yet unclear. On the one hand this element can be replaced in a container-contents relation. On In this section we present a model of common concepts for struc- the other hand, some constructs, like a process in SDL, contain tural, behavioural and data modelling. We developed this model named elements but also contain a nameless body (processes con- by comparing SDL with UML, we looked for abstractions in those tain a state automaton). Further applications have to show whether languages; we normalized these abstractions to fit into each other; BodiedElement is needed or not. we were also influenced by existing metamodels to UML and our The concept TypedElement characterizes an element that refer- common knowledge about language constructs. ences exactly one type of that very element. The name typed easily confuses, because you instantly think of data-type seman- Here are few notes on the notation: The model is notated with tics; but the concept TypedElement is just a syntax property that UML class diagrams. Most of the concept classes are abstract; so simply says that there is exactly one type to every typed element. they cannot be instantiated directly; they have to be specialized by a concrete language definition. There is heavy use of specializa- The concept Parameter for example is a classical application of tion throughout the model. Unfortunately, the support for special- TypedElement. But another application of TypedElement, Argu- ization of associations in MOF/UML 1.x is very poor. In order to mentedElement, might seem a bit more peculiar. It is best explained notate association specialization anyway, we used dependencies through an example: Imagine a procedure call (an element with ar- with the same name. They should be understood as replacement guments) and its type the procedure declaration (an element with for the original association, but with the dependency’s ends as new parameters – ParameterizedElement). specialized association ends. On first sight GeneralizableElement seems to be incoherent because We omit detailed explanations of the model, but we give a few it unnecessarily specializes Namespace. But wherever generaliza- notes on those parts that we think are not self explanatory. tion/specialization occurs it seems to have inheritance semantics. The reason is that in order to have something to inherit, general- izable elements should be able to contain something. Take the Common Concepts among Common Concepts methods and members of a Java class as an example. The Common package (Fig. 1) contains the most abstract concepts; these are concepts that themselves are heavily used by the com- Behaviour mon concepts. ModelElement is the most abstract element; it is the The next model package is CommonBehaviour (Fig. 2 on the next super concept to all other concepts. Its purpose is to model every page). Because there are a lot of techniques that are used in mod- element as possible contents for the Container concept. elling behaviour, this package, or better the set of behaviour mod- elling concepts in general, have potential for further development. The container-contents relation (also known as composite- Weonly present concepts for the behaviour modelling with state au- component) uses composite aggregation semantics in order to tomata and concepts for a simple communication mechanism. impose a strong part-of-a-whole semantics on the instances of Container and its content. To both participants of this relation A StateAutomaton is a composite element that contains States and there are specializations: Namespace and NamedElement. These Transitions. Transitions connect two states. NextState directly four concepts are widely used in structural modelling; classes, relates a transition with its successor state. This is straightfor- components, SDLAgents, packages are only a few examples. ward.

ISSN: 1690-4524 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 1 63 Entry + media + media Exit 0..* Media + automaton + states State 1 * * StateAutomaton States * + source * + adjacentMedia * + sink 1 + state 1 1 + state + state ComSource Network ComSink + nextState + automaton 0..1 0..1 + Transitions 1 source 1 + sink 0..* NextState + data + data + transitions 1 ComData + transition SourceData SinkData Transition * * + transition 1 ExitActions EntryActions + transition 0..1 Actions +exitActions + entryActions {ordered} {ordered} TransitionSelector 0..* 0..* +actions Action NamedElement 0..* State + selector 1 (from Common) + selectors {ordered} Selector 0..* SelectorsOfState PseudoState NamedState Immediate Start

Guard Answer Trigger History Join Stop Split recursive : Boolean question : Expression

Figure 2: Common Behaviour – State Automata and Communication

Unfortunately, the relation from the predecessor state to an tran- The Expression concept allows arbitrary inductive expressions over sition is not straightforward at all. For one thing, there has to be data using LiteralExpression, VariableAccess and AnyExpression as a concept that selects the transition that should be executed; for base step and Operation as inductive step. another we have to decide where to place the Selector. The current solution (as presented in the figure) is that Selector is part of Tran- sition and can be reached via the SelectorsOfState association from 4. APPLICATION OF THE COMMON MODEL the predecessor state. As many decisions this one yet has to prove sensible. Other pos- The model for SDL was derived from the SDL abstract grammar sibilities are that the selectors are part of the states and simply using the techniques described in [7, 13]. Basically this means reference the transitions that they select; or the selected transition that a preliminary model was generated from the SDL grammar, is part of the selector (it is done that way in the Z.100 (SDL) spec- using an automated mapping from BNF to the MOF-model (the ification). We chose this solution because we think it meets best language that we write our metamodels with [12]), and then the with the scholar’s idea of a state automaton. elements of this model were related (marked as specializations) to the elements from the common model. For the UML model, Transitions can contain Actions. Often a transition shall not sim- concrete concepts were taken from the UML standard and related ply execute a chain of actions, but branch on conditions or join to our common model. with another transition. To enable this, we introduce PseudoState; states that that a automaton cannot reside in over a period of time, Unfortunately this is a paper of limited size, so it is not possible to but only can instantly fire a transition. provide you with the actual metamodels for SDL and UML that we derived from the common model. Instead we would like to The states Split and Join are such pseudo states. A Transition cannot show an SDL and UML model of an simple example system, and perform splits or joins on its own; but it can connect join and split we want to show with this example, where which common concept states. A split state can only be predecessor to transitions that have is used in which concrete language concept. The example system Answer selectors. Those answers select the path to choose, accord- is a very primitive constructed system but it shows some major ing to the question expression of the split. A join state, can only be concepts of the modelling of structure, communication, and state predecessor to exactly one transition with Immediate selector. automata. Communication concepts are modelled in a simple way; a Com- Source sends ComData over a Network of Media to an ComSink. These Figure 4 shows the structure of the system. In both models there concepts are explained in detail in Sect. 4, where they are used. is multiple use of the communication concept Media. In SDL, gates and channels are media, used to create a communication link between agent instances. UML defines associations between Data classes to define links as media between class instances. Media is The data concepts modelled in the CommonData (Fig. 3 on the next conceived as a unidirectional communication link; for that reason page) describe an operative interface to actual data types, expres- both the bi-directional SDL channel as well as the bi-navigable sions and their application, and the definition variables. UML association must be aggregations of two media. Further the The concept ValueDataType is capable of modelling an interface to UML association is also an aggregation of its association ends any algebraic data type, since it uses Literal to define a set and it (each of them is a media too); the SDL gates instead are part of defines Operations that work on that set. the agent instead.

64 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 1 ISSN: 1690-4524 + variable DataType Type Variable 1 + variable compatibleWith() Namespace 1 Type 1 + variableDefinition (from Common) AssignTo

Initialization AnyExpression + assignment 1 + assignment Assignment ValueDataType 1 AccessedVariable Type + dataType 1

Type Contains AssignWith

+ assignmentExpression + initExpression Literals Operation + argumentedElement 1 0..1 1 * + arguments Expression ArgumentedElement Arguments {ordered} 1..* + literals determineType() Literal Type

1 + literal OperationApplication 1 1 LiteralExpression VariableAccess LiteralOfLiteralExpression + literalExpression + access

Figure 3: Common Data

It might seem strange to apply communication semantics to UML As mentioned SDL agent and UML class are namespaces; they association. The semantics of UML is for the bigger part open are namespaces to distinguish features of those structure types. A to individual interpretation. We apply the following semantics: UML class may contain attributes and methods; an SDL agent is There must be a navigable link from object a to object b in order namespace to various definitions including variables and proce- to allow a to call a method (to send a message) on b. dures.

This is a bit difficult because methods have synchronous commu- Those features might have a specific visibility. In UML they fol- nication semantics. This means that there must be an additional low the known private, protected, public scheme. In SDL visi- implicit ComItem characterising the return. Regardless of these se- bility is hidden behind the possibility to export variables and to mantic differences both SDL signals and UML methods comply make procedures remotely accessible. As interfaces visibility has to the ComItem concept. purely constraining semantics; it is tightly coupled to the inter- face concept. It is omitted from our common model for the same There is one common concept needed here that we did not cover in reasons. the common model; that is an interface concept. An interface is a communication concept that constrains possible communication; Both languages are almost identical about the State concept. Be- an interface says which ComItems an entity can receive or send. side the normal named state, there are pseudo states. These are This way an interface is a concept that is purely part of static se- states in that the behaving entity cannot reside but only immedi- mantics; it is only used for model checking and has no influence ately trigger a transition or completely stop any further behaviour. on the actual system behaviour. Such states are for example start or stop states. States can, in both languages, contain inner states that are computed in parallel. We did not introduce an interface concept because we are not sure whether it is really needed. All elements of an interface (signals, For the modelling of transitions between such composite states methods, etc.) are already covered by other concepts (gates, class, SDL defines entry and exit points to derive semantics that is de- etc.); but for a common implementation of static semantics an ad- tailed enough to allow an unambigiuous execution of the automa- ditional common interface concept might be very useful. The con- ton. Such points comply to the pseudo state concept (not part of cept interface becomes even more important when specialization the example). and polymorphism complicates the implicit interfaces of UML classes of SDL agents. Transitions are in both languages executed when selected by a trigger, a guard, or similar concepts; selectors can also be combi- In both languages there is a instantiable structure type concept; nations of such concepts. Transitions can contain actions such as agent type in SDL and classes in UML. Both type concepts are tasks or outputs in SDL or method calls in UML. The exit from a GeneralizableElements and Namespaces. They might also comply state (the execution of a transition from this state) as well as the to the BodiedElement, like their relation to a state automaton that entry to a state (the execution of a transition to this state) can be describes the behaviour of a type. Both concepts are instantiable; accompanied by actions. All exit, transition, and entry actions are but SDL allows the definition of whole instance sets. Due to the executed in a specific order. more detailed and more formal semantics, the SDL agent type is a bit more sophisticated; it differentiates various kinds of agents In SDL it is possible to split one transition into reusable parts us- with different characteristics. The UML class is a more common ing labels. Because this is purely syntactical, there is no concept broader concept. But both share the mentioned concepts. for that in the common model.

ISSN: 1690-4524 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 1 65 Another selector is the Trigger, for example inputs in SDL and yes might seem a bit faint and questionable to the practitioner’s method call events in UML. Both concepts also comply with the eye. ComSink concept and are the far side of a communication. This We started to use the common concept idea, and the models pre- means that a signal and its actual arguments (the ComItem) are sented in this paper, in methodologies, frameworks and actual im- received in SDL and the method call message and the actual ar- plementations for language tools. In [5] a conceptual architecture guments (the ComItem) are received in UML. The opposite is the for language development and tool implementation is proposed, output in SDL and the method call in UML. These elements com- and we use this tool-based language development to implement ply to both ComSource and Actions. ComSource because they are tools for ITU-T languages; our work in progress is presented in the local side of a communication and Actions because they are [6]. executed as part of a transition. The example system shall transit from B to A or B depending on 6. REFERENCES the value of varA. The behaviour has been realized differently in SDL and UML to exemplify both approaches; both are possible in [1] ColinAtkinson. Meta-Modeling for Distributed Object Envi- SDL and UML. In UML the transitions selector is a combination ronments. In 1st International Enterprise Distributed Object of a Trigger (the methodB call event) and a Guard selector; there are Computing Conference, October 1997. two different selectors for two different transitions. In the SDL model, a first transition, leading to a Split pseudo state, is selected [2] Colin Atkinson and Thomas Kühne. The essence of multi- as usual by the input trigger. From that split state the next transi- level metamodeling. In 4th International Conference of the tion is immediately selected by one of the two Answer selectors; Unified Modeling Language, October 2001. the answers finally make the difference. [3] Grady Booch. Object-Oriented Design with Applications. Addison Wesley Professional, 1991. 2nd edition (1993). 5. CONCLUSION [4] Peter Coad and Edward Yourdon. Object-Oriented Design. Yourdon Press, 1991. We use metamodelling’s object-oriented characteristics to build a model of concepts that are common in high-level modelling lan- [5] Joachim Fischer, Eckhardt Holz, Andreas Prinz, and Markus guages. This set of common concepts can be the basis for the Scheidgen. Tool-based Language Development. In Work- definition and implementation of languages. shop on Integrated-reliability with Telecommunications and UML Languages (WITUL), November 2004. There are three factors that are crucial for the success of the com- mon concept idea: [6] Joachim Fischer, Andreas Kunert, Michael Piefel, and Markus Scheidgen. ULF-Ware – An Open Framework for • Common concepts are subject to frequent changes, and the Integrated Tools for ITU-T Languages. In SDL 2005, LNCS. set of common concept has to be constantly evolved to adopt Springer-Verlag, 2005. to new trends in the modelling world. The problem is: How flexible and adoptable is metamodelling really? [7] Joachim Fischer, Michael Piefel, and Markus Scheidgen. A metamodel for SDL-2000 in the context of metamodelling • Can common concepts be the base for reusable tool implemen- ULF. In SAM 2004, LNCS. Springer-Verlag, 2005. tations? Is it possible to implement a shared concept once and reuse it in tools for different languages? How easy is it to de- [8] ITU-T Z.100. Specification and Description Language velop tools for new languages on the basis of already existent (SDL). International Telecommunication Union, August tool implementations. 2002. • When common concepts evolve, can implementations based [9] ITU-T Z.130. Extended Object Definition Language (eODL). on common concepts evolve with them? Is metamodelling International Telecommunication Union, July 2003. flexible enough to evolve common concepts without con- [10] James Martin and James J. Odell. Object-Oriented Methods: stantly crippling and deprecating already written tools that A Foundation. Prentice Hall PTR, 1995. 2nd edition (1997). are based on them? [11] MDA. Model Driven Architecture Guide, Version 1.0.1. Ob- All of these question can only be answered when metamodelling ject Management Group, June 2003. omg/03-06-01. and the common concept idea is practically used. From the theo- [12] MOF. Meta Object Facility, Version 1.4. Object Manage- retical view point, the only point of view that we can look from for ment Group, March 2003. formal/2002-04-03. now: due to the success of object-oriented software development that metamodelling is based upon, all these question have to be [13] Markus Scheidgen. Metamodelle für Sprachen mit formaler answered with a yes. Syntaxdefinition, am Beispiel von SDL-2000. Humboldt- Universität zu Berlin, June 2004. Dissertation. But despite its success, object-orientation could not fulfil every promise made, and it cannot be the final answer to all software en- [14] UML. Unified Modeling Language, Version 1.5. Object gineering problems. For that reason the theoretical (hypothetical) Management Group, March 2003. formal/2003-03-01.

66 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 1 ISSN: 1690-4524 UML Class/Object Diagram UMLMethod and SDLSignals both B comply to ComItem. But UMLMethod, A + endA + endB as part of an interface, also complies to attrA : Integer the concept Media; in SDL, this role is methodC() 1 1 methodA() provided by SDLGate. Those items can methodB(argA : Integer) be ArgumentedElements and TypedElements.

a : A b : B endA endB

UMLClass and SDLAgentType are both a combination UMLAssociation, UMLAssociationEnds, of GeneralizableElement and Namespace. SDLChannels and SDLGates are all Media.

SDL System

A B signal signalA, signalB(Integer), signalC;

signalC signalA, signalB UMLObject and SDLTypebasedAgent a(1,1):A b(1,1):B are both TypedElements. gateA gateB

Figure 4: Common Concepts among SDL’s and UML’s Concepts

Statechart for Class B

State, Start, Stop are the same in A methodB ( attrA ) [ attrA!=1 ] both languages.

This Selector is a combination of methodB / endA.methodC() methodA an UMLMethedCallEvent and a Guard . B

SDLVariable as well as UMLAttribute methodB ( attrA ) [ attrA==1 ] are T ypedElements and part of the surrounding Namespace

The UMLMethodCall and the SDLOutput Process Type B are Action and also ComSource. The UMLMethodCalledEvent and the SDLInput are T rigger and also ComSink. dcl varA Integer; B

A signalB(varA)

signalB signalA varA

else 1 signalC B A B via gateB

signalA, signalB signalC

The SDLDecision is a Split, a PseudoState gateB that uses Answer as Selector for the two successor transitions.

Figure 5: Common Concepts among SDL’s and UML’s Statechart Concepts

ISSN: 1690-4524 SYSTEMICS, CYBERNETICS AND INFORMATICS VOLUME 5 - NUMBER 1 67