A service-oriented UML profile with formal support

Transcription

1 A servie-oriented UML profile with formal support Roberto Bruni 1, Matthias Hölzl 3, Nora Koh 2,3, Alberto Lluh Lafuente 1, Philip Mayer 3, Ugo Montanari 1, and Andreas Shroeder 3 1 University of Pisa, Italy 2 Cirquent GmbH, Germany 3 Ludwig-Maximilians-Universität Münhen, Germany Abstrat. We present a UML Profile for the desription of servie oriented appliations. The profile fouses on style-based design and reonfiguration aspets at the arhitetural level. Moreover, it has a formal support in terms of an approah alled Arhitetural Design Rewriting, whih enables formal analysis of the UML speifiations. We show how our prototypial implementation an be used to analyse and verify properties of a servie oriented appliation. 1 Introdution Servie-oriented omputing is a paradigm entered around the notion of servie: autonomous, platform-independent omputational entities that an be desribed, published, disovered, and dynamially assembled for developing massively distributed, interoperable, evolvable systems and appliations. However, servies are still developed in a poorly systemati, ad-ho way. Full fledged theoretial foundations are missing, but they are urgently needed for ahieving trusted interoperability, preditable ompositionality, and for guaranteeing seurity, orretness, and appropriate resoure usage. The IST-FET Integrated Projet SENSORIA aims at developing a omprehensive approah to the engineering of servie-oriented software systems where foundational theories, tehniques and methods are fully integrated into pragmati software engineering proesses. The development of mathematial foundations and mathematially wellfounded engineering tehniques for servie-oriented omputing onstitutes the main researh ativity of SENSORIA. In this paper we present reent efforts within SENSORIA aimed to develop high-level modelling languages with strong formal support. More preisely, we present a novel extension of UML4SOA, our UML2 profile and define here its formal semantis. The presentation is illustrated on a simple example taken from the automotive domain. UML4SOA is an extension of the UML2, the lingua frana of objet-oriented software analysis and design. UML4SOA enhanes UML2 with onepts for modelling strutural and behavioural aspets of servies. In this paper we present for the first time an extension of the profile to support arhitetural styles [18] and dynami reonfiguration. The formal semantis of the extension is defined in terms of Arhitetural Design Rewriting (ADR) [6], a graph-based approah for style-based design and reonfiguration of software arhitetures. This formalism is based on term rewriting and supports This work has been supported by the EU FET-GC2 IP projet SENSORIA, IST

2 Fig. 1. The On road onnetion senario both style-preserving and style-hanging reonfiguration of servie-oriented systems. We show how the ADR formalisation and its prototypial implementation in Maude [3], an be used to analyse and speify properties of UML4SOA speifiations. This paper is strutured as follows. Setion 2 introdues a running example from the automotive domain. Setion 3 presents our UML4SOA extension. Setion 4 desribes the formal ADR semantis of the profile. In Setion 5 we desribe how our prototypial implementation an be exploited to analyse and verify properties of UML4SOA speifiations. Setions 6 and 7 disuss related work and draw some onlusions. 2 Running Example We illustrate our approah by exploiting the On Road Connetivity senario from a SENSORIA ase study where a road assistane group of servies support ar drivers ativities. In the senario, ars aess wireless servies via stations that are situated along a road. We use a UML omponent to represent a onfiguration of suh a system. Figure 1 shows the white-box view of a system as a omponent (top-left box) that ontains other omponents (nested boxes) as parts of its internal assembly. A ar is onneted to the servie aess point of a station, whih an be shared with other ars that are attahed to the same station. A station and its aessing ars form a ell, whih is dynamially reonfigurable, in the sense that ars an move away from the range of the station of their urrent ell and enter the range of another ell. A handover protool permits ars to migrate to adjaent ells as in standard ellular networks. Stations, in addition to the servie aess point, use two other ommuniation ports that we all haining ports. Suh ports are used to link ells in larger ell hains. Stations an shut down, in whih ase their orphan ars are onneted to other stations. This is takled by appropriate system reonfigurations. We shall onsider a shut down situation in whih orphan ars swith from their normal mode of operation to a ell mode, in whih ase they beome standalone ad-ho stations (see the CarCells in Fig. 1).

