A unified superstructure for UML - Semantic Scholar

Vol. 4, No. 1, January–February 2005

A unified superstructure for UML Andy Evans, Paul Sammut, and James S. Willans Xactium Ltd., Sheffield, U.K. Alan Moore ARTiSAN Software Tools Ltd, Chelthenham, U.K. Girish Maskeri Tata Consultancy Services, India A key aspect of successfully using UML is understanding the semantics of the notations. UML 2 will increase the already substantial collection of notations supported by UML 1.x. At the same time, this will augment the difficulty users experience in understanding semantics. In this paper we propose that while the diverse notations may render concepts differently, the concepts can often be considered semantically equivalent. This gives rise to an architecture where two single abstract syntaxes (structure and behaviour) underpin UML 2’s seven concrete syntax. Because there a fewer semantically distinct concepts, this makes UML both easier to understand and substantially easier to implement.

1 INTRODUCTION A characteristic of languages is that the richer they become, the more difficult they are to use. UML 2 promises to delivery a number of new language constructs that enable a broader range of specifications to be constructed. A key issue in successfully using UML 2 is understanding the semantics of the augmented language. For example, what is the meaning of a class diagram in terms of a component diagram, or what is the meaning of a state machine in terms of an activity diagram. These are not easy questions to answer and involve understanding the semantics of each individual construct. The current approach to defining UML is to define an abstract syntax for each of the notations (see [3]). Each abstract syntax is associated with a concrete syntax that defines the rendering of the notations to the user, as illustrated in figure 1. This approach is also followed in the dominant submission to UML 2 superstructure [4]. Because every concrete syntax construct has a construct in the abstract syntax, there are as many semantic units to understand as there are concrete constructs. Consequently, comprehending the semantics of UML is (and will be) non-trivial. The approach proposed in this paper is to generalise the abstract syntax of UML 2 such that there is no longer an abstract syntax for each concrete syntax, rather a Cite this article as follows: Andy Evans et al: ”A unified superstructure for UML”, in Journal of Object Technology, vol. 4, no. 1, January–February 2005, pages 165–181, http://www.jot.fm/issues/issues 2005 01/article6

A UNIFIED SUPERSTRUCTURE FOR UML

Classes Concrete Syntax

Component Concrete Syntax

Use Case Concrete Syntax

Collaboration Concrete Syntax

State Machine Concrete Syntax

Activity Concrete Syntax

Sequence Concrete Syntax

Classes Abstract Syntax

Component Abstract Syntax

Use Case Abstract Syntax

Collaboration Abstract Syntax

State Machine Abstract Syntax

Activity Abstract Syntax

Sequence Abstract Syntax

Figure 1: The current approach to defining UML

Classes

Component

Use Case

Collaboration

Classes Concrete Syntax

Component Concrete Syntax

Use Case Concrete Syntax

Collaboration Concrete Syntax

State

Activity

Sequence

Activity Concrete Syntax

Sequence Concrete Syntax

Machine single abstract is shared by many concrete syntaxes. This generalisation is Concretesyntax Concrete Concrete Concrete Concrete Concrete Concrete Syntax Syntax Syntax Syntax Syntax Syntax motivated by the observation that there are many Syntax semantically equivalent constructs across diverse UML notations, for example join action is common to both state State Structure Behaviour Classes Component Use Case Collaboration of the resulting Activity Sequence is shown machines and activity diagrams. An overview architecture Machine Abstract Abstract Concrete Concrete Concrete Concrete Concrete Concrete Concrete Syntax Syntax Syntax it can Syntax From this be seenSyntax that twoSyntax abstractSyntax syntaxesSyntax underpin the in figure 2.Syntax spectrum of concrete syntaxes. Structure abstract syntax deals with notations such State Classes Component Use Case diagrams Collaboration and behaviour Activity Sequence as class diagrams and component abstract syntax deals Machine Abstract Abstract Abstract Abstract Abstract Abstract Abstract with notations state machines activity sequence Syntax diagrams. The Syntaxsuch as Syntax Syntax Syntax diagrams andSyntax Syntax consequence of this generalisation is that overall size of the abstract syntax definition is reduced. This means that there are fewer distinct semantics to understand, and a significant smaller definition to implement.

Structure Abstract Syntax

State Machine Concrete Syntax Behaviour Abstract Syntax

Figure 2: The proposed approach to defining UML

