Style-Based Modeling and Reﬁnement of Service-Oriented ...

Software and Systems Modeling manuscript No.(will be inserted by the editor)

Style-Based Modeling and Refinement of Service-OrientedArchitectures?

A graph transformation-based approach

Luciano Baresi1, Reiko Heckel2, Sebastian Thone3, Daniel Varro4

1 Politecnico di Milano, Dipartimento di Elettronica e Informazione, Italy – e-mail: [email protected] University of Leicester, Department of Computer Science, U.K. – e-mail: [email protected] University of Paderborn, International Graduate School Dynamic Intelligent Systems, Germany – e-mail: [email protected] Budapest University of Technology and Economics, Department of Measurement and Information Systems, Hungary –

e-mail: [email protected]

Received: date / Revised version: date

Abstract Service-oriented architectures (SOA) pro-vide a flexible and dynamic platform for implementingbusiness solutions. In this paper, we address the mod-eling of such architectures by refining business-orientedarchitectures, which abstract from technology aspects,into service-oriented ones, focusing on the ability of dy-namic reconfiguration (binding to new services at run-time) typical for SOA.

The refinement is based on conceptual models of theplatforms involved as architectural styles, formalized bygraph transformation systems. Based on a refinementrelation between abstract and platform-specific styleswe investigate how to realize business-specific scenarioson the SOA platform by automatically deriving refined,SOA-specific reconfiguration scenarios.

Key words service-oriented architecture – architec-tural style – architecture refinement – graph transfor-mation

1 Introduction

The service-based paradigm to structure and modular-ize software systems becomes more and more popular forcomplex distributed applications with high degree of dy-namic reconfigurations and interactions among systemcomponents. This article focuses on the architecturalaspect of service-based software engineering and intro-duces a methodology for deriving service-oriented archi-tectures (SOA) from high-level business-oriented archi-tecture descriptions.

? Research partially supported by the European ResearchTraining Network SegraVis (on Syntactic and Semantic In-tegration of Visual Modelling Techniques)

Software architectures play an important role in soft-ware development [42]. As abstract models of the run-time structure they help to bridge the gap between userrequirements and implementation. In the context of e-business, self-healing, or mobile systems, dynamic archi-tectures gain more and more importance. They representsystems that do not simply consist of a fixed, static struc-ture, but can react to certain requirements or events byrun-time reconfiguration of its components and connec-tions. Thus, models of dynamic architectures do not onlyhave to consider component structure and interactions,but also dynamic changes of that structure.

Service-oriented architectures are one import kind ofdynamic architectures. They allow for automated ser-vice publication and discovery at run-time. For instance,whenever a service cannot be provided with the requiredquality-of-service any longer, the service requester coulddynamically search for and change to a new service.

Designing such dynamic architectures is a complextask because one has to cope with both business-drivenand platform-driven requirements: The business require-ments prescribe certain component structures, interac-tions, and reconfigurations which have to conform to theinteraction and reconfiguration mechanisms provided bythe underlying middleware platform.

We propose to deal with this complexity by a step-wise refinement approach that covers various degreesof platform abstraction. At first, the software architectderives an abstract model of the architecture from theuser and business requirements. This model roughly cor-responds to the conceptual architecture view proposedin [23]. It mainly covers the functional aspects encapsu-lated in business-related components. Such a business-level architecture description abstracts from the concretemiddleware and run-time platform of the system, and it

2 Luciano Baresi et al.

omits elements that are needed to use platform-specificcommunication and reconfiguration mechanisms.

For instance, a business-level architecture model de-scribes business components and their interfaces but ne-glects the distinction between ordinary components andpublished service components. Consequently, it does notcontain any SOA-specific elements like service descrip-tions and discovery services, either. Also, it elaborateson the various use cases of the system by business-oriented scenarios of component interactions, but it ne-glects SOA-specific interactions and reconfiguration op-erations required for service publication and discovery.

Only later in the design process, when the decision fora service-oriented middleware platform has been made,more and more non-functional requirements and SOA-specific aspects are integrated into the core functionality.This leads to a SOA-specific model of the applicationarchitecture which refines both the structural and thebehavioral parts of the business-level model accordingto the service-oriented paradigm.

A recent example of this general modeling principle isthe Model-Driven Architecture (MDA)1 [30] put forwardby the OMG. Here, platform-specific details are initiallyignored at the model-level to allow for maximum porta-bility. Then, these platform-independent models are re-fined by adding details required to map to a given tar-get platform. Thus, at each refinement level, one imposesmore assumptions on the resources, constraints, and ser-vices of the chosen platform.

In software architecture research, architectural stylesare used to describe families of architectures by com-mon resource types, configuration patterns and con-straints [2]. As Di Nitto and Rosenblum argue in [32],the restrictions imposed by a certain choice of platformcan be considered as an architectural style, too. More-over, to account for component interactions and plat-forms that support dynamic reconfigurations like SOA,we suggest in [4] to extend the classical notion of archi-tectural style by defining not only structural constraintsbut also platform-specific communication and reconfig-uration mechanisms.

As described in [4], we formally define architecturalstyles as graph transformation systems including typegraph, constraints, and transformation rules. Based onthat, we investigate refinement relationships between ab-stract and concrete styles in [5]. They enable us to checkif a given architecture is a refinement of another one witha special focus on the refinement of business-level scenar-ios of communication and reconfigurations into platform-specific scenarios.

Our refinement criteria guarantee both semantic cor-rectness and platform consistency. This means that theplatform-specific scenario comprises the same functionalbehavior as the business-level scenario, and that it is

1 www.omg.org/mda/

consistent with constraints and mechanisms imposed bythe chosen target platform.

In this article, we apply the approach to service-basedarchitectures and extend the SOA case study sketchedin [4]. We present a complete definition of the architec-tural style for service-oriented architectures including allrelevant mechanisms for service publication, discoveryand connectivity. We also define an abstract, business-level style and a refinement relationship between the ab-stract and the SOA-specific style. Moreover, we showhow this relationship can be used to check for correctarchitecture refinements and to derive SOA-specific sce-narios from given business-level scenarios.

Since refinements can be tedious and error-prone, weshow how the behavior refinement problem can be for-mulated as a reachability problem which can be solvedby classical graph transformation and model checkingtools. This allows, within the usual limitations, an au-tomated refinement of business-level architectures intoSOA-specific architectures.

In order to account for user-friendly models, we alsodiscuss how to combine the formal, graph-based rep-resentation of architectures with the Unified ModelingLanguage (UML)2. For this purpose, we introduce anextension of the UML meta-model, proposed as a UMLprofile for service-oriented architectures in [19], and de-fine a mapping between the profile and the elements ofthe architectural style. This mapping can be used by ed-itors and other tools to provide a user-friendly syntaxfor complex architectural descriptions.

The rest of the article is organized as follows. InSect. 2, we introduce a typical service-based applicationas running example for this article. In Sect. 3, we explainhow architectural styles can be used as conceptual plat-form models for different levels of platform abstractionand how they can be formalized by graph transformationsystems. We define an abstract style for business-levelarchitectures and a specific style for service-oriented ar-chitectures. In Sect. 4, we discuss the use of UML andUML profiles as concrete notation for the presented SOAmodels. In Sect. 5, we define refinement relationshipsbetween architectural styles and show how they can beused in order to derive SOA-specific architectural modelsfrom business-oriented models. We survey related workin Sect. 7, and Sect. 8 concludes the article.

2 The SmartCar example

Throughout this article, we use a simple scenario, takenfrom the automotive domain, to demonstrate the mainfeatures of our approach. The scenario foresees how theavailability of special-purpose and context-sensitive ser-vices will change our way of planning trips with our car.

While driving our car, we can inquire a map serviceto get the best (cheapest) map of the area. Another ser-

2 www.uml.org

Style-Based Modeling and Refinement of Service-Oriented Architectures 3

vices computes the best itinerary to reach the final des-tination. The computation is not only based on staticinformation, like the cheapest route (i.e., no fees) or thefastest one (i.e., always on highways), but also uses ac-tual traffic conditions to better plan the itinerary.

The first step towards design leads to a platform-independent architecture that can be informally depictedby means of the UML component diagrams of Fig. 1.

The scenario can be enacted by means of the fourspecial-purpose components of Fig. 1, which specify theirinteraction ports in terms of required and supplied in-terfaces. The Vehicle is the only active component whichstarts the scenario and acts as coordinator of any dy-namic interaction. The MapRequest component providesboth the best (highest resolution) or cheapest map. Sincewe do not aim at discussing the way services and theirparameters can be negotiated, it is the service itself thatsupplies the best option without negotiating parameters.The ItineraryDefinition component complements boughtmaps with the itineraries we choose. Again, we allow forthe cheapest and fastest itineraries. This component in-teracts with the TrafficInformation system to identify thefastest trip with respect to the actual traffic conditions.

1

v:Vehicle m:MapRequestp2:Map-Provider

p3:Itinerary-Requester

Configuration(UML Communication Diagram):

p1:Map-Requester

MapConnector{new}

i:ItineraryDefinition t:TrafficInformation

p4:ItineraryProvider

p7:Info-Requester

p8:Info-Provider

TrafficInfoConnector{transient}

ItineraryConnector {new}

Fig. 1 Component diagram of the SmartCar system

Since the vehicle moves around a region, the actualcomponents must be identified and used while the systemis executed in a fully dynamic fashion. This means thatthe actual links among the components change while thescenario evolves. These changes are constrained by avail-able reconfiguration mechanisms.

In the component diagram, those reconfigurations areindicated by attachments to affected elements: {new} fornewly created connections and {transient} for connec-tions that are created and then removed after a while.

System requirements also include certain scenarios ofcomponent interaction. For instance, as shown in Fig. 2,Vehicle (i.e., the driver) asks the MapRequest for the bestmap of the area. It also selects the itinerary to reach itsfinal destination. For this purpose, it queries Itinerary-Definition, which in turn queries the TrafficInformationservice to select the fastest offer.

After the platform-independent model, the next de-velopment phase requires the selection of a specific plat-form the system should be deployed on. Similar to the

1

v :Vehicle

inquireMap()

maps

selectMap()

getTrafficInfo()info

itineraries

m :Map-Request

i :Itinerary-Definition

t :Traffic-Information

askForItineraries()

sd plan trip

Fig. 2 Simple scenario of the SmartCar system

intentions of MDA [30], the platform-independent modelis in principle portable to different platforms. In thiscase, the development team decides to implement theSmartCar system based on a service-oriented architec-ture (SOA), e.g., Web Services. This means that thebusiness components expose their functionality as ser-vices over a network to vehicles. A service is equippedwith a description of the provided functionality includinginformation where and how to access it.

As shown in Fig. 3, SOA involves three different roles:service providers, service requesters and discovery agen-cies. The service provider runs and exposes the service.Also, the provider has to publish the service description,in order to enable dynamic service discovery and to allowrequesters to access the service.

Since providers and requesters usually do not knoweach other in advance, the service descriptions are pub-lished via third-party discovery agencies. They catego-rize the descriptions and deliver them in response toqueries issued by service requesters. As soon as the ser-vice requester retrieves a service description that meetsits requirements, it can use it to interact with the service.

1

DiscoveryAgency

DiscoveryAgency

ServiceRequestorService

RequestorServiceProviderServiceProvider

ServiceDescription

ServiceDescription

Interact

PublishQuery

ServiceRequirements

Fig. 3 Roles in a service-oriented architecture, cf. [9]

Service-oriented architectures are highly dynamicand flexible: Components and services are only looselycoupled and communicate according to standardized


protocols; service descriptions with interface specifica-tions are exchanged at runtime; thus, service requesterscan dynamically replace unsatisfactory services if otherservices provide a better alternative concerning function-ality or quality. This might also become necessary forself-healing purposes, e.g., if a service is not reachableany longer due to some network problems.