3 3 UML4SOA Extension UML4SOA [14] is a UML profile that aims to ease the work of software engineers when designing and implementing servie-oriented software. UML4SOA is defined as a onservative extension of the UML2 metamodel built on top of the Meta Objet Faility (MOF) metamodel, with new elements reated as UML stereotypes, tagged values and onstraints defined in the Objet Constraint Language (OCL). Suh a MOF metamodel is the basis for the speifiation of a model-driven approah for the automated generation of servie-oriented software through model transformations. In fat, we defined transformation mehanisms from UML4SOA models to various languages (e.g. BPEL/WSDL [15]). UML4SOA uses extended internal struture and deployment diagrams. The extension for struture diagrams omprises servie, servie interfae and servie desription [14]. A omponent may publish several servies implemented as ports, whih are desribed by servie desriptions. Eah servie may ontain a required and a provided interfae that may ontain operations. These operations, in turn, may ontain an arbitrary number of parameters. The orhestration of these servies define a new servie. The extension for deployment diagrams is restrited to different types of ommuniation paths between the nodes of a distributed system, i.e. permanent, temporary and on-the-fly [20]. When modelling servie oriented appliations with our UML4SOA profile we observed the need for onvienent mehanisms to model the inherent dynami topologies of suh appliations: omponents join and leave the system and onnetions are rearranged. Suh dynami reonfigurations provide a number of benefiial features, but require a suitable mehanism to onstrain the possible evolutions of system onfigurations and to avoid ill-formed onfigurations. In order to express suh onstraints on topologies, it is ommon pratie to use arhitetural styles [18], i.e. sets of rules speifying the legal onstituents of a system onfiguration and the permitted interonnetions between them. Unfortunately, UML offers a limited and unsatisfatory support for arhitetural styles. We propose a novel extension of UML4SOA to remedy this. In addition we provide a methodology for modelling dynami hanges of onfigurations under arhitetural styles. 3.1 The UML4SOA Reonfigurations Profile We present our UML4SOA extension to draw easily understandable diagrams for arhitetural styles and reonfigurations. UML4SOA models servies with ports. For an enhaned readability we will omit in this paper the servie stereotype on ports, as all ports in the following represent servies. Servie providers are represented by omponents, while (one-to-one) onnetors are used to model servie referenes. Modelling System Configurations. We model system onfigurations with internal struture diagrams. Using suh diagrams allows us to model servies as ports of servie providers. Software engineers an use them to model the internal struture of strutured lassifiers (suh as omponents), and depit the wirings of fields as well as their names, types, and multipliities. Servie engineers must use the typing and multipliity features to ensure that the set of instanes is restrited to struturally indistinguishable

4 Fig. 2. Arhitetural style produtions for the On Road Connetivity senario onfigurations by setting all field multipliities to a fixed value, and speifying the types of all fields. In this way, instanes may only vary with respet to the internal state of the drawn omponents, but neither in their number nor in their interonnetions. To simplify the modelling of system onfigurations, we hene introdue the stereotype fragment, whih may be applied to omponents and requires that all omponent fields (the elements pitured in the internal struture diagram) are typed with omponent or onnetor types, and interpret unspeified multipliities as one. At the same time, we onstrain fragment omponents by forbidding the use range or multipliities. Consider Fig. 1 whih shows a sample system onfiguration of our senario. The internal struture diagram shows onstraints on possible interonnetion of subomponents. Obviously (interpreting default multipliity as one), all instanes of this diagram possess the same struture. A further interesting aspet of internal struture diagrams is that the ports of the ontainer lassifier may be drawn on the border of the diagram; if the ontainer lassifier owns ports, they may be onneted to internal elements by delegates edges, stating that the port of the ontainer lassifier represents a proxy of the attahed internal port. This allows to define named doking points for the instane, to whih other instanes may be glued to. For fragment omponents, we therefore require that all ports must be a delegate of a port of its ontained omponents. As the name implies, a fragment represents a fragment of a system onfiguration that an be plugged together with other fragments. A omplete system onfiguration is then modeled as a fragment without ports. Modelling Arhitetural Styles. UML internal struture diagrams provide a set of features to speify arhitetural styles. Indeed, suh diagrams desribe the stati struture