It should be noted that it is still necessary to define the semantics of the fewer abstract syntax concepts. The approach we have taken to this is described in [1]. In this, the abstract syntax is mapped down to a kernel of primitive concepts [2] each of which has an associated model-based semantics. Although this detail is outside of the scope of the paper, we observe that this mapping is greatly simplified by having fewer abstract syntax concepts to define the mapping for. This paper describes the two abstract syntax models, the (almost complete) concrete syntax for five of the concrete syntaxes. Due to space limitations we do not describe the concrete syntax for collaboration and use case diagrams and only the important constraints are included in presented models. The paper is now structured as follows. Sections 2 and 3 presents the structure and behaviour abstract and concrete syntax model respectively. Finally in section 4 we summarise our 166

JOURNAL OF OBJECT TECHNOLOGY

VOL 4, NO. 1

2 STRUCTURE

conclusions.

2 STRUCTURE Currently UML enables the definition of structural models using class diagrams. UML 2 augments this with the capability of modelling component diagrams. Component diagrams are used to express architectural level definitions of systems and are particularly used within the context of systems engineering. In the following sub-sections we demonstrate how a unification can be leveraged between class diagrams and component diagrams. This unification is enabled by the treatment of STRUCTURE components as classes and a component’s ports as attributes of a class. Summary

Abstract Syntax

Definition UML2Super::AbstractSyntax::Structure * role 1

1

Package

*

* role 1 roleOwner

PackagedElement

owned

roleOwner

1

Class

Association *

1

1 * role * owned StructuralFeature

roleOwner directionkind direction

1

* role * owned Connection

roleOwner

Attribute

* source 1 *

2

target 1 boolean inverse boolean connectable

end

* 1 type Classifier 1 super

1 sub

*

*

Generalization boolean inverse

Definition for AbstractSyntax::Structure package

Figure 3: Structure abstract syntax Classes

Figure Association 3 illustrates the abstract syntax for structure. The treatment of Class and associations its Features end is conventional, the important difference is the addition of Connection which relates two Attributes. Syntactically, a Connection binds the type of the related Attributes: Attribute

context Connnection inv: VOL 4, NO. 1


167


self.source.type = self.target.type

This constraint is mirrored in the semantic domain (not shown) and ensures that the values of the two Attributes are appropriately bound (see [2] for more details of the semantic domain and the role it plays in our approach to modelling). The semantic domain constraint must also takes into account the direction of Connection and whether the Connection is inverse to that direction. Only connectable attributes can be connected: context Connection inv: self.source.connectable and self.target.connectable