To integrate SOA-specific features like service dis-covery into system design, we refine the business-levelarchitecture into a SOA-specific architecture. This doesnot only involve structural refinements like introducingdiscovery services and service descriptions but also be-havioral refinement of the reconfiguration scenarios. Forinstance, the creation of a new connection to a servicemight require service discovery operations beforehand.

In the following sections, we show how our refine-ment approach can be applied to this sample application.We explain the use of architectural styles as conceptualplatform models and how the architectural models canbe expressed in terms of these styles. Then, we exem-plify our notion of behavioral refinement between a stylefor platform-independent architectures and a style forservice-oriented architectures.

3 Architectural styles as platform models

In this section, we revisit our approach from [4] touse architectural styles as conceptual platform modelswhich are formalized as typed graph transformation sys-tems [11]. After a brief introduction to graph transforma-tions, we present a platform-independent architecturalstyle for business-level architectures and a platform-specific architectural style for service-oriented architec-tures.

As we want to model software architectures in re-lation to their computational infrastructure at differ-ent levels of platform abstraction, we need a conceptualmodel for each of these infrastructures. For such a con-ceptual platform model, we consider the following fourrequirements:

1. It has to define the vocabulary of elements that areto be considered in an architecture description forthe chosen platform. In an architecture description,the engineer can then use this vocabulary to defineapplication-specific types as well as runtime configu-rations of these types.

2. It has to define and constrain the relationships thatare allowed among the various architectural elementsof the vocabulary.

3. It has to define the communication mechanisms thatare provided by the platform to let the architec-tural elements interact. An architect who wants todesign interaction scenarios among software compo-nents can then use these communication mechanismsin the scenarios.

4. It has to define the reconfiguration mechanisms thatare provided by that platform to let a dynamic ar-chitecture evolve at runtime and to change its cur-rent configuration. An architect who wants to designscenarios of architectural behavior can then includereconfigurations that conform to these mechanismsin the scenarios.Since a platform model constrains the possible appli-

cation architectures according to the assumptions aboutthe underlying platform, it can also be considered as anarchitectural style that characterizes the family of archi-tectures which conform to the platform-specific restric-tions and mechanisms.

While the classical notion of architectural style coversstructural constraints only like common vocabulary andtopological patterns [2], we extend this notion by alsotaking into account the communication and reconfigura-tion mechanisms as required above. For this purpose, werepresent architectural styles as typed graph transforma-tion systems.

A typed graph transformation system G =〈TG, C,R〉 consists of a type graph TG to define thearchitectural elements and their relationships, a set ofconstraints C to further restrict the valid models, and aset R of graph transformation rules.

Nodes of the type graph define the architectural el-ements, i.e., the vocabulary of the architectural style.Edges define the possible links and relationships amongthese elements. A type graph can be depicted as a UMLclass diagram as shown in Fig. 4. We can also define sub-types, which inherit all the associations of its supertype,and attributes, which describe additional properties ofthe respective element.

We use the vocabulary in a concrete application ar-chitecture by representing system configurations as in-stance graphs of the type graph. According to [11], avalid instance graph G ∈ GraphTG has to be equippedwith a structure-preserving mapping to the fixed typegraph TG, formally expressed as a graph homomorphismtpG : G → TG. In combination with the UML class dia-gram for the type graph, we use UML object diagrams todepict instance graphs. One can assign attribute valuesto the instances in an object diagram in order to addinformation about their current state.

Along with the type graph comes the set C of con-straints that further restrict the set of valid instancegraphs. Simple constraints already included in the classdiagrams are cardinalities that restrict the multiplicity oflinks between the elements (omitted cardinality means0..n by default). More complex restrictions can be de-fined, e.g., using expressions of the Object ConstraintLanguage (OCL) [33], which is part of the UML. To-gether, the type graph and the constraints satisfy thefirst two requirements stated above for platform models.

The third and fourth requirement are handled bygraph transformation rules. They represent both com-munication and reconfiguration mechanisms provided by


the considered platform. Examples for such rules can befound in Table 1.

The application of a transformation rule to an in-stance graph results in rewriting a certain part of thatgraph. Since, in our case, instance graphs represent sys-tem configurations, the transformation rules are well-suited to model reconfiguration mechanisms that can beapplied to change the system configuration.

In order to treat communication mechanisms in thesame way, we have to encode communication-related in-formation into the instance graphs. For this reason, weadd dedicated nodes to the type graph which represent,e.g., messages with edges to their sender, receiver, andcurrent position. Then, special transformation rules canbe defined to create and transmit messages.

Altogether, the consecutive applications of transfor-mation rules to a given instance graph, also called atransformation sequence, can be used to model a certainscenario of both reconfiguration and communication op-erations.

Formalization: Formally, a graph transformation ruler : L ; R consists of a pair of TG-typed instance graphsL,R such that the intersection L∩R is well-defined (thismeans that, e.g., edges which appear in both L and R areconnected to the same vertices in both graphs, or thatvertices with the same name have to have the same type,etc.). The left-hand side L represents the pre-conditionsof the rule while the right-hand side R describes thepost-conditions.

According to the Double-Pushout semantics [14], theapplication of a transformation rule r to a host graphG, yielding a direct transformation step G

r,oL=⇒ H, isperformed in three steps:

1. Find an occurrence oL of the left-hand side L in thecurrent host graph G, formally a structure-preservinggraph morphism oL : L → G.

2. Remove all the vertices and edges from G which arematched by L \ R. We must also be sure that theremaining structure D := G\oL(L\R) is still a legalgraph, i.e., that no edges are left dangling because ofthe deletion of their source or target vertices. In thiscase, the dangling condition [14] is violated and theapplication of the rule is prohibited.

3. Glue D with a copy of R \ L to obtain the derivedgraph H. We assume that all newly created nodesand edges get fresh identities, so that G ∩H is well-defined and equal to the intermediate graph D.

A transformation sequence s = (G0r1,o1=⇒ · · · rn,on=⇒

Gn) in G, briefly G0 ⇒∗G Gn, is a sequence of consecutive

transformations using the rules of G such that all graphsG0, . . . , Gn satisfy the constraints C. As above, we as-sume that fresh identifiers are given to newly created el-ements, i.e., ones that have not been used before in thetransformation sequence. In this case, for any i < j ≤ nthe intersection Gi ∩ Gj is well-defined and represents

that part of the structure which has been preserved inthe transformation from Gi to Gj .

After this introduction to graph transformation the-ory, we now illustrate the concepts by two samplegraph transformation systems that represent architec-tural styles for business-level and service-oriented archi-tectures. Later in the article, these styles are used todemonstrate the stepwise refinement approach for de-veloping complex, service-oriented architectures.

3.1 A style for business-level architectures

The first architectural style we define represents ahigh level of platform abstraction and can be used forbusiness-level architecture descriptions. At the businesslevel, we do not want to consider platform-specific as-pects but concentrate on core functionalities. Therefore,we avoid as many assumptions as possible about theunderlying platform and assume a basic computationalinfrastructure for component-based, distributed systemsonly.

As usual in architecture descriptions [42], the styleprescribes to use components and connectors as first-class entities to configure a system architecture. Compo-nents are considered as encapsulated black boxes whichcan communicate with their environment through ded-icated ports only. Ports are characterized by providedand required interfaces. Two components can only in-teract with each other if their ports are connected by aconnector.

1

Component-Type

PortTypeInterfaceprovidesrequires

Connector-Type Connector

Component

connects2

allows

1

1

1

1ownssupports

isInstanceOf

isInstanceOf

isInstanceOf

Operation

Type graph:

defines

1 2

Portused:Boolean

0..1

0..1

sentVia0..1

respondsTo1

receivessends

Request Response

0..1

calls 0..1

Message

Fig. 4 Type graph of the business-level style

Type graph: The type graph of the style is shown inFig. 4. It can be subdivided into two parts: The left halfcontains elements to define application-specific types,i.e., the ComponenTypes, the supported PortTypes (in-cluding provided and required Interfaces), and the Con-nectorTypes. The right half of the diagram contains el-ements to define the runtime configuration of a systemwith Components, Ports, and Connectors, i.e., concreteinstances of the aforementioned types respectively.


Consequently, instance graphs of the type graph de-scribe both application-specific types as well as runtimeconfigurations of concrete instances thereof. The type in-formation allows, e. g., to determine the interfaces pro-vided or required by a certain component. Moreover, thetransformation rules presented below need to access thetype information in order to check type compatibilitywhen creating new instances. Note that the same tech-nique of including elements for both application typesand runtime instances in a single type graph is also usedin the UML meta-model [34].

Attributes can be used to store additional informa-tion in a node. For example, we add the boolean at-tribute used to the Port node in order to distinguish be-tween free and already used ports. The current value ofthe attribute can be queried, e.g., before a transforma-tion rule is applied. For instance, the rule openPort inTab. 1 can only be applied to open a new port for acomponent if there is no other free port left.

As mentioned before, we have to include special com-munication elements in the type graph in order to ex-press communication mechanisms by graph transforma-tion rules. For this reason, the type graph contains aMessage node which is specialized into subtypes Requestand Response.

Constraints: Besides the cardinalities given in the classdiagram, there is a set of additional OCL constraintswhich further exclude undesired instance graphs. For ex-ample, the following expression ensures that a Connectoronly connects those Ports whose PortTypes are allowedby its ConnectorType:

context Connector inv:

self.port.portType -> forAll(pt|

self.connectorType.portType -> includes(pt))

With the help of the type graph and the constraints,we can now model system configurations as instancegraphs that conform to the business-level style. Figure 5shows an example which models the initial configurationof the SmartCar system.

1

isInstanceOfm:Component MapRequest

:ComponentTypeMapProvider

:PortTypesupports

t:Component

v:Component

i:Component

Vehicle:ComponentType

ItineraryDefinition:ComponentType

TrafficInformation:ComponentType

MapRequester:PortType

ItineraryRequester:PortType

ItineraryProvider:PortType

InfoRequester:PortType

InfoProvider:PortType

isInstanceOfsupports

supports


supports

isInstanceOf supports

MapConnector:ConnectorType

TrafficInfo-Connector

:ConnectorType

Itinerary-Connector

:ConnectorType

allows

allows

allows

allows

allows

allows

Fig. 5 Instance graph for the SmartCar application

Although such instance graphs may easily becomelarge and unreadable, they are still suitable as formalrepresentation inside tools. In order to facilitate the han-dling of larger models by end users, we recommend to ap-ply the UML as concrete notation as discussed in Sect. 4.

Transformation rules: The architectural behavior ofour models depends on the communication and recon-figuration mechanisms provided by the infrastructure orthe platform. For the business-level style, we assume thatports can be opened or closed and that connectors canbe created or removed, but we abstract from mechanismsfor finding the right partner components and defer thisquestion to the platform-specific style. Moreover, we as-sume a basic communication mechanism which is basedon message exchange via established connectors.

These mechanisms are defined by the graph transfor-mation rules listed in Table 1. As an example, considerthe first rule openPort which creates a new port for acomponent. The pre-condition on the left-hand side de-mands that the type of the component supports the typeof the port to be created.

As we want to avoid that the rule is applied againand again to the same component creating an unboundednumber of ports, we add a negative application conditionto the rule. Such a negative condition is depicted bycrossed-out elements like, e.g., the Port node p in ruleopenPort. It prevents the application of the rule to anyoccurrence of the left-hand side which can be extendedby the crossed-out elements. In the case of openPort, thismeans that the rule is only applicable if the componentdoes not already own a free port of the selected porttype.

According to the right-hand side of openPort, a ruleapplication results in the creation of a new port for thecomponent. While on the left-hand side one can queryattribute values, at the right-hand side one can assignattribute values. In this case, the value of the used at-tribute of the new port is initially set to false.