5 on the level of types, and allow to onstrain multipliities as well as interonnetions. However, the servie engineer is fored to model all alternatives allowed by a speifi arhitetural style within one single diagram beause of two reasons: first, there is no possibility to define abstrat UML omponents, and seond, subtype polymorphism, while present in UML, is not prominently used. We believe that suh mehanisms are not enough for a onvenient speifiation of styles. Our approah, instead, is based on a straightforward extension of the modelling of fragments with two modifiations. First, the onstraints on multipliities and on typing of fields are removed. Seondly, to define arhitetural styles in an indutive manner with omposeable patterns, by using refineable omponents instead of onrete ones. Components used to define arhitetural style patterns are tagged with the stereotype prodution. The non-terminal omponents marked with refineable may be replaed by any speializing prodution pattern. In our senario, for example, the prodution Chain (f. Fig. 2) ontains two ourrenes of refineable omponents, whih may be replaed by Chain, CarCell, and CarStation and produtions, as they all speialize the refineable. The prodution patterns define the legal wirings between omponents, and at the same time represent the basi building bloks of an arhitetural style. An arhitetural style is represented by a set of prodution patterns in the sense that every legal onfiguration must be produeable by applying the prodution patterns of the arhitetural style, replaing refineable by speializing prodution patterns. Similarly, it is possible to analyse a given system onfiguration with the help of prodution rules, and to determine whether it adheres to the arhitetural style defined by the used prodution rules. Modeling Reonfigurations under Arhitetural Styles. Reonfiguration rules are defined as transformation pakages having two pattern stereotyped omponents with internal struture diagrams (a left hand side and right hand side pattern), linked with a transforms edge. The name of fields in pattern omponents is interpreted as variable names and the enlosing transformation pakage as sope, hene allowing to share variables among left hand side and right hand side patterns. Often enough, reonfiguration rules depends on omplex or non-loal onditions. Consider for example the shut-down of a onnetion station: The onneted ars should form an ad-ho network hain whih will be onneted to the neighbouring operating stations. Having only simple rules at hand, one would have to write one rule for eah possible number of ars to be reonfigured. Using reursive rules, that is to say, using appliation onditions as in onditional rewrite frameworks, allows us to model the reonfiguration of arbitrary many ars to a linear ad-ho network, as in Fig. 3. As an be seen from the diagram, one stereotype was introdued, preonditions, whih is attahed to a dependeny edge and points to a pakage ontaining the reonfiguration preonditions. The sope of variables in preondition patterns is again the enlosing transformation pakage, hene allowing reonfigured arhitetures to arry over transformation results from the preonditions to the atually performed reonfiguration step. In this way, a omplex reonfiguration involving arbitrary many omponents may be modelled using simple and loal reonfigurations.

6 Fig. 3. Ad-ho network reonfiguration rules for the On Road Connetivity senario One major hallenge when modelling dynami reonfigurations is to guarantee that the onstraints of the arhitetural style are not violated. The benefit of our approah is that style preservation is ensured just by having the same types in the left- and righthand sides of reonfiguration rules.