Packages, PackagedElements and Connections have a self association called role. This is a generalised version of UML 1.x role mechanism which enables candidate scenarios of the model element to be specified [5][195-203]. All model elements in the structure (and behaviour) abstract syntax have a role mechanism either directly or derived through generalisation1 . The relationship between a role and and a roleOwner is that the former can only constrain the semantics of the latter. The precise constraint for this association is dependent on the model element, in the case of class this is: context Class inv: self.role->forAll(role | role.memberStructuralFeature->excluding( role.memberStructuralFeature->select(s | s.isKindOf(Constraint))->forAll( feature | self.memberStructuralFeature->exists(feature.roleOwner))) and self.role->forAll(role | self.memberStructuralFeature->select(s | s.isKindOf(Constraint))->forAll(constraint | role.memberStructural->exists(constraint)))

Roles effectively create a parallel model mirroring the composition hierarchy of the roleOwner. A Package role must have PackagedElement roles for its role owners PackagedElements, and a Class role must have StructuralFeature roles for its role owners StructuralFeatures, and so on.

Class diagram The concrete syntax for Class diagram is shown in figure 4 and describes how a ClassBox can be the target of AttributeLines,AssociationLines and a GeneralisationLines. A ClassBox contains compartments for its Operations’s and Attribute’s strings. The mapping between the Class diagram model and Structure model is depicted in 5. 1

The repeating role pattern alludes to templates which are the means by which the definition presented in this paper has been specified, see [2] for more details. 168


VOL 4, NO. 1

CLASS

2 STRUCTURE

7.2 M ODEL UML2Super::ConcreteSyntax::Class AttributeLine

AssociationLine *

*

2

2

ClassBox

*

2

*

GeneralisationLine

containedClassBox 0..1 containingClassBox

* containedOperationCompartment

* containedAttributeCompartment

OperationCompartment

AttributeCompartment

containingClassCompartment * containedClassCompartment 0..1

ClassCompartment

0..1 containingOperationCompartment

0..1 containingAttributeCompartment

* containedOperationString

* containedAttributeString

OperationString

CLASS

AttributeString

Figure 7-1 Definition for ConcreteSyntax::Class package

7.4 A BSTRACT YNTAX M APPING FigureS4: Class diagram concrete syntax 7.2.1 Classes UML2Super::AbstractConcreteMapping::Class

AttributeCompartment

*

AssociationLine

1

associations views containedAttributeString The string within the AttributeCompartment. * 1

Association

ClassBox

Class

views

ClassBox

*

AttributeString

1

Attribute

views

associations * 1 OperationString containedAttributeCompartment The contained AttributeCompartment. views containedClassCompartment The contained ClassCompartment. * 1 AttributeLineThe contained containedOperationCompartment OperationCompartment. views GeneralisationLine

*

1 views

ClassCompartment

Operation

Attribute

Generalization

associations containedClassBox The contained Figure ClassBox. 7-2 The AbstractConcreteMapping::Class Package

Figure 5: Class diagram abstract syntax mapping OperationCompartment 7.5 E XAMPLE

associations containedOperationString The contained OperationString.

Figure 6 describes a vending machineClass1 as an instance of the class concrete syntax definition. As can be observed fromboolean thisattribute1 example, our class model conforms to the conventional UML 1.x definition. boolean Operation1 () 2U CONSORTIUM UML 2.0 SUBMISSION

2U CONSORTIUM UML 2.0 SUBMISSION

VOL 4, NO. 1

VERSION 0.2 – JANUARY 2003



51

53

169


V M Attributes theDisp:Dispenser CoinInput:Coin UserSelection:Product CoinOutput:Coin ProductOutput:Product theCP:CoinProcessor theCon:Console

theDisp

Dispenser Attributes ProductSelect:Order ProduceOutput:Product

Console

theCon

Attributes CoinControl:CCIF ProductChoice:Product ProductSelect:Order

theC P

CoinProcessor Attributes CoinOutput:Coin CoinInput:Coin CoinControl:CCIF

Figure 6: Class diagram of a vending machine

Component diagram Component diagrams describe systems as components and the relationship between the systems as connectors. When two systems are related via a connector, this specifies that data sent by one system is available to the other system (depending on the direction of connection). The concrete syntax model for component diagrams is shown in figure 7 and the mapping to the abstract syntax model is shown in figure 8. PortBoxes must map onto attributes which are Connectable:

context PortBox inv: self.views.connectable = true

The nesting of components is unfolded onto classes and their attributes. Given a ComponentBox A which contains a ComponentBox B, A and B are mapped to Classes and the class representing A must have an attribute of type B :

context ComponentBox inv: self.containedComponentBox->forAll(ccb | self.views.owned->includes(sf | ccb.views = a and a.isKindOf(Attribute)))

The equivalence of component and class models is concretely demonstrated by the component diagram illustrated in figure 9 which is semantically equivalent to the vending machine shown in figure 6. Those attributes in figure 6 which are shown 170


VOL 4, NO. 1

COMPONENT

2 STRUCTURE 6.2COMPONENT M ODEL

6.3 G RAPHICAL R EPRESENTATION UML2Super::ConcreteSyntax::Component

SYMBOL GRAPHICS * containedComponentBox Component ComponentBox Box 0..1

NOTES

Component

containingComponentBox 0..1 1 containingComponentBox

Pin Box * containedPortBox 2 PortBox

Connection Line

*

ConnectorLine

port

Figure 6-1 Definition M for ConcreteSyntax::Component package 6.4 A BSTRACT S YNTAX APPING Figure 7: Component diagram concrete syntax

6.2.1 Classes UML2Super::AbstractConcreteMapping::Component

ComponentBox *

associations ComponentBox containedComponentBox The contained ComponentBoxes. containedPortBox The contained PortBoxes. PortBox

*

1

Class

views

1

Attribute

views

ConnectorLine associations * ConnectorLine port The PortBoxes connected by the ConnectorLine.

1 views

Connection

6.2.2 Well-formedness Rules for AbstractConcreteMapping::Component package Figure 6-2 Definition

Figure 8: Component diagram abstract syntax mapping 6.2.3 Operations

as ports in figure 9 have their boolean connectable value set to false (not concretely rendered).



VOL 4, NO. 1

VERSION 0.2 – JANUARY 2003 VERSION 0.2 – JANUARY 2003


48

47

171


VM

Console ProductOrder

Product

Dispenser CCIF

Coin Processor

Product

Coin

Coin

Figure 9: Component diagram of the vending machine

VMBank

Power

Power

LeftVM/VM

RightVM/VM Dispenser Control

Figure 10: A Scenario of the vending machine’s component diagram

172


VOL 4, NO. 1

3 BEHAVIOUR

Figure 10 presents an example of the usefulness of the role mechanism for describing scenarios. In this, a bank of two vending machines is described, each machine being a particular scenario of the original machine. Figures 9 and 10 demonstrates a powerful aspect of the recursive treatment of roles, which is that the same concrete syntax can be used to describe both types and roles of types since they are the same model element (the basic type is a role whose roleOwner is self).

3 BEHAVIOUR In our definition of behaviour, a single abstract syntax model is used as a basis for use case, collaboration, state machines, activity diagrams and sequence diagrams. In this paper we deal only with state machines and activity diagrams.

Abstract Syntax The abstract syntax of behaviour illustrated in figure 11 can be broadly considered in two parts. The first part is a hierarchy of actions (which is made explicit in the lower half of figure 11) some of which have sub-actions. The second part is relations between actions such as Flow and Transition. At first sight, treating State as a type of Action may seem unconventional since the conventional interpretation is that it represents a static property of a system (i.e. the value of slots and objects) at a particular point in time. Our approach extends this property with dynamic aspects by defining a state to be an action for two reasons: 1. In UML, state machine states have dynamic properties. For example, a state state specifies an entry action, exit action and may continuously execute a do action until the exit action is invoked. Thus, it is natural and convenient to treat a state as an action. 2. State machines and activity diagrams share many concepts (for example join and fork ) the our superstructure proposal provides a common abstract syntax model for both these and other behavioural notations. This unification is leveraged by treating state machine states as actions. The formal definition of the semantics of behaviour is outside of the scope of this paper. However, informally the semantics is built around the ability to preempt execution. Each Action has a boolean flag which denotes whether it can be prematurely terminated. When a pre-emptable action is related by a type of flow, the action does not need to complete its execution before the flow can be executed. A transition’s effect Action cannot be pre-empted, an additional constraint captures this: VOL 4, NO. 1


173

Summary A UNIFIED SUPERSTRUCTURE FOR UML

Definition UML2Super::AbstractSyntax::Behaviour

Static Expression roleOwner 1 *

role

0..1 guard * * * *

Flow

role

* start 1 Action Vertex

1 * end

1 roleOwner

subaction

ownedflow

Action Transition

boolean preemptable

boolean isInternal boolean preempts *

1 0..1

0..1 effect

0..1

role

0..1

0..1 trigger

* 1

0..1

Operation

0..1 0..1 implementation 0..1 0..1 entry exit

Composite Action

Class

body

roleOwner

1 targetOperation * role 1 roleOwner

0..1 0..1

* Region

Signal

*

0..1

State

subregion

1

*

Static Expression

invariant Create Object Action

Action Vertex

Action

Simple Action Write Attribute Action

boolean preemptable Composite Action

Pseudo-Action

History

Final

Parallel Action

boolean isDeep Join

Sequential Action

Fork

Iteration Action

Choice

Selection Action

Junction

Region

Initial

State

Definition for AbstractSyntax::Behaviour package

Figure 11: Behaviour abstract syntax Classes

context Transition inv: self.effect.preemptable = false

As with the definition of structure, figure 11 includes a generalised version of UML 1.x’s role mechanism. This enables scenarios to be described over any behavioural model based on the abstract syntax.

State machine diagram The concrete syntax for state machines is shown in figure 12 and the associated abstract syntax mapping in figure 13. A top level state machine State is owned by a Class, only Regions can own sub-States: 174


VOL 4, NO. 1

3 BEHAVIOUR

context CompositeAction inv: self.subaction->forAll(sa | sa.isKindOf(State) implies self.isKindOf(Region)

A State has invariants which must hold true during the lifetime of its execution. The nesting of States results in the propagation of invariants down the state hierarchy:

context State inv: self.subregion->forAll(sr | sr.subaction->forAll(sa | sa.isKindOf(State) implies (self.invariant->forAll(i | sa->includes(i)))))

A Transition is semantically a type of guarded Flow (the guard is denoted by the trigger in figure 11). Because of the pre-emption semantics, States are not concerned with checking whether a Transition can fire. It is the responsibility of the Transition to ensure that when it fires that source States are terminated. The entry and exit actions of States are not pre-emptable:

STATEMACHINE context State inv:

Summary self.entry.preemptable

= false and self.exit.preemptable = false

Therefore when a Transition pre-empts a State, the entry and exit actions will

Definition always execute. UML2Super::ConcreteSyntax::StateMachine

ChoiceSymbol StateDiagram ForkSymbol 0..1 containingStateDiagram JunctionSymbol *

* containedTransitionLine * Transition Line

* containedStateSymbol end 2

StateSymbol

JoinSymbol

* containedStateSymbol

containedTransition Line

FinalSymbol

StateBox

PseudoStateSymbol

History Symbol

0..1 containingStateBox

containingRegionCompartment 0..1 0..1

containingRegionCompartment

containedEntryCompartment containedActionCompartment containedInternalTransitionCompartment

* containedRegionCompartment RegionCompartment

0..1 containedExitCompartment ExitCompartment

0..1

EntryCompartment

0..1 ActionCompartment

0..1 InternalTransitionCompartment

Definition for ConcreteSyntax::StateMachine package

Figure 12: State machine concrete syntax

Classes ChoiceSymbol VOL 4, NO. 1 associations

views

FinalSymbol associations


175

STATEMACHINE Summary A UNIFIED SUPERSTRUCTURE FOR UML

Definition UML2Super::AbstractConcreteMapping::StateMachine StateSymbol

*

1

State

views Transition Line

*

1

Transition

views RegionCompartment

*

1

Region

views FinalSymbol

*

ForkSymbol

*

1 views

Final

1

Fork

views History Symbol

*

1

History

views InitialSymbol

*

1

Initial

views JoinSymbol

*

1

Join

views JunctionSymbol

*

1

Junction

views ChoiceSymbol

*

1

Choice

views

Definition for AbstractConcreteMapping::StateMachine package

Figure 13: State machine abstract syntax mapping Classes Well-formedness Rules In the current model there is an ingredient of non-determinism. A Transition can occur when the Transition’s guard is enabled, but there is no semantic which Operations ensures a Transition will definitely occur when enabled. This is consistent with UML 1.x.

Figure 14 describes the behaviour of the Dispenser component of a vending machine as an instance of state machine concrete syntax definition. This serves to demonstrate the conventional consideration of state machines in the presented definition.

Activity diagram Activity diagrams share many common features with state machine diagram. Activity state and state machine state are semantically equivalent, transitions are a kind of flow with some added detail (see figure 11) and both fork and join actions are common to both types of diagrams. The homogenous nature of state machine diagrams and activity diagrams is reflected in the mapping of activity diagram concrete syntax (figure 15) as shown in figure 16 with concepts shared by the state machine concrete syntax (figure 12). Figure 17 illustrates the use of the activity diagram in describing the behaviour of the vending machine. Unlike component diagrams and class diagrams it does not make sense to show the same model viewed by these alternative notations, during the design of systems they are usually used mutually exclusively. What figures 14 176


VOL 4, NO. 1

3 BEHAVIOUR

Dispense

[prodq=0]

[prodq>0 Available

Idle Check

SelectItem

Figure 14: State machine of the vending machine

and 17 do demonstrate is that the sharing of semantics between state machines and activity diagrams. For example, the Junction symbol in figure 17 has precisely the same underlying abstract syntax and semantics as that in the state machine of figure 14.

VOL 4, NO. 1


177

A UNIFIED SUPERSTRUCTURE FOR UML ACTIVITY

8.2 M ODEL UML2Super::ConcreteSyntax::Activity

0..1

* ownedSwimLane

SwimLane

0..1 1

ActivityDiagram

owningActivityDiagram containingSwimLane 0..1 containingSwimLane

* containedActionSymbol

* containedFlowLine *

FlowLine

2

ActionSymbol

flowend * containedFlowLine

*

containedActionSymbol

containingActionBox 0..1

0..1

ActionBox

PseudoActionSymbol

containingActionBox

JoinSymbol

ForkSymbol

InitialSymbol

FinalSymbol

JunctionSymbol

ChoiceSymbol

InitialSymbol

Figure 8-1 Definition for ConcreteSyntax::Activity package

Figure 15: Activity diagram concrete syntax ACTIVITY 8.2.1 Classes

ActionBox

8.4 A BSTRACT S YNTAX M APPING

associations containedActionSymbol The contained ActionSymbols. containedFlowLine The contained FlowLines. UML2Super::AbstractConcreteMapping::Activity containedPinBox The contained PinBoxes. ConnectorLine

*

1

Connection

views

ActivityDiagram ActionSymbol

*

associations ownedSwimLane The PinBox owned SwimLanes. *

1

Action Vertex

views 1

Pin

views

ConnectorLine

FlowLine

associations SwimLane end The connectorLine end’s. ChoiceSymbol

*

1

Flow

*

views 1

Class

views *

1

Choice

*

views 1

ForkSymbol

*

views 1

Fork

2U CONSORTIUM UML 2.0 SUBMISSION InitialSymbol

*

views VERSION 0.2 – JANUARY 20031

Initial

JoinSymbol

*

views 1

Join

JunctionSymbol

*

views 1

Junction

FinalSymbol

Final

56

views

Figure 8-2 Definition for AbstractConcreteMapping::Activity package

Figure 16: Activity diagram abstract syntax mapping

178




VOL 4, NO. 1

58

4 CONCLUSION

Entering Money

Refund Money

Check Money

Dispense Change Check Product Availability Dispense Product

Figure 17: Activity diagram of the vending machine

4 CONCLUSION The next generation of UML is an important step in enabling model oriented software engineering. In order for it to cater for diverse requirements UML 2 must contain new notations not currently found in UML 1.x. We have argued that this does not necessarily mean introducing fundamentally new abstractions (new semantics). Instead the new abstractions can be considered as new syntax which share a semantic underpinning with existing notations. The abstract syntax presented here is substantially smaller than UML 1.x even though it supports the new notations required by UML 2.0. The models described in this paper have been implemented by Tata Consultancy Services (TCS) in their Mastercraft tool. The vending machine model shown throughout the paper have been modelled using Mastercraft, adding weight to the presented approach. Because of the unification of abstract syntax, and interesting aspect of the presented approach is that new concrete syntaxes can be formed consisting of a hybrid of the distinct concrete syntaxes. For instance, it is possible to have a behavioural notation that combines aspects of state machines, activity diagrams and sequence diagrams. We intend to explore this avenue as future work. VOL 4, NO. 1


179


Acknowledgments We are grateful to Sreedhar Reedy and R. Venkatesh of TCS India who have over seen the tool implementation of the described models. We are also grateful to TCS and BAe Systems who have generously funded the research described here.

REFERENCES [1] 2U. 2nd revised submission to OMG RFP unified modeling language superstructure version 2.0. http://www.2uworks.org/uml2submission/. ad/02-12-23). [2] 2U. 3rd revised submission to OMG RFP unified modeling language infrastructure version 2.0. http://www.2uworks.org/uml2submission/. ad/03-01-08). [3] Object Management Group. Unified modeling language specification version 1.4. http://www.omg.org. ad/01-09-67. [4] U2 Partners. 2nd revised submission to OMG RFP unified modeling language superstructure version 2.0. http://www.u2-partners.org/artifacts.htm. ad/0301-01). [5] James Rumbaugh, Ivar Jacobson, and Grady Booch, editors. The Unified Modeling Language Reference Manual. Addison Wesley, first edition, 1999.

About the authors Andy Evans is managing director of Xactium Limited, a company that provides advanced modelling tools and services to the software development industry. He was previously a lecturer at York University, where he was heavily involved in modelling research and industrial consultancy. He was programme chair of UML2000 and is an associate editor of software and systems modelling journal (SOSYM).

Paul Sammut is a senior consultant at Xactium Ltd., a company providing tools, technology and solutions for Model Driven Development. Prior to joining Xactium, he was a Research Associate at the Department of Computer Science, University of York (UK), where his key research interests were model driven development, and tools and languages for metamodelling. Much of this work has been published in journals and conference proceedings, and recently he has co-authored a book on Applied Metamodelling.

180


VOL 4, NO. 1

4 CONCLUSION

James S. Willans holds a PhD from the University of York where he was until recently a Research Associate pursuing interests included metamodelling languages and tool support for language engineering. He now works as senior consultant at Xactium (www.xactium.com), a company providing tools and consultancy for model-driven development, and is co-author of a book on Applied Metamodelling.

Alan Moore is VP for ARTiSAN Software Tools Ltd. Alan has 18 years of experience in the development of real-time and objectoriented methodologies, and their application in a variety of problem domains. He is responsible for the development and evolution of Real-time Perspective, ARTiSAN’s process for real-time systems development. He is an active member of the Object Management Group and chaired both the finalisation and revision task forces for the UML Profile for Schedulability and Performance and Time, and is the co-chair of the OMGs Real-time Analysis and Design Working Group. He is ARTiSANs technical lead in the SysML consortium.

Girish Maskeri is a scientist at Tata Resesarch Development and Design Center, Pune, India. His research interests include metamodelling, Model transformation and Component based engineering.

VOL 4, NO. 1


181