With these remarks, we believe that the rest of Tab. 1should be self-explanatory. It contains further rules tocreate or remove connections, to send or receive requestsand responses, and to remove finished messages.

Table 1 Transformation rules of the generic style

1

openPort

c:Component

pt:PortTypesupportsct:Component-Type

isInstanceOf

owns

isInstanceOf

p:Portused==false

closePort

c:Component owns p:Portused==true

pt:PortType

isInstanceOf

c:Connector

connects

c:Component

pt:PortType

c:Component


isInstanceOf

owns p:Portused:=false

isInstanceOf

openPort:If a component does not own a free port of a supportedport type, this rule creates one.


1

openPort

c:Component


isInstanceOf

owns

isInstanceOf

p:Portused==false

closePort

c:Component owns p:Portused==true

pt:PortType

isInstanceOf

c:Connector

connects

c:Component

pt:PortType

c:Component


isInstanceOf

owns p:Portused:=false

isInstanceOf

closePort:If a used port is not any longer connected to a connector,this rule deletes the port.

1

connect

c1:Component

owns

pt1:PortTypeisInstanceOf

supports

ct1:ComponentType

isInstanceOf

c2:Component

owns


supports

ct2:ComponentType

isInstanceOf

conT:ConnectorType

allows

allows

con:Connector

connects

connects

isInstanceOf

port1:Portused:=true


c1:Component

owns


supports

ct1:ComponentType

isInstanceOf

c2:Component

owns


supports

ct2:ComponentType

isInstanceOf

conT:ConnectorType

allows

allows

port1:Portused==false


connect:If two components own a free port each and there is a com-patible connector type, this rule creates a new connectorbetween the two ports.

1

disconnect

port1:Port

port2:Port

conT:ConnectorType

c:Connector

connects

connects

isInstanceOf

port1:Port

port2:Port

conT:ConnectorType

m:MessagesentVia

disconnect:If a connector between two ports does currently not trans-port any message, it can be removed by this rule.

1

callOperation

receiveCall

receives

r:Requestsends

sentViacalls

to:Port

con:Connector

from:Port

connects

connects

pt:PortTypeisInstanceOf

i:Interface

provides

op:Operation

defines

to:Port

con:Connector

from:Port

connects

connects


i:Interface

provides

op:Operation

defines

r:Request

sends

sentViacalls

to:Port

con:Connector

from:Port

connects

connects


i:Interface

provides

op:Operationdefines

receives

r:Request

sends

sentViacalls

to:Port

con:Connector

from:Port

connects

connects


i:Interface

provides

op:Operationdefines

callOperation:If a port is connected to another port that provides acertain operation, then the port can send a request callingthat operation.

1

callOperation

receiveCall

receives

r:Requestsends

sentViacalls

to:Port

con:Connector

from:Port

connects

connects


i:Interface

provides

op:Operation

defines

to:Port

con:Connector

from:Port

connects

connects


i:Interface

provides

op:Operation

defines

r:Request

sends

sentViacalls

to:Port

con:Connector

from:Port

connects

connects


i:Interface

provides

op:Operationdefines

receives

r:Request

sends

sentViacalls

to:Port

con:Connector

from:Port

connects

connects


i:Interface

provides

op:Operationdefines

receiveCall:The port providing an operation can receive new incomingcalls from connected ports by this rule.

1

sendResponse

port1:Port con:Connectorconnects

r:Requestreceives

sentVia

resp:Response

sentViasends respondsTo


r:Requestreceives

sentVia

resp:Response

sentViasends

respondsTo

receiveResponse


r:Requestsends

sentVia

resp:Response

sentViareceives respondsTo


r:Requestsends

sentVia

resp:Response

sentViarespondsToreceives

finishRequestResponse

port1:Port

con:Connector

connects

r:Request

sends

sentVia resp:Response

sentVia

receives

respondsTo

port2:Port

connects

sends receives

op:Operation

calls

port1:Port

con:Connector

connects

port2:Port

connects

op:Operation

sendResponse:If a port has received a request, this rule sends a response.

1

sendResponse


r:Requestreceives

sentVia

resp:Response



r:Requestreceives

sentVia

resp:Response

sentViasends

respondsTo

receiveResponse


r:Requestsends

sentVia

resp:Response



r:Requestsends

sentVia

resp:Response



port1:Port

con:Connector

connects

r:Request

sends


sentVia

receives

respondsTo

port2:Port

connects

sends receives

op:Operation

calls

port1:Port

con:Connector

connects

port2:Port

connects

op:Operation

receiveResponse:The port sending a request can receive a correspondingresponse by this rule.

1

sendResponse


r:Requestreceives

sentVia

resp:Response



r:Requestreceives

sentVia

resp:Response

sentViasends

respondsTo

receiveResponse


r:Requestsends

sentVia

resp:Response



r:Requestsends

sentVia

resp:Response



port1:Port

con:Connector

connects

r:Request

sends


sentVia

receives

respondsTo

port2:Port

connects

sends receives

op:Operation

calls

port1:Port

con:Connector

connects

port2:Port

connects

op:Operation

finishRequestResponse:This rule removes finished request and response messages.

1

finishRequestport1:Port

con:Connector

connects

r:Request sentVia

resp:Response

receives

respondsTo

port2:Port

connects

sends

op:Operation

calls

port1:Port

con:Connector

connects

port2:Port

connects

op:Operation

finishRequest:This rule removes a finished request message which didnot get a response.


After having introduced the transformation rules, wecan apply them to the initial configuration of the Smart-Car system shown in Fig. 5. This way, we can formallymodel the SmartCar scenario from Sect. 2 as a transfor-mation sequence. The beginning of the transformationsequence is partially shown in Fig. 6.

1

isInstanceOf

m:Component

MapRequest:ComponentType

MapProvider:PortType

supports

v:Component



isInstanceOf

supports MapConnector:ConnectorType

allowsallows

p1:Port

used==trueowns

isInstanceOf

p2:Port

used==trueowns

isInstanceOf

con:Connector

connectsconnects

isInstanceOf

openPort

openPort

connect

isInstanceOf

m:Component



supports

v:Component



isInstanceOf


allowsallows

p1:Port

used==falseowns

isInstanceOf

p2:Port

used==falseowns

isInstanceOf

isInstanceOf

m:Component



supports

v:Component



isInstanceOf


allowsallows

p1:Port

used==falseowns

isInstanceOf

isInstanceOf

m:Component



supports

v:Component



isInstanceOf


allowsallows

Fig. 6 Transformation sequence for the SmartCar scenarioin the business style

3.2 A style for service-oriented architectures

While the above presented architectural style can beused for modeling at the platform-independent level, thefollowing subsection presents a style for service-orientedarchitectures as introduced in Sect. 2. It extends theplatform-independent style by SOA-specific concepts likeservice publication and discovery. In Sect. 5, we then ex-plain how business-level architecture models and scenar-ios can be refined to the SOA style.

The SOA style does not model any vendor-specificplatform. It rather represents the general SOA-specificmechanisms for service publication and service discov-ery. Other aspects that go beyond like quality-of-service,security, or mobility can be represented by even morespecific styles which form a refinement hierarchy downto vendor-specific platform models. Our stepwise refine-ment approach can then be extended to this hierarchy.

Type graph: Figures 7 and 8 show the type graph of theSOA style. Due to the increased complexity, the class di-agram is subdivided into two separate packages, Struc-ture and Communication. They contain the same types

as the platform-independent type graph from Fig. 4 butspecialize some of them by subtyping and add furthertypes for SOA.

1

ComponentType

PortTypeInterfaceprovidesrequires

ConnectorType Connector

Component

DiscoveryService

Service

connects

2allows

1

1

1

1

ownssupports

isInstanceOf

isInstanceOf

isInstanceOf

Operation

ServiceType

Type graph (part I: Package Structure):

Discovery-ServiceTypedefines

1

FindPTPublishPT

RequesterPT

ProviderPT2

Portused:Boolean

Fig. 7 Type graph of SOA style (package Structure)

1

Port(from Structure)

Service-Description

Connector(from Structure)

connects2

Message

Service-Query

Service-Publication

0..1

0..1

sentVia0..1

11

requires-ServiceForpublishes

respondsTo1

sendsreceives

Query-Result

contains

Type graph (part II: Package Messages):

Request Response

Operation(from Structure)

0..1

calls

PortType(from Structure)

1Service

(from Structure)

Component(from Structure)

knows

describes

0..1

1

satisfies

resultOf1 0..1

Fig. 8 Type graph of SOA style (package Communication)

The first package Structure (Fig. 7) contains sub-types of Component which can be used to declare soft-ware components as Service or, if functioning as discov-ery agency, as DiscoveryService. ComponentType is spe-cialized accordingly. Also, there are special subtypes ofPortType which are used to define dedicated port typesfor interactions with discovery services.

The second package Communication (Fig. 8) extendsthe elements for message-based communication knownfrom the business style. The central SOA element hereis ServiceDescription which describes a specific Service (inSOA, descriptions refer to deployed, addressable servicesrather than to service types only). The knows relation-ship indicates which components have access to a de-scription. The existence of such a knows relationship is


a precondition for connecting to a service as shown bythe transformation rule connect in Table 2.

Besides the already known Request and Responsemessages, there are three special SOA message types forinteractions with discovery services, namely ServicePubli-cation, ServiceQuery, and QueryResult. The first one sub-mits a service description to a discovery service for pub-lication, the second one refers to a port type which theservice requester requires a suitable service for, and thethird one is returned by the discovery service containinga description that satisfies the query.

Constraints: Along with the extended type graphcomes an extended set of constraints which we do notpresent in detail here. For instance, they ensure thata DiscoveryServiceType always supports port types ofkind PublishPT and FindPT. Also, they restrict possi-ble sender and receiver ports for SOA-specific messages;e.g., a ServicePublication message can only be sent fromProviderPT ports to PublishPT ports.

We can now model the initial configuration of theSmartCar system in the SOA style. We take the business-level instance graph from Fig. 5 and change all compo-nents except for Vehicle into the new SOA types Serviceand ServiceType. We attach a ServiceDescription to allservices. Furthermore, we add a DiscoveryService whichis used to dynamically discover services. Additional porttypes are inserted to enable communication with the Dis-coveryService. The result is shown in Fig. 9.

1

isInstanceOfm:Service MapRequest

:ServiceTypeMapProvider

:PortTypesupports

t:Service

v:Component

i:Service


ItineraryDefinition:ServiceType

TrafficInformation:ServiceType


ItineraryRequester:PortType

ItineraryProvider:PortType

InfoRequester:PortType

InfoProvider:PortType

isInstanceOf

isInstanceOf

supports

isInstanceOf

supports


TrafficInfo-Connector

:ConnectorType

Itinerary-Connector

:ConnectorType

allows

allows

allows

allows

allows

allows

d:Discovery-Service

Discovery-Engine

:Discovery-ServiceType

QueryPort:FindPT

isInstanceOfsupports PublicationPort

:PublishPT

supports

mapDesc:ServiceDescriptiondescribes

itineraryDesc:ServiceDescription

describes

trafficDesc:ServiceDescriptiondescribes

discoveryDesc:ServiceDescription

describes

knows

knows

knows

knows

ServiceRequester:RequesterPT

ServiceProvider:ProviderPT

QueryConnector:ConnectorType

allowsallows

Publication-Connector

:ConnectorType

allows

supports

supports

allows

supports

supports

Fig. 9 SOA-specific instance graph for the SmartCar system

Since SOA-specific instance graphs become largerand more complex than the platform-independent ones,

their readability decreases. In Sect. 4, we explain howto define a mapping between the type graph and a cus-tomized version of the UML meta-model in order to al-low for a better concrete notation.

Transformation rules: Similarly to the type graph, theSOA style also inherits the transformation rules definedfor the business style in Table 1. The only rule that ismodified is the rule connect. Its SOA-specific variant,shown at the beginning of Table 2, has a stronger pre-condition demanding that a Component knows the Ser-viceDescription of a requested Service before a Connectorto the service can be created.