7 Overall, the UML4SOA profile for arhitetural design allows to model sample instanes of arhitetural styles, prodution rules that define an arhitetural style and that an be omposed to reate system onfigurations, and a delarative rule-based framework that allows to model omplex reonfigurations of system onfigurations. 4 Formal support ADR [6] models systems by designs: a kind of typed, interfaed graphs whose inner items represent the system omponents and their interonnetions and whose interfaes express their overall types and onnetion apabilities. Domains of valid systems, (e.g. those ompliant to styles) are defined in an indutive way by means of design produtions (i.e. valid system ompositions), whih define an algebra of design terms, eah enoding the struture of the system and providing a proof of validity (e.g. style onformane). Reonfiguration and behaviour are given as term rewrite rules ating over design terms rather than over designs. This enables the flexible definition of valid (e.g. style preserving) reonfigurations. A prototypial implementation is desribed in [3], where we also extended the approah to the treatment of hierarhial graphs and explained how to write system speifiations and how to analyse them. ADR has been already validated over heterogeneous models suh as network topologies, arhitetural styles and modelling languages. For instane, in [4] we presented a formalisation of design and reonfiguration aspets of SRML, SENSORIA s business-level servie modelling language. 4.1 ADR Semantis for the UML4SOA Reonfiguration Profile This setion desribes, in an illustrative manner, the ADR formal semantis of the above presented UML4SOA profile. The main idea behind the formalisation is that fragment -stereotyped omponents, i.e. onfigurations, are represented by ADR designs, while the arhitetural onstraints imposed by UML onepts suh as multipliity or produtions are aptured by appropriate ADR types and design produtions. UML4SOA reonfiguration rules speified as transformation pakages are represented by ADR rewrite rules. It is worth to reall that the main novel priniples of the profile, i.e. style-onsistent design-by-refinement and style-preserving, onditional reonfigurations are indeed the quintessene of ADR. Modelling System Configurations in ADR. A design is a graph-based struture. Reall that a graph is a tuple G = V, E, θ where V is the set of nodes, E is the set of edges and θ : E V is the tentale funtion. Given a graph T (alled the type graph), a T-typed graph is a pair G, t G : G T, where G is the underlying graph and t G : G T is a graph morphism. From now on we assume that graphs are T-typed. Tehnially, a design is a triple d = L d, R d, i d, where L d is the interfae graph onsisting of a single so-alled non-terminal edge (the interfae) whose tentales are attahed to distint nodes; R d is the body graph; and i d : V Ld V Rd is the total funtion that maps interfae nodes to body nodes.

8 Station Station Station Car Car Car CarCell CarCell Car Fig. 4. The On Road Connetivity senario of Fig. 1 as an ADR design The visual representation of a design (see Fig. 4) depits the interfae as a dotted box with its type written in its top-left orner. The body is depited inside the dotted box. Edges are represented as boxes (possibly rounded), tentales as arrows (their order is given by their orientation) and nodes as small irles. The nodes being exposed on the interfae are denoted by waved lines. Fig. 4 exemplifies how UML4SOA fragment omponents of Fig. 1 an be mapped to ADR designs: servie ports are mapped to ADR nodes, while the port type determines the node type (e.g. UML types ChainingPort, CarAessPort and StationAessPort are represented by node types, and, respetively). Components are mapped to hyper-edges, where the omponent type determines the hyper-edge type. UML onnetors are mapped to binary edges of a predefined type. The interfae of the design is defined by the ports and the generalisation of the fragment omponent. The ports of the fragment define the set of interfae nodes V Ld, and eah delegates edge defines a maplet of the mapping i d from interfae to body nodes V Rd. The type of the so-produed graph, as defined by the UML4SOA model, is determined by the generalisation of eah fragment ( in Fig. 1). Modelling Arhitetural Styles in ADR. The distintion between refinable omponents and non-refinable omponents amounts to the distintion between non-terminal and terminal edges in ADR. The underlying idea is the same: a non-terminal edge is an edge intended to be refined (i.e. replaed by an arbitrarily omplex graph). Non-terminal edges an appear in designs, representing unspeified parts of a onfiguration (a refinable omponent) or in design produtions (see later). Terminal edges instead represent parts of a graph that annot be further refined (non-refinable omponents). The style definition mehanisms of UML4SOA, i.e. internal struture diagrams and produtions, are modelled by ADR type graphs and by design produtions. Note however that some of the arhitetural onstraints involved in lass diagrams suh as multipliities annot be diretly mimiked by type graphs. Instead, they are dealt with at the level of design produtions. Consider the type graph of left on Fig. 5. It is easy to see that eah edge orresponds to a omponent (Car, Station, CarCell) or onnetor type (the overloaded symbol ).

9 Car Station Cars CarCell Station Station Fig. 5. Type graph for On Road Connetivity senario (left) and a orretly typed graph(right) Chain : CarStation : Cars Station Cars CarCell : CarCell NoCar : Cars Car : Cars Cars : Cars Cars Cars Cars Cars Car Cars Cars Cars Fig. 6. Design produtions for On Road Connetivity senario Non-terminal edges (Cars, ) are distinguished by their double border. In general, the type graph is obtained from the whole UML4SOA speifiation: adding terminal edges for eah non-refinable omponent type, non-terminal edges for eah refinable omponent type, nodes for port types, tentales for omponent ports and edges for the onnetors. Type graphs do not impose any multipliity onstraint, i.e. they would amount to a UML [0.. ] multipliity onstraint. A suitable way to impose a multipliity onstraint in ADR is by means of design produtions. For instane, the treatment of sets of ars in the UML4SOA speifiation via multipliities is dealt in ADR with the design produtions NoCar, Car and Cars (see Fig. 6), whih respetively allow to refine a generi set of ars as an empty set, a singleton or the union of two other sets. In this way, UML4SOA produtions are diretly mapped into ADR design produtions. For instane, in absene of prodution NoCar the multipliiy onstraint would be [1.. ]. We remark that produtions allow to refine the arhitetural onstraints imposed by a type graph alone. For instane, the graph on the right of Fig. 5 is well-typed but is not generated by our produtions.

10 Cars Car toell CarCell Fig. 7. Reonfiguration CarToCell Tehnially, a design prodution is very muh like a design but with an order on the non-terminal edges of the body graph (intuitively, the order of the arguments they represent). The type of a prodution p is A 1 A 2... A np A p, where A k is the nonterminal symbol labelling the k-th non-terminal edge e k of the body of the prodution. The funtional type A 1 A 2... A np A p assoiated to a prodution p is not an aident. In fat, p an be onsidered a funtion that when applied to a tuple d 1, d 2,..., d np of designs of types A 1, A 2,... A np, respetively, returns a design d = p(d 1, d 2,..., d np ) of type A p. The definition is obvious: d = (L p, R d, i p ), where R d is obtained from R p by replaing edge e k in it with graph R dk respeting the tentale funtion i dk, k = 1,..., n p. This view orresponds to a bottom-up design development: a design is onstruted by putting together some omponent designs. However, the dual view is also possible: a prodution an be seen as a refinement of an abstrat omponent of type A as an assembly of onrete and abstrat omponents, the latter being of type A 1, A 2,... A np. Modelling Reonfigurations under Arhitetural Styles. UML4SOA transformations are represented by ADR rewrite rules. We just reall here that one of the advantages of ADR reonfigurations over other graph-based approahes is style-preservation, whih is guaranteed by rewrites that do not hange the overall type (they an atually hange the type of ertain sub-parts in the rule derivation of the overall reonfiguration). Translating UML4SOA reonfiguration rules to ADR in the general ase is done by UML4SOA preonditions, transforms left-hand and right hand sides, and transformation labels are translated to their respetive ounterparts in ADR. In this proess, pattern omponents are translated to ADR designs by first produing ADR design graphs (replaing omponents with [0.. ] multipliities by the orresponding non-terminal hyper-edge, as done in the example with Cars) and then parsing the result using the ADR produtions generated from the UML4SOA produtions. The ad-ho network reonfiguration is takled by using indutive reonfiguration rules in SOS style. The base reonfiguration involves a single ar (see Fig. 7): CarToCell : Car toell CarCell The indutive ase we onsider is illustrated in Fig. 8, where the union of two olletions of ars is reonfigured as the onatenation of the respetive reonfigured ells, provided that these are possible: CarsToCellChain : toell x 1 x 1 toell x 2 x 2 Cars(x 1, x 2 ) toell Chain(x 1, x 2 )