In order to establish the required knows relationship,a number of other SOA-specific rules have to be appliedfirst, which model the mechanisms for service publicationand query. These additional rules are found in Table 2after the connect rule.

There are three rules dealing with service publica-tions and six rules dealing with service queries. Aftera query has been submitted (sendServiceQuery) and re-ceived by the discovery service (receiveServiceQuery), the

Table 2 Transformation rules of the SOA style

1

connect

c:Component

owns


supports

ct:ComponentType

isInstanceOf

s:Service

owns


supports

st:ServiceTypeisInstanceOf

conT:ConnectorType

allows

allows



sd:ServiceDescription

knows

describes

con:Connector

connects

connects

isInstanceOf

c:Component

owns


supports

ct:ComponentType

isInstanceOf

s:Service

owns


supports

st:ServiceTypeisInstanceOf

conT:ConnectorType

allows

allows



sd:ServiceDescription

knows

describes

connect:With this rule, a component is connected to a service onlyif the service description is known.

1

s:Service

sendServicePublication

port1:Port

con:Connector

owns

connects

pt1:ProviderPTisInstanceOf

sd:Service-Description

describes

sp:Service-Publication

sends

sentVia

publishes

port2:Port pt2:PublishPTisInstanceOf

connects

s:Service

port1:Port

con:Connector

owns

connects



describes


connects

sendServicePublication:A service submits its description to a discovery service.


1

receiveServicePublication

receives


sends

sentVia

port1:Port

con:Connector

owns

connects


d:Discovery-Service


connectsreceives


sends

sentVia

port1:Port

con:Connector

owns

connects


d:Discovery-Service


connects

receiveServicePublication:A discovery service receives a new request for publication.

1

publishServiceDescription


publishes

knows

receives


sends

sentVia

port1:Port

con:Connector

owns

connects

di:Discovery-Service

port2:Port

connects

sd:Service-Descriptionport1:Port

con:Connector

owns

connects

di:Discovery-Service

port2:Port

connects

publishServiceDescription:The discovery service stores the description of the serviceto be published.

1

sendServiceQuery

sq:Service-Query

sentVia

sends

requires-Service-For

supports

pt:PortType

supports

c:Component

port1:Port

con:Connector

owns

connects

pt1:Re-questerPT

isInstanceOf

comp:ComponentType

port2:Port pt2:FindPTisInstanceOf

connects

isInstanceOf

supports

pt:PortType

supports

c:Component

port1:Port

con:Connector

owns

connects

pt1:Re-questerPT

isInstanceOf

comp:ComponentType

port2:Port pt2:FindPTisInstanceOf

connects

isInstanceOf

sendServiceQuery:A component sends a service query to a discovery service.

1

receiveServiceQuery

sq:Service-Query

sentVia

receives

d:Discovery-Service

port1:Port

con:Connector

owns

connects

pt:FindPTisInstanceOf

port2:Port

connectssends

sq:Service-Query

sentVia

receives

d:Discovery-Service

port1:Port

con:Connector

owns

connects

pt:FindPTisInstanceOf

port2:Port

connectssends

receiveServiceQuery:A discovery service receives a service query.

1

findService

pt1:PortType

requires-ServiceFor


knows

s:Service

isInstanceOf

describes

st:Service-Type

pt2:PortType

supports

conT:ConnectorType

allows allows

satisfies

sq:Service-Query

receives

d:Discovery-Service

port1:Port

owns

pt1:PortType

requires-ServiceFor


knows

s:Service

isInstanceOf

describes

st:Service-Type

pt2:PortType

supports

conT:ConnectorType

allows allows

satisfies

sq:Service-Query

receives

d:Discovery-Service

port1:Port

owns

findService:The discovery service selects an appropriate service de-scription which satisfies the service query. This is the caseif there is a compatible connector type for the port typesof requester and provider.

1

sendQueryResult

qr:Query-Result

sentViasends

contains

resultOf


knows

satisfies

sq:Service-Query

sentViareceives

d:Discovery-Service

p:Port con:Connectôr

owns

connects


knows

satisfies

sq:Service-Query

sentVia

receives

d:Discovery-Service

p:Port con:Connector

owns

connects

sendQueryResult:The discovery service sends a response with a satisfyingservice description.

1

receiveQueryResult

p:Port con:Connectorconnects

sq:Service-Query

sentViasends

qr:Query-Result

sentViareceives

resultOf


sq:Service-Query

sentViasends

qr:Query-Result

sentViareceives

resultOf

receiveQueryResult:The service requester receives the result of a query.

1

saveQueryResult

c:Component

owns


contains

knows


sq:Service-Query

sentViasends

qr:Query-Result

sentViareceives

resultOf

satisfiesc:Component

owns



saveQueryResult:The service requester finishes the query communicationand stores the description of the found service.


rule findService is applied to decide which service descrip-tion satisfies the query. A necessary condition is thatthere exists a ConnectorType which allows the connec-tion of the requester port type and the port type ofthe service. If there are several candidates, the rule isapplied non-deterministically since we abstract from de-tailed specification matchings in this style.

4 UML Notation for SOA-specific models

Graph transformation is a powerful formalism but, at thesame time, rather difficult to use in practice because in-stance graphs easily grow very large. Also, the proposednotation for instance graphs does not provide a symbolicdistinction between different element types which makesit difficult to read the diagram.

To address these problems, we propose to use thegraph representations as underlying formalism, whichcan internally be handled by tools, and to place a user-friendly notation layer like the Unified Modeling Lan-guage (UML) on top. UML is a well-known modelinglanguage and the de-facto standard for object-orientedmodeling in industry.

Another advantage of UML is its built-in extensionmechanism [34]. In our case, this mechanism can be usedto provide a distinguished notation for style-specific ele-ments that are not represented by the UML core. For thispurpose, one defines a UML profile that consists of so-called stereotypes. Each stereotype extends and adaptsclasses of the UML meta-model by defining refined se-mantics, additional attributes, constraints, and, option-ally, a new distinguished notation.

While the standard UML might be sufficient to modelplatform-independent architectures (cf. [29]), we proposeto define dedicated UML profiles for platform-specificmodels. Following the tradition of [39,29], we choose anexisting meta-class from the UML meta-model that is se-mantically close to a construct from the platform-specificarchitectural style and define a stereotype that can beapplied to instances of that meta-class to constrain itssemantics to that of the architectural style.

The correspondence between the resulting UMLmodels and their equivalent graph-based representationcan be maintained by special conversion tools as de-scribed in Sect. 6. Based on a mapping between the (ex-tended) UML meta-model and the type graph of the cor-responding architectural style, such tools can translatebetween the UML models exported from a CASE-tooland the corresponding graph-based representation.

Below, we apply the concept to our service-orientedstyle. At first, we define a UML profile for SOA as a set ofstereotypes that extend selected classes of the UML 2.0meta-model. Then, we provide a notation guide for thesenew stereotypes. Eventually, we define the mapping be-tween the SOA type graph and the extended UML meta-model as conceptual basis for conversions between thetwo representations.

Stereotypes: Figure 10 defines the SOA-specific stereo-types for the UML 2.0 meta-model. The extended UMLmeta-classes are shown at the top of the diagram, thecorresponding stereotypes below the dashed line. Theextension relationship is indicated by arrows with small,filled arrow-head. Stereotypes can be specialized by sub-types.

1

«profile» SOA

«metaclass»Class

«stereotype»PortType

«metaclass»Association

«stereotype»Connector

«metaclass»Component

«metaclass»Instance-

Specification

«stereotype»Service

«stereotype»Discovery-

Service

«metaclass»Port

«stereotype»PublishPort

«stereotype»FindPort

«metaclass»Dependency

«stereotype»Knows-

Dependency

«stereotype»Describes-

Dependency

«stereotype»PublishPT

«stereotype»FindPT

«stereotype»RequesterPT

«stereotype»ProviderPT

«metaclass»Artifact

«stereotype»Service-

Description

Fig. 10 Stereotypes of the UML profile for SOA

Port types and connector types can be modeled withclass diagrams. Thus, we introduce the stereotype Port-Type and its sub-stereotypes as extensions of the UMLmeta-class Class. Associations between these port typeclasses model connector types and are marked by thestereotype Connector. In the same class diagram, one canalso specify the interfaces that a port type provides andrequires (cf. Fig. 11).

With the help of the two stereotypes Service and Dis-coveryService, we can label components that are to beexposed as services. Since services occur as both typesand instances thereof, these stereotypes can be attachedto the meta-classes Component as well as InstanceSpecifi-cation. These constructs are used in component diagrams(cf. Fig. 12), where we can also specify which port typesfrom the aforementioned class diagram are supported bya component or service type, and in communication orsequence diagrams modeling interactions between vari-ous (instances of) components and services.

UML 2.0 knows the notion of Port as an interactionpoint to a component instance. Thus, we do not need aseparate stereotype for ports in general. But, in order tohighlight those ports that are used for service publicationand query, we introduce the stereotypes PublishPort andFindPort.

The stereotype for service descriptions is based on themeta-class Artifact. The relationships to these descrip-tions are modeled by the stereotypes KnowsDependencyand DescribesDependency.


Table 3 Notation guide for SOA stereotypes

1

«publishPT»PublishPT

«findPT»FindPT

«portType»PortType

«providerPT»ProviderPT

DescribesDependency

KnowsDependency

FindPort

PublishPort

ServiceDescription

DiscoveryService

Service

«connector» NameConnector

«requesterPT»RequesterPT

Notation:Stereotype from SOA profile:

Name D

F

P

«describe»

«know»

ServiceName«service»

Name«discovery»

Notation: The default convention for the notation ofstereotyped diagram elements is to attach the stereo-type name within a pair of guillemets to the symbol ofits meta-class. Nevertheless, one can also define morecustomized notations. The notation of the SOA stereo-types is summarized in Table 3.

Relating style and UML meta-model: The relationshipbetween the UML notation and the formal architecturalstyle is defined by a bi-directional mapping between thetype graph of the style and the extended UML meta-model. With the help of such mapping, we can rendera given instance graph as UML diagrams, and, in theopposite direction, we can provide the semantics for agiven UML model in terms of the architectural style.

Table 4 shows the mapping for the SOA style andthe UML profile for SOA. The left column contains thenodes (and some of the edges) of the SOA type graph(cf. Fig. 7 and 8). The right column contains the cor-responding meta-classes and stereotypes that should beused in UML diagrams to depict the various concepts ofthe SOA style.

Edges in the type graph represent relationships be-tween nodes. If there are similar relationships in theUML meta-model (e.g., for the operations defined by aninterface), then we can omit the mapping of edges. Twoexceptions are the knows and describes edges becausetheir counterparts on the UML side are real meta-classesand stereotypes.

Table 4 Mapping between SOA style and UML

SOA type graph UML meta-model and profile elements

elements (package name::class name)

ComponentType BasicComponents::Component

Component Kernel::InstanceSpecification

ServiceType BasicComponents::Component

stereotyped by SOA::Service

Service Kernel::InstanceSpecification

stereotyped by SOA::Service

DiscoveryService- BasicComponents::Component

Type stereotyped by SOA::DiscoveryService

DiscoveryService Kernel::InstanceSpecification

stereotyped by SOA::DiscoveryService

PortType Kernel::Class

stereotyped by SOA::PortType

ProviderPT Kernel::Class

stereotyped by SOA::ProviderPT

PublishPT Kernel::Class

stereotyped by SOA::PublishPT

FindPT Kernel::Class

stereotyped by SOA::FindPT

RequesterPT Kernel::Class

stereotyped by SOA::RequesterPT

Port [If self.portType.oclIsTypeOf(PortType)]

Ports::Port