11 x 1 :Cars toell x 1 : x 2 :Cars toell x 2 : Cars toell x 2 : x 1 : x 1 :Cars x 2 :Cars Fig. 8. Reonfiguration CarsToCellChain x:cars toell x : Station x : x:cars Fig. 9. Reonfiguration CellToChain The ell with the station shutting down is reonfigured by the rule (see Fig. 9): CellToChain : x toell x CarStation(x) x Obviously, types are not preserved by CarToCell and CarsToCellChain and thus the right- and left-hand sides of the rewriting rule annot be applied in the same ontexts. Type hanging allows for the modelling of reonfigurations that lead from one arhitetural style to another. However, this is not what we want in this example and thus labelled rules are given in SOS style. The last rule CellToChain, instead, is given as a onditional term rewrite rule, where the premise is for a olletion of ars to beome a hain ell, while the onlusion atually transforms a hain of ells into a hain of ells. The type is preserved and the silent label makes it appliable in any larger ontext (unlike style-hanging rewrites labelled toell).

12 5 Analysis and Verifiation This setion emphasizes the benefit of having a formal semantis for our UML profile by desribing how the use of our implementation of ADR [3] an be used to analyse and verify properties of UML4SOA speifiations. We remark that the implementation of the formalisation, i.e. the translation of UML4SOA speifiations to ADR speifiations has not been implemented yet. On the other hand, a prototypial implementation of ADR is available for download [3]. Nevertheless, we offer suffiient evidene of the potential of our approah as a helpful support for software arhitets. Analysing Styles. After a first development of a UML4SOA speifiation, a software arhitet might wonder whether the defined arhitetural styles enjoy some properties he desires. For instane, in our example senario one ould be interested in stating that no prodution builds a onfiguration in whih the left and right haining ports are disonneted. It is easy to see tat this property trivially holds in our example. However, as senarios beome ompliated suh properties beome more subtle. Note that due to the indutive definition of styles it holds that if all produtions satisfy the property, then the property holds for any possible onfiguration. This is indeed the ase of the example property: all s are un-broken hains. Our implementation inludes a graph logi (Courelle s MSO) that allow us to reason about the struture of a graph. Suh mehanism an be used to analyse struture of UML4SOA produtions by analysing the underlying graphs. The above example for instane is a well known property of graph onnetivity whih an be expressed in MSO by X.(( x, y(y X z R(y, z) z X y.r(a, y) y X)) b X), where X is a set of nodes, x,y and z are nodes, R abbreviates the existene of an edge between two nodes, and a, b are shorthands for the left and right hand-side haining ports. In words, we look for a all sets of nodes X losed under the transitive losure of the relation R of diret adjaeny and ontaining all nodes adjaent to b. If all suh sets ontain b too, then a and b reahable from eah other. The above formula holds for all body graphs of produtions. We an of ourse, write abbreviations for suh formulae to onstrut a sort of library of strutural properties. Cheking Style Conformane. One the software arhitet is onfident with the style he has designed he might be interested in re-using some of his old speifiations. After manually applying some osmetis on the types of diagrams and other entities, he might want to know whether the resulting instane is onsistent with the style. Roughly, he needs a orret parsing in terms of the produtions. This is supported by a mehanism that roughly generates design terms and heks if the resulting designs are isomorphi to the onfiguration under analysis. For instane, one an show that the onfiguration in Fig. 4 is style onformant by finding the parsing that we entioned in Setion 3.1. A ounterexample an be find in Fig. 5 (right). Finding Configurations Automatially. Model finding is the problem of analysing the state spae of all possible instanes of his arhitetural style. Suh analysis serves as a omputer-aided design proess or as a debugging method to find out inonsistenies in models, styles or properties. Our model finding system is based on two mehanisms:

13 one to generate a state spae of models and one to explore it. In our approah we an define a rewrite theory that simulates a design-by-refinement proess, roughly onsisting of the ontext-free graph grammar obtained by a left-to-right reading of design produtions. In order to explore suh state spaes we an use various mehanisms of Maude. Typially, the spae of onfigurations is infinite and bounds are required. For istane, we an use searh strategies to find onfigurations with at 4 ars, 3 stations and 2 ar ells and we obtain, among others, the design of Fig. 4. Analysing Stati Aspets of Configurations. Now that the software arhitet has adapted some of his old designs and possibly built new ones, he might want to reason about them. Returning to our example, we might wonder if a onfiguration has at least n ars or is free of ars in ell mode. Reall that our onfiguratinos have two levels: the more abstrat level of design terms and the more detailed level of the diagrams. We an expet dual mehanisms for stating strutural aspets. Indeed, we saw above that the properties of diagrams are supported by graph logis. Similarly, properties an be stated at the level of design terms. Our ADR implementation does this by means of spatial logis, the natural and strutured way to reason about term-like speifiations. Basially, for eah design prodution f used to ompose designs the logi inorporates a spatial operator f-so to deompose a design. For instane, formula Chain-so(φ 1,φ 2 ) is satisfied by all those designs of the form Chain(x1,x2), where design x1 satisfies formula φ 1 and design x2 satisfies formula φ 2. Consider the property that states a olletion of ars has at least n ars. We an indutively define it as follows: For n equal to zero the formula always holds. For n + 1 the formula holds whenever the term is deomposable as the omposition via operation Cars of one ar (Car-so) and a term with at least n ars. Using suh formulas we an for instane hek that the design of Fig. 4 satisfies the property stating that eah station has at least one ar and violates the property stating that eah station has at least two ars. Analysing Dynami Instanes of Configurations. At this point the software arhitet might be onfident with the strutural properties enjoyed by his onfigurations. The modelled appliation, however, has a dynami arhiteture with a various reonfiguration rules as those we use in our running example. Can he express that some property is invariantly preserved or that some bad property will never happen? The standard way to reason about suh properties is by means of temporal logis. In our ase temporal logis are supported Maude s built-in LTL model heker. Properties regarding dynami aspets of reonfigurations are expressed using the Linear-time Temporal Logi (LTL). Roughly, one is able to reason about infinite sequenes of reonfigurations, by expressing properties on the ordering of state (i.e. onfiguration) observations. Suh observations are prediates expressing strutural properties as above mentioned. As an example we an write the formula asserting that it is always true that a olletion of ars has at least 2 ars as [] at-least-k-ars(2), where [] denotes the always temporal operator. This property trivially holds for the design of figure 4. Indeed, no reonfiguration rule allows ars to leave the system so that their number remains onstant.

14 6 Related Work The Servie Component Arhiteture (SCA) [8] fouses on poliies and implementation aspets of servies but is not based on UML. The work in [19] is based on UML models and transformations to exeuteable desriptions of servies. However, the approah laks an appropriate UML profile preventing one from building models at the high level of abstration; thus produing overloaded diagrams. The work of [11] proposes to use modes to address dynami reonfiguration of servie-oriented arhitetures and extends the UML to visualize suh reonfiguration. The UML extension stiks to the mode terminology and does not inlude a visualization of the transformation rules. The OMG is also working to standardize a UML profile and metamodel for servies (UPMS) [17]. The urrent version does not support styles or reonfigurations. Strutural aspets for servies, modelled in UML, have also been addressed in several other works (e.g. [13]); however, as far as we know, none of them is based on a formal bakground like the one presented here. The only exeption is the UML extension for servie-oriented arhitetures that an be found in [2]. The approah inludes refinement issues based on arhitetural styles and is formalized by graph tranformation systems. It inludes stereotypes for the strutural speifiation of servies. However, it does not introdue speifi model elements for the orhestration of servies, the notion of style there is less expressive (it basially amounts to our type graphs) and reonfigurations there are limited to unonditional ones. A ompletely different approah to modelling arhitetural styles in UML would be to use onstraints expressed in the OMG Objet Constraint Language (OCL). To the best of our knowledge, however, there is no reonfiguration approah using solely OCL, whih would have two drawbaks: OCL is a textual notation and it would introdue another language to the servie engineer. ADR has been mainly inspired by graph-based approahes to arhitetural styles [12,16] (see [6] for a omparison). The use of graphs and graph transformations to model arhitetural styles has been proposed by several authors (see [18], for instane) who based their approahes on the onept of shapes in programming languages. ADR shares also onepts with approahes based on proess aluli with reonfigurable omponents (e.g. [1]). The main advantages of ADR are that the hierarhial and indutively based approah allows us to ompatly represent omplex reonfiguration rules, and that, style preservation is guaranteed by onstrution. ADR is also related to approahes that deal with reonfigurations in software arhitetures defined by an ADL (see [5]). The main advantages of ADR are the unified treatment of design, behaviours and reonfiguration, and the use of hierarhial, indutive reonfigurations. A omparison with a logi based arhitetural design methodology was given in [7]. 7 Conlusion We have presented a novel extension of UML4SOA, our approah for the modelling of servie oriented arhitetures. The profile offers suitable ingredients to deal with arhitetural styles and reonfigurations. We have equipped the proposed profile with a formal semantis, offering support for analysis and verifiation from the very early