[If self.portType.oclIsTypeOf(PublishPT)

or self.portType.oclIsTypeOf(ProviderPT)]

Ports::Port

stereotyped by SOA::PublishPT

[If self.portType.oclIsTypeOf(FindPT) or

self.portType.oclIsTypeOf(RequesterPT)]

Ports::Port

stereotyped by SOA::FindPT

ConnectorType Kernel::Assocication

stereotyped by SOA::Connector

Connector Kernel::InstanceSpecification

Interface Interfaces::Interface

Operation Kernel::Operation

ServiceDescription Artifacts::Artifact

stereotyped by SOA::ServiceDescription

knows Dependencies::Dependency

stereotyped by SOA::KnowsDependency

describes Dependencies::Dependency

stereotyped by

SOA::DescribesDependency


If there are several notation options for the same typegraph element, then we can distinguish these options byadditional OCL constraints as shown in Table 4 for Port.

Since, we restrict the UML profile to visualizing thestructure of a system only, we omit a mapping of thevarious message types for communication.

Example diagrams: Figures 11 and 12 give an impres-sion, how the model layout is improved when the SOAprofile is applied. They visualize the SOA instance graphof the SmartCar system shown in Fig. 9.

Figure 11 presents a class diagram which defines allport types together with their provided (triangle arrow-head) and required (use dependency) interfaces. Thecomponent diagram in Fig. 12 reveals which service orcomponent supports which port type and which servicedescriptions are known by which components at the be-ginning.

1

«interface»MapSelection

inquireMap(..) selectMap(..)

«portType»MapProvider

«portType»MapRequester

«use»

«connector»MapConnector

«interface»ItinerarySelectionaskForItineraries(..) selectItinerary(..)

«portType»ItineraryProvider

«portType»ItineraryRequester

«use»

«connector»ItineraryConnector

«interface»TrafficInfo

getTrafficInfo(..)

«portType»InfoProvider

«portType»InfoRequester

«use»

«connector»TrafficInfoConnector

«interface»ServicePublication

publish(..)

«publishPT»PublicationPort

«providerPT»ServiceProvider

«use»

«connector»PublicationConnector

«interface»Payment

findService(..)

«findPT»QueryPort

«requesterPT»ServiceRequester

«use»

«connector»QueryConnector

Fig. 11 SOA-specific class diagram for SmartCar

1

v:Vehiclem:MapRequest

:MapProvider

:ItineraryRequester

:MapRequester

i:ItineraryDefinition t:TrafficInformation

:Itinerary-Provider

:InfoRequester :InfoProvider

«service» «service»

«service»

d:DiscoveryEngine

:QueryPortF«discovery»

:PublicationPortP

P:ServiceProvider

F

:Service-Requester

P

:Service-Provider

F:Service-Requester P

:ServiceProvider

map-Desc

D

traffic-Desc

D

itinerary-Desc

D

discovery-Desc

D«describe»

«describe»

«describe»

«describe»

«know»

«know»

«know»

«know»

Fig. 12 SOA-specific component diagram for SmartCar

5 Behavior-preserving architecture refinement

Based on the architectural styles defined in Sect. 3 andthe UML profile defined in Sect. 4, we can now modelsystem architectures at the business-level as well as forservice-oriented platforms, and we can provide an opera-tional semantics for communication and reconfigurationscenarios in terms of graph transformations. The under-lying conceptual platform model, in our case the archi-tectural style for SOA, ensures that the architecture isconsistent with the provided platform mechanisms.

The remaining problem we want to address in thissection is how to ensure the consistency between archi-tecture models in the abstract, business-oriented and theplatform-specific, service-oriented style. Since these twostyles represent different levels of platform abstraction,the desired consistency relationship can be defined by anappropriate notion of architecture refinement.

To be a valid refinement of a business-level architec-ture, a platform-specific or, in our case, service-orientedarchitecture has to realize the same functionality. Thisrequirement can be subdivided into1. Structural refinement: The platform-specific ar-

chitecture has to preserve all business-relevant, func-tional entities and all required connections betweenthese entities.

2. Behavior-preserving refinement: The platform-specific architecture has to enable all communicationand reconfiguration scenarios which can also occur atthe business level.Our notion of refinement should be style-based, i. e.,

based on a relationship between the abstract, platform-independent style and the SOA-specific style which canbe reused for refining any instances of these styles. Forthis purpose, a mapping between the two type graphsis used to induce an abstraction function that projectsinstance graphs from the concrete style to the abstractstyle. The rationale behind using an abstraction func-tion rather than a refinement function is the fact thatabstraction is in general simpler and more deterministicthan refinement.

Based on the abstraction function, we can check ifa given instance graph in the SOA style is a refinementof a given business-level instance graph. A similar cri-terion applies to transformation sequences representingreconfiguration and communication scenarios.

In order to derive refined, SOA-specific scenariosfrom given business-level scenarios including operationsfor service publication and discovery, we reformulatethis problem as a reachability problem which can auto-matically be solved by graph transformation or model-checking tools as described in Sect. 6.

5.1 Refinement criterion for instance graphs

As mentioned above, we use an abstraction functionas refinement criterion which is induced by a map-


ping at the style level. For the case of service-orientedarchitectures, let the platform-independent (pi) stylefrom Sect. 3.1 be Gpi = 〈TGpi, Cpi, Rpi〉 and theservice-oriented (so) style from Sect. 3.2 be Gso =〈TGso, Cso, Rso〉. Then, we introduce a type mappingt : TGso → TGpi, formally a partial surjective graphhomomorphism, which maps elements of the SOA typegraph TGso to the elements of the platform-independenttype graph TGpi.

The concrete definition of t is driven by semanticcorrespondences between the elements of the two styles.We distinguish three different cases which are illustratedin Fig. 13:

1. Since the SOA-specific type graph is an extension ofthe platform-independent type graph, all nodes andedges of the latter also occur in the former. In thesecases, the SOA elements are mapped to their equiv-alent in the platform-independent type graph. Thisway, the abstraction mapping t becomes surjective.For instance, as shown in Fig. 13, t maps the SOAtype Component to the platform-independent typeComponent, and similarly with ComponentType.

2. Since services are a SOA-specific interpretation ofcomponents, t maps Service and ServiceType to theplatform-independent types Component and Compo-nentType, too.

3. All other types (and adjacent edges) like Discov-eryService, ServiceDescription, or the SOA-specificport types and messages represent purely platform-specific concepts which do not occur at the businesslevel. Therefore, these elements are not mapped tothe platform-independent type graph.

1

ComponentType Component

DiscoveryService

Service

1 isInstanceOf

ServiceType

Abstraction mapping:

DiscoveryServiceType

ComponentType ComponentisInstanceOfTGpi

TGso

t

t t

t

t

1

Fig. 13 Part of the type graph mapping t

The type mapping t induces the desired abstractionfunction abst : GraphTGso → GraphTGpi which ab-stracts instance graphs typed over TGso to those typedover TGpi. This abstraction informally consists of (1)renaming the types of all elements whose type has animage in TGpi according to the definition of t, (2) delet-ing all nodes and edges which, due to the partiality of t,have a type in TGso but not in TGpi, and (3) deleting alldangling edges and those adjacent nodes whose numberof connected neighbor nodes falls below the lower boundof the relevant cardinality constraint.

Figure 14 illustrates the effect of the abstractionfunction abst for an instance graph fragment which de-fines the MapRequest service in the SOA style. First, weapply the type mapping t and rename the types of theService and ServiceInstance nodes into Component andComponentInstance (1). Then, we delete the ProviderPTand ServiceDescription nodes and the describes edge be-cause they have no mapping to TGpi under t (2). Thedeletion of the ProviderPT node leads to the deletion ofthe adjacent Port node in the third step, because other-wise the cardinality constraint would be violated whichsays that every Port requires a PortType. Eventually, alldangling edges are removed (3).

1

abstraction of instance graphs

(1)

(3)

(2)

abstractionabst

isInstanceOfm:Service MapRequest

:ServiceType

p1:PortmapDesc:Service-

Description owns

describes


supports

isInstanceOf

p2:Port

owns


supports

isInstanceOf


:ComponentType

p1:PortmapDesc:Service-

Description owns

describes


supports

isInstanceOf

p2:Port

owns


supports

isInstanceOf


:ComponentType

p1:Portowns


supports

isInstanceOf

p2:Port

owns supports

isInstanceOf


:ComponentType

p1:Portowns


supports

isInstanceOf

Fig. 14 Abstraction of an instance graph

Since we defined the cardinalities and constraints Cso

in Gso stronger or as strong as the constraints Cpi in Gpi,the abstraction of instance graphs is compatible with theconstraints, that is, if Gso satisfies Cso, then abst(Gso)satisfies Cpi, too.

A service-oriented instance graph Gso is called a re-finement of a platform-independent graph Gpi, if its ab-straction into the platform-independent style reflects ex-actly the elements of Gpi, i.e., if abst(Gso) = Gpi. Thisdefinition ensures that the SOA-specific refinement pre-serves all functional, business-relevant entities occurringin the abstract, business-oriented architecture.

As an example, consider the graph in the upper leftof Fig. 14 which is obviously a refinement of graph (3)in the lower right of the figure. Another example isthe SOA-specific configuration for SmartCar, shown inFig. 9, which refines the platform-independent configu-ration shown in Fig. 5 because the application of theabstraction function to the former yields the latter.

The above defined refinement criterion helps to checkfor refinements of individual system configurations asinstance graphs. In order to actually construct the re-fined configurations, we refer to existing work on struc-tural refinements such as [1,31]. Since our focus is onthe refinement of scenarios, we assume that the archi-tect uses heuristics or one of the available techniques


in order to derive correct SOA-specific configurations(with, e.g., discovery service and service descriptions)from platform-independent ones according to the aboverefinement criterion. Nevertheless, plain structural re-finement is not sufficient to refine the behavioral aspectsof a scenario as described below.

5.2 Refinement criterion for transformations

According to Sect. 3, a reconfiguration and communica-tion scenario is represented as a transformation sequencein the architectural style. For this reason, we extendthe correctness criterion for the refinement of instancegraphs to the refinement of transformation steps and fur-ther on to the refinement of transformation sequences.

For a transformation step spi = (Gpi ⇒ Hpi) in theplatform-independent graph transformation system Gpi,the transformation sequence sso = (Gso ⇒∗

Gso Hso) inthe service-oriented transformation system Gso is a cor-rect refinement, if Gso refines Gpi and Hso refines Hpi

(formally, abst(Gso) = Gpi ∧ abst(Hso) = Hpi).The refinement sso is a transformation sequence

rather than a single step because, at the platform-specificlevel, it might be necessary to perform a number of con-secutive steps to realize the platform-independent step.

1

Gso Hsosend-Service-Query

receive-Service-Query

find-Service

connect

connect

abst abst

spi =

sso =

Gpi Hpi

send-Query-Result

receive-Query-Result

save-Query-Result

Fig. 15 Refinement of a transformation step

As an example, consider the transformation step spi

of Fig. 15 which contains the application of the platform-independent rule connect (cf. Table 1). For the service-oriented refinement of this step, we have to use the SOAvariant of the connect rule (cf. Table 2) which requiresas precondition that the service description is known tothe service requester. Therefore, it becomes necessary tosubmit a service query to a discovery service before theconnect operation can be applied. Thus, we add corre-sponding rule application to the service-oriented refine-ment sso shown at the bottom of Fig. 15.

The criterion for transformation steps is easily ex-tended to sequences spi = (Gpi

0 ⇒∗Gpi Gpi

n ) of lengthgreater than one: A sequence sso = (Gso

0 ⇒∗Gso Gso

n )over the SOA style is a valid refinement of spi, if sso canbe partitioned into consecutive subsequences that are re-finements of the individual transformation steps of spi.

5.3 Construction of refined transformation sequences

To actually construct the refined transformation se-quence, we stick to the stepwise view and decompose

the abstract sequence spi into its individual steps spik =

(Gpik ⇒ Gpi

k+1). Each step is then transformed into areachability problem which can be solved by analysistools.

Consider the first step spi0 = (Gpi

0 ⇒ Gpi1 ). We assume

that there is a correctly refined start graph Gso0 in the

SOA style with abst(Gso0 ) = Gpi

0 . Then, the first reach-ability problem is to find the shortest transformationsequence of SOA-specific rule applications which leadsfrom Gso

0 to an instance graph Gso1 that refines the tar-

get graph Gpi1 .

The length of the SOA-specific transformation se-quence is required to be minimal, because we want toreach the target configuration without any superfluoussteps that could have additional effects on business-relevant elements like, for instance, creating any extraconnector that is not required by the target graph Gpi

1 .If the search within the service-oriented transforma-

tion system is successful, the reached instance graph canbe taken as new start graph for the second step spi

1 , andso on. If we repeat the procedure for all steps of the trans-formation sequence and concatenate the resulting SOA-specific transformation sequences, we receive a completerefinement of the platform-independent scenario spi.

If the search fails and at least one of the steps tobe refined cannot be expressed as a transformation se-quence at the SOA level, then this might be caused bysome missing elements in the initial configuration of theservice-oriented architecture. For example, if one of thecomponents that needs to use a service does not knowthe description of the responsible discovery service and,thus, cannot connect to it for submitting a service query,then this component cannot connect to the required ser-vice, either. This way, the solution of the reachabilityproblems can also be used to validate the correctnessand completeness of the initial SOA configuration.

Example: We illustrate the refinement of scenarios forthe SmartCar scenario which is partially depicted inFig. 6 as a transformation sequence in the platform-independent style. The depicted part represents the cre-ation of a new connector between the Vehicle componentand the MapRequest component and consists of four in-stance graphs, which we now name Gpi

0 , Gpi1 , Gpi

2 , andGpi

3 , and the three transformation steps

Gpi0

openPort=⇒ Gpi

1

openPort=⇒ Gpi

2connect=⇒ Gpi

3

The refinement of this transformation sequence is de-picted in Fig. 16. The individual steps of the refinedtransformation sequence are labeled by the applied SOA-specific rules. We do not highlight to which part of thegraph a rule has been applied since this can be derivedfrom the outcome of a rule application, and, for the sakeof brevity, we have summarized some consecutive trans-formations into single steps. For the definition of theindividual rules please refer to Table 2.


Fig. 16 Refined, SOA-specific transformation sequence forthe SmartCar scenario

1

isInstanceOf

m:Service

MapRequest:ServiceType

Map-Provider:PortType su

ppor

ts

v:Component


Map-Requester:PortType

isInstanceOf

supports


allowsallow

s

openPort (4x)

d:DiscoveryService

DiscoveryEngine:DiscoveryServiceType

isInstanceOf

QueryPort:FindPT

discoveryDesc:ServiceDescpription

describes

Service-Requester

:RequesterPT supp

orts

mapDesc:Service-

Descpription

describes

supports

knows

knows


allows

allows

1

isInstanceOf

m:Service



ppor

ts

v:Component



isInstanceOf

supports


allowsallow

s

connect

d:DiscoveryService


isInstanceOf

QueryPort:FindPT


describes

Service-Requester

:RequesterPT supp

orts

mapDesc:Service-

Descpription

describes

supports

knows

p1:Port

used==falseowns

isInstanceOf

p2:Port

used==falseowns

isInstanceOf

knows


allows

allows

p4:Port

used==false

owns

isInstanceOf

p3:Port

used==false

owns

isInstanceOf

1

isInstanceOf

m:Service



ppor

ts

v:Component





allowsallow

s

sendServiceQuery +

d:DiscoveryService


isInstanceOf

QueryPort:FindPT


describes

Service-Requester

:RequesterPT supp

orts

mapDesc:Service-

Descpription

describes

supports

knows

p1:Port

used==falseowns

isInstanceOf

p2:Port

used==falseowns

isInstanceOf

knows


allows

allows

p4:Port

used==true

owns

isInstanceOf

p3:Port

used==true

owns

isInstanceOf

c1:Connector

connects

connectsisIns

tance

Of

receiveServiceQuery

1

isInstanceOf

m:Service



ppor

ts

v:Component



isInstanceOf

supports


allowsallow

s

findService

d:DiscoveryService


isInstanceOf

QueryPort:FindPT


describes

Service-Requester

:RequesterPT supp

orts

mapDesc:Service-

Descpription

describes

supports

knows

p1:Port

used==falseowns

isInstanceOf

p2:Port

used==falseowns

isInstanceOf

knows


allows

allows

p4:Port

used==true

owns

isInstanceOf

p3:Port

used==true

owns

isInstanceOf

c1:Connector

connects

sq:Service-Query

sends

sentVia

requires-ServiceFor

receivesconnectsisI

nstan

ceOf

1

isInstanceOf

m:Service



ppor

ts

v:Component



isInstanceOf

supports


allowsallow

s

sendQueryResult +receiveQueryResult

d:DiscoveryService


isInstanceOf

QueryPort:FindPT


describes

Service-Requester

:RequesterPT supp

orts

mapDesc:Service-

Descpription

describes

supports

knows

p1:Port

used==falseowns

isInstanceOf

p2:Port

used==falseowns

isInstanceOf

knows


allows

allows

p4:Port

used==true

owns

isInstanceOf

p3:Port

used==true

owns

isInstanceOf

c1:Connector

connects

sq:Service-Query

sends

sentVia

requires-ServiceFor

receives

satisfies

connectsisIns

tance

Of

1

isInstanceOf

m:Service



ppor

ts

v:Component



isInstanceOf

supports


allowsallow

s

saveQueryResult

d:DiscoveryService


isInstanceOf

QueryPort:FindPT


describes

Service-Requester

:RequesterPT supp

orts

mapDesc:Service-

Descpription

describes

supports

knows

p1:Port

used==falseowns

isInstanceOf

p2:Port

used==falseowns

isInstanceOf

knows


allows

allows

p4:Port

used==true

owns

isInstanceOf

p3:Port

used==true

owns

isInstanceOf

c1:Connector

connects

sq:Service-Query

sends

sentVia

requires-ServiceFor

receives

satisfies

rq:Query-Result

sends

resu

ltOf

contains

receives

sentViaconnectsisI

nstan

ceOf

1

isInstanceOf

m:Service



ppor

ts

v:Component



isInstanceOf

supports


allowsallow

s

connect

d:DiscoveryService


isInstanceOf

QueryPort:FindPT


describes

Service-Requester

:RequesterPT supp

orts

mapDesc:Service-

Descpription

describes

supports

knows

p1:Port

used==falseowns

isInstanceOf

p2:Port

used==falseowns

isInstanceOf

knows


allows

allows

p4:Port

used==true

owns

isInstanceOf

p3:Port

used==true

owns

isInstanceOf

c1:Connector

connects

connectsisIns

tance

Of

knows

1

m:Service



ppor

ts

v:Component



isInstanceOf

supports


allowsallow

s

d:DiscoveryService


isInstanceOf

QueryPort:FindPT


describes

Service-Requester

:RequesterPT supp

orts

mapDesc:Service-

Descpription

describes

supports

knows

p1:Port

used==trueowns

isInstanceOf

p2:Port

used==trueowns

knows


allows

allows

p4:Port

used==true

owns

isInstanceOf

p3:Port

used==true

owns

isInstanceOf

c1:Connector

connects

connectsisIns

tance

Of

knows

c2:Connector

connectsconn

ects

isInstanceOf isInstanceOfisInstanceOf


The start graph of the refined sequence in Fig. 16equals the SOA instance graph from Fig. 9 which is avalid refinement of the platform-independent start graphGpi

0 from Fig. 6. It contains all relevant parts for the Ve-hicle component, the MapRequest service and the Discov-eryEngine discovery service. In order to shorten the ex-ample, we assume that the service description mapDescof the MapRequest service has already been published tothe discovery service (as indicated by the knows edge).

The refinement of the transformation sequence startswith the first two transformation steps representing twoinvocations of the openPort operation. Their refinementinto a SOA-specific scenario is quite trivial as we cansimply apply the equivalent openPort operations of theSOA style.

More difficult is the refinement of the business-levelconnect operation. In this case, we cannot simply applythe corresponding SOA variant to the last intermediateresult because the SOA variant of the connect rule re-quires a knows link to the service description mapDescwhich is not yet existent. For this reason, we have to trythe application of other rules in order to find a transfor-mation sequence to a valid refinement of Gpi

3 .The minimal solution to this reachability problem

can be found in Fig. 16 after the first two openPortoperations. In summary, it comprises two further open-Port operations that “prepare” a connect operation tothe discovery service, sending and receiving a query tothe discovery service, finding an appropriate service, andsubmitting the query response with the required servicedescription. Eventually, the desired connect operation isapplicable after the knows links has been created by save-QueryResult (cf. also Fig. 15).

If we continue the refinement procedure until theentire business-level scenario of the SmartCar appli-cation is refined to the SOA-specific level, we receivea platform-specific reconfiguration and communicationscenario which can then be rendered as a UML diagramagain. Figure 17, for instance, shows the interactions ofthe refined scenario as a UML sequence diagram.

We do not have to perform the described reachabilitysearches manually. As discussed in the next section, ex-isting analysis and graph transformation tools can auto-matically select applicable transformation rules and testthe effect of their application in order to automate thepresented refinement approach.

6 Tool support

While conceiving the approach presented so far, we didnot concentrate on designing a brand-new tool, but de-cided to exploit existing tools as components of a toolchain. Even if this paper concentrates on describing theconcepts of the approach, we briefly discuss the tool sup-port required and how we can reuse existing tools.

Roughly, we can split the task into the creation ofUML models and graph transformation systems and the

1

v :Vehicle

inquireMap()maps

selectMap()

getTrafficInfo()info

itineraries

«service»m :Map-Request

«service»i :Itinerary-Definition

«service»t :Traffic-

Information

askForItineraries()

sd plan trip «SOA»«discovery»d :Discovery-

Engine

sendServicePublication()

sendServicePublication()

sendServicePublication()sendServiceQuery()

query result

sendServiceQuery()query result

sendServiceQuery()query result

Fig. 17 UML sequence diagram of SOA-specific scenario

support for model refinement. The latter, involving thereachability analysis for a target configuration from agiven initial configuration, is critical for the proposedrefinement technique. This analysis can be performedusing both model checking techniques and simulationfeatures of graph transformation tools. In both cases,the solution to the reachability problem has to be in-tegrated with the tools to create graph transformationsystems and UML models.

6.1 Modeling tools

The creation of UML models is a standard task and doesnot require special attention. Here, we can use off-the-shelf UML CASE tools, like Poseidon3, to define modelsand add suitable annotations (stereotypes) to decoratethem with additional information. All UML tools sup-port the XML Metadata Interchange (XMI) format [35]as a standard and vendor-independent way to store andexchange user models.

The creation of graph transformation systems is sup-ported by tools, like AGG4, PROGRES [41], and Fu-jaba5, which allow the specification of rules in variousnotations as well as their application to a given graph.As a common XML format for graph transformationsystems, the Graph Transformation eXchange Language(GTXL)6 is being developed. It is based on the GrapheXchange Language (GXL)7 [47] and will shortly be sup-ported by several graph transformation tools.

3 www.gentleware.com4 tfs.cs.tu-berlin.de/agg5 www.fujaba.de6 tfs.cs.tu-berlin.de/projekte/gxl-gtxl.html7 www.gupro.de/GXL


6.2 Reachability analysis by model-checking

Model checking of graph transformation systems has al-ready been investigated by Varro with the CheckVMLtool [44]. This subsection gives a brief overview how thetechnique can be applied to solve reachability problems.The interested reader is referred to [4,45] for more tech-nical details.