15 stages of modeling. Thus, our approah is a omprehensive and pragmati but theoretially well founded approah to software engineering for servie-oriented systems. Our urrent efforts are aimed ompleting our tool support by automatising the translation of UML4SOA speifiations and upgrading the prototypial implemantion of ADR to a real tool. In future work we would like to integrate our approah in the SENSORIA suite of tools and tehniques, whih already inludes some development [10] and reengineering (legay systems as servies) [9] instruments. Referenes 1. N. Aguirre and T. S. E. Maibaum. Hierarhial temporal speifiations of dynamially reonfigurable omponent based systems. ENTCS, 108:69 81, L. Baresi, R. Hekel, S. Thöne, and D. Varró. Style-based modeling and refinement of servie-oriented arhitetures. SOSYM, 5(2): , R. Bruni, A. Lluh Lafuente, and U. Montanari. Hierarhial Design Rewriting with Maude. In WRLA 08, ENTCS. Elsevier, To appear. 4. R. Bruni, A. Lluh Lafuente, U. Montanari, and Emilio Tuosto. Servie Oriented Arhitetural Design. In TGC 07, volume 4912 of LNCS, pages Springer, R. Bruni, A. Lluh Lafuente, U. Montanari, and E. Tuosto. Arhitetural Design Rewriting as an Arhiteture Desription Language. R2D2 Mirosoft Researh Meeting, R. Bruni, A. Lluh Lafuente, U. Montanari, and E. Tuosto. Style Based Arhitetural Reonfigurations. In EATCS Bulletin, volume 94, pages February A. Buhiarone, R. Bruni, S. Gnesi, and A. Lluh Lafuente. Graph-Based Design and Analysis of Dynami Software Arhitetures. In Conurreny, Graphs and Models, volume 5065 of LNCS. Springer, S. Consortium. Servie Component Arhiteture Poliy Framework, Version 1.0, R. Correia, C. Matos, R. Hekel, and M. El-Ramly. Arhiteture migration driven by ode ategorization. In ECSA, volume 4758 of LNCS, pages Springer, H. Foster and P. Mayer. Leveraging integrated tools for model-based analysis of servie ompositions. In ICIW 08. IEEE Computer Soiety Press, H. Foster, S. Uhitel, J. Kramer, and J. Magee. Leveraging Modes and UML2 for Servie Brokering Speifiations. volume 389 of LNCS, pages CEUR, D. Hirsh and U. Montanari. Shaped hierarhial arhitetural design. ENTCS, 109, S. Johnson. UML 2.0 Profile for Software Servies, N. Koh, P. Mayer, R. Hekel, L. Gözy, and C. Montangero. D1.4a: UML for Servie- Oriented Systems. Speifiation, SENSORIA Projet , P. Mayer, A. Shroeder, and N. Koh. A Model-Driven Approah to Servie Orhestration. In SCC 08, IEEE, pages 1 6. IEEE, D. L. Métayer. Desribing software arhiteture styles using graph grammars. IEEE Transations on Software Engineering, 24(7): , Objet Management Group (OMG). UML Profile and Metamodel for Servies, M. Shaw and D. Garlan. Software Arhiteture: Perspetives on an Emerging Disipline. Prentie-Hall, New Jersey, USA, D. Skogan, R. Grønmo, and I. Solheim. Web servie omposition in UML. In EDOC 04, pages IEEE Computer Soiety, M. Wirsing, A. Clark, S. Gilmore, M. Hölzl, A. Knapp, N. Koh, and A. Shroeder. Semanti-Based Development of Servie-Oriented Systems. In FORTE 06, volume 4229 of LNCS, pages Springer, 2006.