The model checking problem consists in decidingby exhaustive simulation whether a certain correctnessproperty holds in a given transition system. That re-quires a systematic traversal of all possible executionpaths of the system, i.e., all enabled transitions must betaken in all reachable states. The properties are typicallyformalized as temporal logic formulae.

From graph transformation systems to transition sys-tems: The system specification languages of mostmodel checkers are based on transition systems, wherethe structure of a state consists of (a subset of) proposi-tions over an a priori finite universe. When translatinggraph transformation systems into transition systems (asdone by the CheckVML tool, mapping graph transfor-mation systems to Promela, the input language of theSPIN model checker [24]) a graph is interpreted as astate, while the application of a rule for a certain oc-currence of the left hand side in such a graph yields atransition in the transition system. Traversing all en-abled transitions then means applying all rules with allpossible occurrences.

The main challenge consists in bridging the gap inthe abstraction levels: Graph transformation rules definehow an arbitrary instance of a type graph should behave,while transition system specifications in, e. g., Promelaare given for specific instances. That requires to generatePromela transitions for all the potential applications ofa graph transformation rule during a compile-time pre-processing phase.

Moreover, sophisticated optimization techniques areneeded in order to reduce the state space. For exam-ple, one can distinguish static and dynamic model ele-ments in the type graph (only the latter are modified bygraph transformation rules), representing only the dy-namic parts of instance graphs as states of the targettransition system. The occurrences of the rules in thestatic parts, instead, yield additional constraints on thepotential execution paths.

A drawback of the model checking approach is its apriori restriction to finite state systems. Therefore, onehas to fix an upper bound for the number of dynamicmodel elements that can be created by the transforma-tion rules. If the analysis is not successful, one can in-crease the bound and repeat the analysis within certainlimits.

From graph patterns to logic properties: The reacha-bility problem of a certain target configuration can beexpressed by safety and reachability properties.

– A safety property defines a desired property thatshould always hold on every execution path or (equiv-alently) an undesired situation which should neverhold on any execution paths.

– A reachability property describes, on the contrary, adesired situation which should be reached on at leastone execution path.

From a model checking point of view, safety andreachability properties are dual: the refutation of a safetyproperty is a counter-example which satisfies the reach-ability property obtained as the negation of the safetyproperty. On the other hand, if a safety property holds(or a reachability property is refuted) the model checkerhas to traverse the entire state space.

A safety or reachability property can be interpretedas a special graph pattern (called property graph) whichimmediately terminates the verification process if it ismatched successfully. As shown in [37], the propertiesexpressible in this way are equivalent to the ∃¬∃ frag-ment of (∀-free) first order logic with binary predicates.

An alternative solution for model checking graphtransformation systems has been proposed by Rensinkin the GROOVE system [36]. The essence of the ap-proach is to use the core concepts of graphs and graphtransformations all the way through during model check-ing. This means that states are explicitly representedand stored as graphs, and transitions as applications ofgraph transformation rules. Furthermore, graph-specificmodel checking algorithms are applied for traversing thestate space. This solution exploits the symmetric natureof problems by intensive graph isomorphism checks.

A comparison on the two approaches for model check-ing graph transformation systems can be found in [38].

6.3 Reachability analysis by simulation

In order to avoid the complete generation of the statespace of a model, and thus allow the refinement of in-finite state systems, we may use graph transformationtools for the interactive simulation. The PROGRES [41]tool is especially suitable for this purpose since it sup-ports, besides the mere execution, depth-first search andbacktracking. In PROGRES, we can define a type graph,the set of transformation rules, the start graph, and con-straints for safety invariants. The reachability propertyis represented by a so-called test graph which models thetarget pattern.

The interpreter simulates the execution of the trans-formation rules by non-deterministically choosing appli-cable rules. If the system runs into a dead end, back-tracking is used to roll back the current state. As soonas an occurrence of the test graph is found in the currenthost graph, the search successfully terminates.

Since the tool performs depth-first search in an infi-nite state space, it might run into an infinite path. For


this reason, one can define PROLOG-like cuts that in-terrupt the backtracking at certain points and guaranteetermination by limiting the search depth.

6.4 Tool integration

The integration of all these components can be carriedout through suitable XML data: XMI representations ofclass and communication diagrams can be transformedinto GXL documents, e.g., using XSLT scripts or simpletools.

GXL is the format supported by both AGG andCheckVML. The former exploits GXL for type and startgraphs, while the latter uses GXL graphs for the ini-tial configuration and the encoding of properties (i.e.,scenarios). AGG and CheckVML can also exchangegraph transformation rules encoded in GTXL, the GraphTransformation eXchange Language.

A data flow, which is still missing, but neverthelessimportant, is the propagation of analysis results pro-duced by the model checker back to the UML case tool.This flow does not only require a suitable data format,but also a rigorous transformation of traces and counterexamples into meaningful decorations of UML elements.

6.5 User roles

The tools and artifacts discussed above imply two kindsof users, namely style architects and application archi-tects.

If the presented styles for business- and service-oriented architectures are to be modified or adapted toother platforms, then users who are proficient in bothgraph transformation and architectural styles can serveas style architects to design the graph transformationsystems that specify platform-specific concepts and re-configuration mechanisms. The style architect also de-fines the mapping between the type graph and partsof the UML meta-model (possibly extended by style-specific stereotypes) which can be used to convert UMLdiagrams into the graph representations. Eventually, thestyle architect has to relate the styles for different levelsof platform abstraction by suitable refinement relations.

While specific rules and mappings are required foreach architectural style, several architectures can exploitthe same style. As soon as rules and UML mapping aredefined, application architects can model their architec-tures using conventional UML diagrams (suitably stereo-typed for the chosen style) and validate and refine themby means of our approach.

7 Related work

The work presented in this paper is rooted in four mainresearch directions: architecture description languages,

model checking of software architectures, graph trans-formations, and architectural refinement.

Besides the many proposals for Architecture Descrip-tion Languages (ADLs), like Rapide [27], Wright [3], orDarwin [28], we must mention those approaches thatexploit graph transformation [21,22,25,43,46] to reasonon the consistency of reconfiguration operations and in-teraction of components with respect to structural con-straints. Our work is in this tradition, but it combinesthe formal approach with the notion of style-based re-finement.

Le Metayer [25] describes architectures by graphs andthe valid graphs of an architectural style by a graphgrammar. Reconfiguration is described by conditionalgraph rewriting rules. He uses static type checking toprove that the rewriting rules are consistent with the re-spective style. In comparison to our work, his graphs rep-resent computational entities but no connectors, speci-fications, or other resources. And, instead of a graphgrammar, we use a declarative type graph to define thevalid graphs of the architectural style.

Wermelinger and Fiadeiro [46] provide an algebraicframework based on Category theory where architec-tures are represented as graphs of CommUnity programsand superpositions. The architectural style, given as atype graph, restricts the ways connectors can be ap-plied to components. Dynamic reconfigurations are spec-ified by graph transformation rules over architecture in-stances. Both, styles and rules are used for modelingdomain-specific restrictions rather than the underlyingplatform as we do. Consequently, they do not deal withrefinement relationships between different levels of plat-form abstraction.

In his Ph.D. thesis [21], Hirsch uses hypergraphsto represent architectures and hyperedge replacementgrammars to define the valid architectures of an archi-tectural style. Furthermore, he uses graph transforma-tion rules to specify run-time interactions among compo-nents, reconfigurations, and mobility. Hypergraphs andrules are textually represented using the concept of syn-tactic judgements which enables formal type checkingproofs. Similar to the other approaches, refinement rela-tionships are not discussed.

The use of graph transformation techniques to cap-ture dynamic semantics of models has also been inspiredby work proposed by Engels et al. in [15] under the nameof dynamic meta modeling. That approach extends meta-models defining the abstract syntax of a modeling lan-guage like UML by graph transformation rules for de-scribing changes to object graphs representing the statesof a model.

The use of model checking techniques for verifyingsoftware architectures has been thoroughly studied byseveral proposals. vUML [26], veriUML [10], JACK [17],and HUGO [40] support the validation of distributed sys-tems, where each statechart describes a component, butdo not support any complex communication paradigm.


JACK and HUGO only support communication based onbrodcasting, where the events produced by a componentare notified to all the others. vUML and veriUML sup-port the concept of a channel, that is, each componentwrites and reads messages on/from a channel. These pro-posals aim at general-purpose applications and can coverdifferent domains, but are not always suitable when weneed a specific communication paradigm.

They study static systems whose topology cannotvary at run-time. Similarly, Garlan et al. [12] and theresearchers involved in the Cadena project [18] appliedmodel-checking techniques to analyze specific architec-tures based on the publish/subscribe paradigm. Thefixed topology distinguishes these approaches from ourwork. In fact, we propose the study of the dynamic evo-lution of architectures with almost no attention to the in-ternals of components. Given our interest, we treat com-ponents as black-box entities, while all these approachesanalyze the behaviors of such components. They con-sider a given system (architecture) as if it were a com-plex and fixed automaton, but neglect the possibilitythat such automaton changes while the system evolves.Even if different, these approaches can also be seen asthe natural complement of our approach: We study whatthey do not address and they analyze what we neglect,mainly because of the size of resulting models. So far, noproposal attempts to address the whole picture.

There are also different notions of software refine-ment. For instance, Batory et. al. [6] consider featurerefinement which is modifying models, code, and otherartifacts in order to integrate additional features. For ev-ery new artifact type, they require a special refinementdefinition in order to compose software by generators.In our case, we concentrate on the refinement of archi-tectural models and derive platform-specific models fromabstract ones without adding any extra-functionality.

Such a refinement of architectures has first been dis-cussed by Moriconi et al. in [31]. Building on a formal-ization in first-order logic, the authors describe a generalapproach of rule-based refinement replacing a structuralpattern in the more abstract style by its realization inthe concrete style. The approach is complementary toours because it focuses on refinement of structure ratherthan behavior and does not capture reconfiguration. Thegeneral idea of rule-based refinement, however, could beapplicable in our context, too.

Garlan [16] stresses the fact that it is more power-ful to have rules operating on styles rather than on styleinstances. He formalizes refinements as abstraction func-tions from the concrete to the abstract style. We use asimilar approach to define the refinement relations (seeSect. 5). Also, he argues that no single definition of re-finement can be provided, but that one should state whatproperties are preserved. In our case, we concentrate onthe preservation of the dynamic semantics of reconfigu-ration and communication scenarios.

Other proposals on architecture refinement like [1,8,13] concentrate on structural refinements only, which iscomplementary to our work. The only formal approachwe are aware of that considers refinement of dynamicreconfiguration can be found in [7]. But, the paper pro-vides only a sketch of the ideas without any concretedefinition. Moreover, the approach is targeted on thetranslation from one ADL to another rather than onthe refinement between architectural styles that repre-sent different levels of platform abstraction.

8 Conclusions and future work

In this paper, we have given a formal definition ofservice-oriented architectures, seen as an architecturalstyle. We have defined a refinement relation from ageneric style of component-based systems to the SOAstyle that can be used to study the specialization ofplatform-independent scenarios, and we have discussedthe use of model checking techniques and tools to auto-mate this task. The results are based on the use of graphtransformation systems as models of architectural stylesat different levels of platform abstraction, representingreconfiguration and communication scenarios as graphtransformation sequences.

While we demonstrated the approach for service-oriented architectures in this article, it should alsobe applicable to other kinds of middleware infrastruc-tures modeled by corresponding architectural styles assketched in Sect. 6.5.

As stated in Sect. 7, a current challenge is to combinedescriptions and analysis of component behavior withruntime changes of component configurations. In a paral-lel paper [20], we elaborate on this problem and proposean extension of the architectural styles presented in thisarticle. These extensions allow to equip active entitieslike components, services, and connectors with processdefinitions that prescribe the order in which communi-cation and reconfiguration operations can be applied.

All applications of communication and reconfigura-tion rules have to respect the process definitions. Thisway, we integrate descriptions of component behaviorand of topological changes which are required to realizethe desired business processes. In [20], we demonstratehow this integration can be achieved without any newformal concepts. Consequently, we are still able to applythe aforementioned model checking-based analysis tech-niques. The restricted architectural behavior even facili-tates the analysis due to the smaller overall state space.We also discuss in [20] how the behavior-preserving re-finement can be guaranteed in face of the new processdescriptions.

Our future work addresses the development of an in-tegrated CASE environment for the analysis and step-wise refinement of software architectures which is aprerequisite for validating the approach on other non-


trivial examples. We are proficiently conducting exper-iments with existing graph transformation tools andmodel checkers in isolation, but the final objective is atool chain that seamlessly integrates the different com-ponents. The problem is largely one of incompatible in-put formats. Only the backward translations of analysisresults into user models poses conceptual questions.

References

1. M. Abi-Antoun and N. Medvidovic. Enabling the refine-ment of a software architecture into a design. In Proc.UML 99 - The Unified Modeling Language, volume 1723of LNCS, pages 17–31. Springer, 1999.

2. G. D. Abowd, R. Allen, and D. Garlan. Using style tounderstand descriptions of software architectures. ACMSoftware Engineering Notes, 18(5):9–20, 1993.

3. R. Allen. A Formal Approach to Software Architecture.PhD thesis, School of Computer Science, Carnegie Mel-lon University, 1997.

4. L. Baresi, R. Heckel, S. Thone, and D. Varro. Modelingand validation of service-oriented architectures: Applica-tion vs. style. In Proc. ESEC/FSE 03 European SoftwareEngineering Conference and ACM SIGSOFT Symposiumon the Foundations of Software Engineering, pages 68–77. ACM Press, 2003.

5. L. Baresi, R. Heckel, S. Thone, and D. Varro. Style-based refinement of dynamic software architectures. InProc. WICSA4 – 4th Working IEEE/IFIP Conference onSoftware Architecture, pages 155–164. IEEE ComputerSociety, 2004.

6. D. Batory, J. N. Sarvela, and A. Rauschmayer. Scalingstep-wise refinement. In Proc. ICSE 2003 – Int. Con-ference on Software Engineering, pages 187–197. IEEE,2003.

7. T. Bolusset and F. Oquendo. Formal refinement of soft-ware architectures based on rewriting logic. In Proc.RCS 02 Int. Workshop on Refinement of Critical Sys-tems, 2002. www-lsr.imag.fr/zb2002/.

8. C. Canal, E. Pimentel, and J. M. Troya. Specificationand refinement of dynamic software architectures. InProc. WICSA1, First Working IFIP Conference on Soft-ware Architecture, volume 140 of IFIP Conference Pro-ceedings, pages 107–126. Kluwer, 1999.

9. M. Champion, C. Ferris, E. Newcomer, and D. Orchard.Web Service Architecture, W3C Working Draft, 2002.http://www.w3.org/TR/2002/WD-ws-arch-20021114/.

10. K. Compton, Y. Gurevich, J. Huggins, and W. Shen. Anautomatic verification tool for UML. Technical ReportCSE-TR-423-00, University of Michigan, EECS Depart-ment, 2000.

11. A. Corradini, U. Montanari, and F. Rossi. Graph pro-cesses. Fundamenta Informaticae, 26(3,4):241–265, 1996.

12. D. Garlan and S.Khersonsky and J.S. Kim. Model check-ing publish-subscribe systems. In Proceedings of the 10th

SPIN Workshop, volume 2648 of LNCS, May 2003.

13. M. Denford, T. O’Neill, and J. Leaney. Architecture-based design of computer based systems. In Proc.StraW03, Int. Workshop From Software Requirements toArchitectures, 2003. se.uwaterloo.ca/~straw03/.

14. H. Ehrig, M. Pfender, and H.J. Schneider. Graph gram-mars: an algebraic approach. In 14th Annual IEEE Sym-posium on Switching and Automata Theory, pages 167–180. IEEE, 1973.

15. G. Engels, J.H. Hausmann, R. Heckel, and St. Sauer.Dynamic meta modeling: A graphical approach to theoperational semantics of behavioral diagrams in UML.In Proc. UML 2000 - The Unified Modeling Language,volume 1939 of LNCS, pages 323–337. Springer, 2000.

16. D. Garlan. Style-based refinement for software architec-ture. In Proc. ISAW-2, 2nd Int. Software ArchitectureWorkshop on SIGSOFT ’96, pages 72–75. ACM Press,1996.

17. S. Gnesi, D. Latella, and M. Massink. Model check-ing UML statecharts diagrams using JACK. In Proceed-ings of the 4th IEEE International Symposium on HighAssuarance Systems Enginering (HASE), pages 46–55.IEEE Press, 1999.

18. J. Hatcliff, W. Deng, M.B. Dwyer, G. Jung, and V. Ran-ganath. Cadena: An integrated development, analysys,and verification environment for component-based sys-tems. In Proceedings of the 25th International Confer-ence on Software Engineering, pages 160–172, May 2003.

19. R. Heckel, M. Lohmann, and S. Thone. Towards aUML profile for service-oriented architectures. In Proc.of Workshop on Model Driven Architecture: Founda-tions and Applications (MDAFA), CTIT Technical Re-port TR-CTIT-03-27. University of Twente, Enschede,The Netherlands, 2003.

20. R. Heckel and S. Thone. Behavior-preserving refinementrelations between dynamic software architectures. InProc. of the 17th Int. Workshop on Algebraic Develop-ment Techniques, WADT 2004, LNCS. Springer, 2004.to appear.

21. D. Hirsch. Graph transformation models for software ar-chitecture styles. PhD thesis, Departamento de Com-putacion, Universidad de Buenos Aires, 2003.

22. D. Hirsch and U. Montanari. Synchronized hyperedge re-placement with name mobility. In Proc. CONCUR 2001- Concurrency Theory, volume 2154 of LNCS, pages 121–136. Springer, 2001.

23. C. Hofmeister, R. Nord, and D. Soni. Applied SoftwareArchitecture. Addison-Wesley, 2000.

24. G. Holzmann. The model checker SPIN. IEEE Transac-tions on Software Engineering, 23(5):279–295, 1997.

25. D. Le Metayer. Software architecture styles as graphgrammars. In Proc. 4th ACM SIGSOFT Symposium onthe Foundations of Software Engineering, volume 216 ofACM Software Engineering Notes, pages 15–23. ACMPress, 1996.

26. J. Lilius and I.P. Paltor. vUML: a tool for verifying UMLmodels. In Proceedings of the 14th IEEE InternationalConference on Automated Software Engineering (ASE),pages 255–258, October 1999.

27. D. Luckham, J. Kenney, L. Augustin, J. Vera, D. Bryan,and W. Mann. Specification and analysis of system ar-chitecture using rapide. IEEE Transactions on SoftwareEngineering, 21(4):336–355, 1995.

28. J. Magee, N. Dulay, S. Eisenbach, and J. Kramer. Speci-fying Distributed Software Architectures. In Proc. ESEC95 - 5th European Software Engineering Conference, vol-ume 989 of LNCS, pages 137–153. Springer, 1995.


29. N. Medvidovic, D. S. Rosenblum, D. F. Redmiles, andJ.E. Robbins. Modeling software architectures in theUnified Modeling Language. ACM Transactions on Soft-ware Engineering and Methodology (TOSEM), 11(1):2–57, January 2002.

30. J. Miller and J. Mukerji. MDA Guide Version 1.0.1.Object Management Group, 2003. www.omg.org/docs/

omg/03-06-01.pdf.

31. M. Moriconi, X. Qian, and R. A. Riemenschneider. Cor-rect architecture refinement. IEEE Transactions on Soft-ware Engineering, 21(4):356–372, 1995.

32. E. Di Nitto and D. Rosenblum. Exploiting ADLs to spec-ify architectural styles induced by middleware infrastruc-tures. In Proc. of the 21st International Conference onSoftware Engineering, ICSE 99, pages 13–22. IEEE Com-puter Society Press, 1999.

33. Object Management Group. UML 2.0 OCL FinalAdopted Specification, 2003. www.omg.org/cgi-bin/doc?ptc/2003-10-14.

34. Object Management Group. UML 2.0 Superstructure Fi-nal Adopted specification, 2003. http://www.omg.org/

cgi-bin/doc?ptc/2003-08-02.

35. Object Management Group. XMI: XML Metadata Inter-change, v2.0, 2003. http://www.omg.org/cgi-bin/doc?formal/2003-05-02.

36. A. Rensink. The GROOVE simulator: A tool for statespace generation. In M. Nagl, J. Pfalz, and B. Bohlen,editors, Proc. Application of Graph Transformations withIndustrial Relevance (AGTIVE ’03), volume 3062 ofLNCS, pages 479–485. Springer, 2003.

37. A. Rensink. Canonical graph shapes. In D. A. Schmidt,editor, Programming Languages and Systems — Euro-pean Symposium on Programming (ESOP), volume 2986of LNCS, pages 401–415. Springer, 2004.

38. A. Rensink, A. Schmidt, and D. Varro. Model check-ing graph transformations: A comparison of two ap-proaches. In H. Ehrig, G. Engels, F. Parisi-Presicce, andG. Rozenberg, editors, Proc. 2nd International Confer-ence on Graph Transformation, ICGT 2004, volume 3256of LNCS, pages 226–241. Springer, 2004.

39. J. E. Robbins, N. Medvidovic, D. F. Redmiles, and D. S.Rosenblum. Integrating architecture description lan-guages with a standard design method. In Proc. of the20 th International Conference on Software Engineering,ICSE 98, pages 209–218. IEEE Computer Society, 1998.

40. T. Schafer, A. Knapp, and S. Merz. Model checking UMLstate machines and collaborations. Electronic Notes inTheoretical Computer Science, 55(3):13 pages, 2001.

41. A. Schurr, A.J. Winter, and A. Zundorf. The PROGRESapproach: Language and environment. In H. Ehrig,G. Engels, H.-J. Kreowski, and G. Rozenberg, editors,Handbook on Graph Grammars and Computing by GraphTransformation, volume 2: Applications, Languages andTools. World Scientific, 1999.

42. M. Shaw and D. Garlan. Software Architecture: Perspec-tives on an Emerging Discipline. Prentice-Hall, 1996.

43. G. Taentzer, M. Goedicke, and T. Meyer. Dynamicchange management by distributed graph transforma-tion: Towards configurable distributed systems. In Proc.TAGT’98 - Theory and Application of Graph Transfor-mations, volume 1764 of LNCS, pages 179–193. Springer,2000.

44. D. Varro. Towards symbolic analysis of visual modelinglanguages. In Proc. GT-VMT 2002 - Int. Workshop onGraph Transformation and Visual Modeling Techniques,volume 72 of ENTCS, pages 57–70. Elsevier, 2002.

45. D. Varro. Automated formal verification of visual mod-eling languages by model checking. Journal of Softwareand Systems Modeling, 3(2):85–113, 2004.

46. M. Wermelinger and J. L. Fiadeiro. A graph transforma-tion approach to software architecture reconfiguration.Science of Computer Programming, 44(2):133–155, 2002.

47. A. Winter, B. Kullbach, and V. Riediger. An overview ofthe GXL graph exchange language. In S. Diehl, editor,Software Visualization: International Seminar, DagstuhlCastle, Germany, May 20-25, 2001. Revised Papers, vol-ume 2269 of LNCS, pages 324–336. Springer, 2002.

Style-Based Modeling and Reﬁnement of Service-Oriented ...

Documents

Transcript of Style-Based Modeling and Reﬁnement of Service-Oriented ...