Modeling portlet aggregation through statecharts

Modeling portlet aggregation through statecharts

Oscar Díaz, Arantza Irastorza, Maider Azanza, Felipe M. [email protected], [email protected], [email protected],

[email protected]

Department of Computer Languages and SystemsUniversity of the Basque Country

San Sebastian (Spain)

Abstract. A portal is a key component of an enterprise integration strategy. Itprovides integration at the user interface level, whereas other integration tech-nologies support business process, functional or data integration. To this end,portlet syndication is the next wave following the successful use of content syn-dication in current portals. A portlet is a front-end application which is renderedwithin the portal framework. From this perspective, portlets can be regarded asWeb components, and the portal as the component container where portlets areaggregated to provide higher order applications. Unlike back-end integration ap-proaches (e.g. workflow systems), portlet aggregation demands front-end solu-tions that permit users navigate freely among portlets in a hypertext way. To thisend, the Hypermedia Model Based on Statecharts is used. This model uses thestructure and execution semantics of statecharts to specify both the structural or-ganization and the browsing semantics of portlet aggregation. Besides familiarity,statecharts bring formal validation to portal design, helping portal designers inthe development of structured portals. As a prove of concept, this model has beenrealized in the eXo portal platform.

1 Introduction

The significance of portal applications stems not only from being a handy way to accessdata but also from being the means of facilitating the integration with third-party ap-plications. Different standardization efforts (e.g. WSRP, JSR168) have provided a com-mon way to include applications within the portal realm: the portlets [3]. Portlets areapplications within a portal in much the same way as servlets are applications withina Web server. The difference stems from portlets being full-fledge, multi-step, user-facing applications. They are very much like Windows applications in a user desktop,in the sense that a portlet renders markup fragments that are surrounded by a decorationcontaining controls.

However, the added-value of a portal does not stop at providing a single access pointfor invoking heterogeneous applications but it should also include means to integratethese applications. A portal can contain several portlets, and portlet aggregation refersto the combination of a set of portlets to achieve a common goal within the portal realm.

So far, this aggregation is totally unconstrained. A portal page can contains a num-ber of portlets whose fragments can be arranged into columns and rows, and minimized,

maximized, or arranged to suit the user’s needs. This is known as “side-by-side” aggre-gation. The value rests on providing a unified access point to the user, and renderingtogether content from diverse sources.

In the current approach, however, portlet navigation (i.e. browsing along the portletfragments) is completely detached from portal navigation (i.e. browsing along the portalpages). And all portlets are readily rendered when entering in the container page.

This situation prevents the portal from becoming a proper workplace where taskstend to have some order. Portlets, as task enablers, should also be engaged in someworkflow that guides the user in accomplishing some goal. However, traditional work-flows impose a rigid control on the activities and data available where tasks are prede-termined. By contrast, a “deskflow” should be more easy-going where users can freelybrowse along the available tasks while some general guidelines can be prescribed. Inother words, integration at the back-end can be better served by a workflow, predeter-mined approach where user intervention is minimized and rigidly controlled. By con-trast, integration at the front-end aligns better with an hypertextual approach where theuser is less constrained.

Therefore, the challenge is to find a formalism ductile enough to specify both con-straint and unconstrained flows. This paper argues about the benefits of using statechartsfor this purpose.

However, statecharts have been traditionally used for control specification and pre-sentation concerns fall outside. But portlets are front-end applications that conform theportal interface. Therefore, an extension to statecharts is adopted that uses the structureand execution semantics of statecharts to specify both the structural organization and thebrowsing semantics of portlet aggregation [5]. The paper provides a sample case for asix-portlet portal which has been implemented in the eXo platform. Those interested inseeing the Browsing portal working can visit http://www.onekin.org/academicBrowsing/.

The rest of the paper is structured as follows. Section 2 introduces the notion ofportlet aggregation and its issues. Section 3 presents the portal deskflow, formalized bya statechart. Section 4 explains the presentation model, complementary to the statechartmodel. Section 5 is about related work and finally, conclusions are given in section 6.

2 Selection of the modeling approach

Broadly speaking, aggregation can be defined as the purposeful combination of a setof artifacts to achieve a common goal. Literature can then be classified according tothe type of artifacts being aggregated. If artifacts are text then, there is an extensiveliterature on hypertext approaches where the model helps to cope with the complexitiesof the structure and navigation of the application.

If the artifacts are Web services, aggregation models have been proposed to ei-ther orchestrate or compose Web services into higher-level services while preservingsome formal properties such as availability, reachability and the like. Also, an hybridapproach is possible where artifacts include both text and Web services. WebML is acase in point [10]. Here, the focus is on Web service composition scenarios that in-volve human interaction on the Web. Other kind of artifacts are software components.

Component-based development aims at building systems by assembling components.Finally, this work focuses on portlets as the artifact to be aggregated.

The peculiarities of the artifact (i.e. text, Web services, portlets) influence the ag-gregation model. For instance, Web services have input/output parameters. Hence, Webservice aggregation needs to address the role of parameters during aggregation (e.g.using semantic approaches [11][13]). By contrast, portlets do not have input/output pa-rameters. Instead of delivering a data-based XML document, portlets deliver markupfragments (e.g. XHTML) ready to be rendered by the portal. Moreover, portlets tend tobe stateful, and the interaction lasts for a whole session, rather than the simple requestthat characterizes the one-shot interaction of Web Services.

Based on the peculiarities of portlets and their most common containers, the portals,we identify two main requirements for the portlet aggregation model, namely:

– hypertext-like navigation style. Portlet aggregation should permit users to explorethe applications freely, by skipping among applications if required. This does notpreclude that a more conducted process à la workflow could need to be enforced insome cases, but the free-surfing style should be predominant.

– front-end aggregation. Portlets do not return data structures but markup (i.e. semi-structured documents where content and presentation are mixed together). There-fore, aggregation should be achieved in how markups from distinct portlets arearranged and sequentially presented. As an example, consider two portlets: pur-charseOrder permits to buy some product whereas creditRequest allows to applyfor a credit. The portal designer needs to enforce a precedence rule so that a creditcan not be requested till a product is bought during the same session. This rule canbe enforced in the back-end through some pre-conditions attached to the creditRe-quest service or some workflow engine enforcing the flow dependency. By contrast,a “front-end” approach can rely on disabling the “creditRequest” button until the“purchaseOrder” button has been clicked on. The integration is not achieved at theback-end but via presentation-based mechanisms.

To accomplish these requirements, the Hypermedia Model Based on Statecharts (HMBS)[5] has been adapted for our purposes. The use of statecharts [7,6] or their predecessors,state-transition diagrams, is common for modeling hypermedia applications, Web ser-vice composition [1,2] and reactive systems. Statecharts provide a concise and intuitivevisual notation as well as being rigorously defined with a formal syntax and operationalsemantics. A hypermedia system, and also a portal, may be considered as a reactivesystem, since it must interactively attend to external events given in the form of userrequests during browsing.

For the purpose of this paper, portal modeling implies describing:

– the structure of the portal, i.e how content is distributed both among pages andwithin a page

– the navigation of the portal, i.e. the order in which content is being made available

Next sections address these issues using statecharts and the HMBS model.

Fig. 1. Statechart of the Browsing portal

3 The portal deskflow

A portal defines a workspace, i.e. a compendium of front-end tasks. From a portal per-spective, a task is a unit of behaviour: you are either visualising the task or you are not.How the task itself achieves its duty is outside the portal realm. The portal responsibilityis to define a semi-structured flow among the contained tasks, i.e. the “deskflow”.

Statecharts are used to define the “deskflow”. Statecharts constitute a visual formal-ism for describing states and transitions in a modular fashion. It extends the classicalformalism of state transition diagrams by incorporating the notions of hierarchy, orthog-onality (concurrency), a broadcast mechanism for communication between concurrentcomponents, composition, and refinement of states. Specifically, an OR-type decompo-sition is used when a state is to be decomposed into a set of exclusive substates, whereasan AND-type decomposition is used to decompose a state into parallel, or orthogonalsubstates. Each concurrent region in an AND state is delimited by a dashed row.

As an example, consider that the following tasks can be achieved within a portal:the IEEESearch task, which comprises a subset of the functionality of the IEEE portal;the ACMSearch task, which covers part of the offering of the portal.acm.org for theACM organization; the CiteSeerSearch task, which includes the functionality for au-thor searching at citeseer; the DBLPSearch task, which embodies the functionality forauthor searching at Ley’s site; the DeliciousStore task, which provides the functional-ity available at del.icio.us for keeping track of references found in the Web; the ISIWoKtask, which permits to obtain distinct quality parameters of a journal (e.g. impact factor)or paper through the ISI Web of Knowledge portal.

From the portal perspective, tasks are basic states. These tasks can be arrangedalong a deskflow as illustrated in figure 1. Here the portal designer initially considerstwo states: you are either searching for something on the Web, or you are storing yourfinding in del.icio.us. At any time, you can move to the ISIWoK task to consult theimpact. Search is an abstract state which contemplates two situations: searching for a

Fig. 2. “Presentation configuration” counterpart of the state configuration {Browsing,Search, PaperSearch, IEEESearch, ACMSearch}

paper or searching for an author. Papers can be looked for at either IEEE or ACM. Theseoptions are simultaneously available, and hence, they are represented as an AND state(i.e. dotted line). On the other hand, author information can be obtained through theCiteSeerSearch task or DBLPSearch task. Both tasks can be simultaneously available,hence, they are also modeled as another AND state.

At a given moment, the system is in a certain configuration state, i.e. the set ofcurrently active states of the statechart [7]. Basically, a configuration state comprisesa basic state (e.g. ACMSearch), and its container states (i.e. PaperSearch and Search).The substates of an OR decomposition are not allowed to be active simultaneously,whereas the substates of an AND decomposition are simultaneously active as long astheir container states remains active.

For our sample problem four state configurations are possible:

– configuration1: {Browsing, ISIWoK}– configuration2: {Browsing, DeliciousStore}– configuration3: {Browsing, Search, PaperSearch, IEEESearch, ACMSearch}– configuration4: {Browsing, Search, AuthorSearch, CiteSeerSearch, DBLPSearch}

By mapping each state to its widget counterpart, state configurations are mapped into“presentation configurations”. Figure 2 shows the result for the first state configuration.Next section addresses how this mapping is realized.

4 The portal structure

Portal structure refers to the presentation counterpart of the deskflow. To this end, weadapt the extensions proposed by the HMBS model to the portal setting. Specifically,

HMBS [5] extends statecharts with mappings to those primitives found in hypertextapplications. Hence, we first introduce the presentation model (e.g. rendering concernsin a portal setting), and next, the mapping from a state configuration to a presentationconfiguration.

4.1 The presentation model

Basically, the presentation model refers to the GUI widgets and layouts used for sup-porting portal pages. For our case, GUI widgets are portlets, anchors and texts. Styleand layout parameters are used to govern the aesthetic and layout of these widgets. Nextparagraphs describe the main parameters which, with distinct variations, can be foundin IDE for portal development such as eXo, Oracle Portal or IBM’s Web Sphere1.

Style parameters include background-color, border-style (values include none, dot-ted, dashed, and so on), border-color, border-width, font-family, color (often referred toas the foreground color), font-size, font-style (values include normal italic and oblique),text-align (i.e. how text is aligned within the element) and transition. The latter indicateshow transitions are realized. The options include anchor (e.g. a button) or helping textwhere the transition is achieved by clicking on the underlined text.

As for the layout, it indicates how the artifacts are arranged along the presentationworkspace. This is specified through a template function that takes a state configurationand produces a template where each corresponding artifact is placed in a cell of the tem-plate. This template is then ready to be rendered as an HTML <table> tag. Therefore,for the purpose of this paper, a table-based page is the rendering counterpart of a stateconfiguration. However, to avoid cluttered pages in dense configuration states, othertemplate functions can be envisaged where frames or tabs could be used to distributethe presentation artifacts along distinct presentation areas.

The description of how artifacts are distributed along the table’s cell is achievedthrough the following parameters:

– distribution. It describes the policy to locate the set of anchors within the scopeof the policy. Options include together and detached. The together option placesall anchors together regardless of the associated task, whereas detached locatesanchors beside the related task.

– position. Regardless of whether the distribution is together or detached, anchorscan be on the top, bottom, left or right of the page or the related task.

– alignment. The previous parameters described the relationships among the portalpages, anchors and helping text, but the designer must make another decision: thedistribution of different functionalities shown in the same page. Will they be onebelow the other or one next to the other? In the former case, the functionalities seta column, and in the latter, they set a row of functionalities. Thus, the values of thisparameter are column and row.

– presentationDef. Another important decision in the appearance description willbe the look-and-feel of the portal. Here, again, we can have different perspectives

1 http://www.exoplatform.org/ ; http:/www.oracle.com/appserver/portal_home.html ;http://www.ibm.com/websphere/

State Style guidelines

Browsing

transition=both; distribution=detached; position=top; textPosition=top; presentationDef=free; alignment=row

PortalAppDescriptor {background=white; borderStyle=none; borderWidth=0px; borderColor=transparent}WindowAppDescriptor {borderStyle=solid; borderColor=orange; borderWidth=4px; background=white;

fontFamily=times; fontSize=12pt; fontStyle=normal; color=black; textAlign=justify;}AnchorAppDescriptor {borderStyle=solid; borderColor=black; borderWidth=5px; background=white;

fontFamily=arial; fontSize=14pt; fontStyle=italic; color=black; textAlign=justify;}

TextAppDescriptor {background=white; borderStyle=solid; borderWidth=1px; borderColor=red;

fontFamily=arial; color=red; fontSize=14pt; fontStyle=normal; textAlign=justify}

PaperSearchWindowAppDescriptor{alignment=column; borderStyle=dotted; borderColor=blue;}

AnchorAppDescriptor {borderStyle=dotted; borderWidth=7px}

IEEESearch WindowAppDescriptor {fontFamily=courier; fontSize=14pt}

AuthorSearch WindowAppDescriptor {alignment=column; position=bottom; }

ISIWok WindowAppDescriptor { fontFamily=arial; fontSize=16pt;}

Table 1. States and their presentation counterpart.

depending on the designer, the type of portal users, or the main aim of the portal.Thus, in some contexts, the objective could be that absolutely all the portal pageshad the same look-and-feel, in other contexts it could be enough that the style insidea page was coherent (e.g. all the anchors with the same color and font-type), but inthe same portal the style could change from one page to another (e.g. in one pageall the anchors are red, and in another, blue), and at last, in other contexts, perhaps,an unified style is not important or the designers would like to use different stylesto stress different points (e.g. assuming that in a portal page we can distinguish twotypes of anchors: global anchors, that appear in all pages, and local anchors, thatare specific to each page, the designer could specify that the global anchors must goin red and the others in green). So, this parameter has three possible values: portal,page, free.

These parameters determine the finale rendering of a page. But this does not mean thatthe designer has to set these parameters for each of the portal pages. Indeed, ensuringa common look-and-feel throughout the portal pages is one of the main concerns forthe portal designer to improve usability and the user experience. To this end, skinshave been proposed, i.e. templates defined at the portal level that set some presentationproperties and are then inherited from all the portal pages. Besides ensuring presentationhomogeneity, this mechanism accounts for maintainability as (some) changes in thepresentation uniquely involve updating the skin rather than modifying the distinct portalpages.

However, this mechanism can be too coarse grained, i.e. presentation is defined ateither the portal or the page level. There is nothing in between. For large portals wherepages can be grouped into clusters based on content or functional grounds, finer grainedskins could be most convenient.

Fig. 3. “Presentation configuration” counterpart of the state configuration {Browsing,Search, PaperSearch, IEEESearch, ACMSearch}

The idea is to use the statechart for this purpose. Both states and transitions willhave a presentation counterpart (see next subsection). Rather than attaching presentationparameters to pages, now these parameters are associated with states, and their scopeincludes all substates. That is, a parameter set for state S affects any widget associatedwith any substate directly or transitively below S. A parameter is overridden if newlydefined in a substate.

This approach offers a balance between the generality required to provide a commonlook-and-feel along the portal while at the same time addressing specificities of certaintasks or task clusters where presentation singularity is sought. Traditional skins corre-spond to presentation parameters defined for the upper state (e.g. Browsing) whereasit is still possible to completely override the skin for a particular atomic state (e.g.IEEESearch). Table 1 describes the presentation model complementary to our Browsingstatechart. In Table 1 we can see that at Browsing state level the designer has specifiedthat the font type and size for displaying portlet information will be Times and 12, but atthe IEEESearch state has redefined them, and she has decided that specifically the ieeeportlet will show its information in Courier font and 14pt. Moreover at Browsing statethe designer has defined that the anchors will be detached and they will be shown witha solid 5px border-line and in a italic font-style, by default. At the PaperSearch state,she has redefined the description and the anchors with origin in PaperSearch will beshown with a dotted 7px border-line. As we can see in figure 2 the presentation of thepage follows this specification. The states that are not in the table do not have a specificpresentation model, they inherit from their parente state.

Both models are independent, and using the same deskflow (statechart) it is possibleto describe different presentations. In our example, for the statechart in figure 1 the de-signer could have decided another presentation model; for example, in Browsing state:... distribution=together; alignment=column ... AnchorAppDescriptor{ ...fontStyle=normal;fontSize=12pt; borderStyle=solid; borderWidth=3px; ...} .... In this case, the first pageof the portal would have been as shown in figure 3. All anchors are together in the samerow, and in normal 12pt font with a thinner border-line than before.

4.2 From state configurations to presentation configurations: generating theportal pages

In order to get the presentation configurations (portal pages) from the state configura-tions, statecharts are extended with two mapping functions, namely:

– s2p is a function that maps from states to their presentation counterpart. Only basicand OR states are considered. Only basic states can be mapped to portlets2. In ourexample our six basic states (ISIWok, DeliciousStore, IEEESearch, ACMSearch,CiteSeerSearch, DBLPSearch) are mapped to six portlets: isi, delicious, ieee, acm,citeseer and dblp. AND states are not mapped into widgets, and its unique purposeis to express concurrency in statecharts. An AND state indicates that informationin widgets associated to its substates is to be shown simultaneously. This functionalso maps from transitions to anchors (the portal widget to perform the navigation).

– a2e is a function that associates anchors to statechart events that control the fir-ing of transitions. A statechart transition must have a unique event, although anevent may appear in multiple transitions. In this way, HMBS supports reuse of linkcomponents, as transitions and events may be reused to define anchors in differentnavigational contexts. An anchor within a page must be mapped into a transitionoriginating from one of the states of the state configuration associated to the page.In figure 1, for example, an anchor in the widget associated to state PaperSearchshould be mapped to the transition fired by 2AuthorSearch. We can see that anchorinside the black dotted box in Figure 2.

The statechart and the mappings are provided by the portal designer. From then on,presentation is handled by the portal engine as follows. When the user clicks on ananchor, the system performs the following actions:

1. Applies the a2e mapping to generate the event that causes the triggering of thetransition associated to that anchor.

2. Activates all states that are target sets for the transition fired, thus generating thenext state configuration and disabling the previous one. To this end, the executionsemantics of statecharts is used to describe the navigation of the portal. At a givenmoment, the system is in a certain configuration state. When an event happens, thesystem transmits it to the transition associated to the triggered event3. Then, the

2 Disclaimer: the portlets used in this paper were implemented as wrappers of third-party sites.They are used only for illustrative purposes, and not for commercial advantage.

3 The operational semantics of statecharts relies on a discrete time model that assumes thatsystem states have an associated duration, whereas transitions are instantaneous.

corresponding guard condition is evaluated, and if satisfied, the statechart sets thetarget state as active, which in turn, leads to a new state configuration.

3. Applies s2p to the new state configuration to obtain the next “presentation configu-ration”, i.e. a set of artifacts that should be simultaneously rendered to the user.

4. New “presentation configuration” is delivered to the user. This ends the cycle.

Fig. 4. “Presentation configuration” counterpart of the state configuration {Browsing,ISIWoK}.

Figures 2 and 4 depict the screen-shot counterparts of the 1 and 4 state configurationswhich correspond to our sample problem.

5 Related works

Our work is related to WebML (www.webml.org), a Web modeling language that con-templates the interplay between Web applications and Web services. Whereas WebMLconsiders the design of the Web application from scratch, our approach takes portletsas the starting point. Our intuition is that a component-based approach is more akin tothe notion of the portal as a doorway to other applications. Moreover, we hope that theuse of familiar models such as statecharts will facilitate the adoption of this approachin contrast with ad-hoc notations.

Pinheiro [12] explains that to develop abstract user interface descriptions the stan-dard UML facilities are enough. They use UML class diagrams to represent presentationmodels and UML activity diagrams for task models, and then, they use object flows in

activity diagrams to relate interaction objects (from the presentation model) to actionstates (from the activity diagram). The transitions in statecharts are triggered by eventsand not by the end of an activity as it happens in the activity diagrams. We see portalsas aggregations of portlets, and after using one portlet, the user is who decides to gothrough another one. He clicks in the portal, i.e. triggers events. So, for this reason, weconsider statechart mechanism more suitable for portal design. Moreover, besides thetask and trigger design, our approach considers the look-and-feel of the portal and thestate hierarchy helps the designer to define it in a modular and hierarchical manner.

Maamar [9] presents an approach for the design and development of service-drivenapplications: service chart diagrams are proposed as a specification technique. Thesediagrams are based on UML statecharts. With these diagrams a service is representedfrom five perspectives, one of them is the statechart. Another one is the information,which identifies the data exchanged between services. As we see, this is the most impor-tant contribution of that work and an aspect that we should consider to add in our state-chart diagrams, in order to represent the information exchange between two portlets.

In [4], we present our proposal to portlet aggregation, extending fragment markupof the portlet with semantic information. This set of data might be used by the designerof the portal to specify the mapping rules between the portlets she wants to pipe. Ourwork is complementary to this approach as we focus on the support of the portal as awhole. However, if we could make the portal aware of events coming from portlets then,statecharts could be expanded to contemplate also portlet events, besides those comingfrom the end user.

At last, Hong [8] proposes a DEVS modeling language called DEVS SpecificationLanguage (DEVSpecL) based on which discrete event systems are modeled, simulatedand analyzed. The DEVS formalism specifies a model in a hierarchical, modular form:it is a state transition graph. DEVSpecL is a set of rules to define messages, input/outputevents, conditions, etc. With DEVSpecL the designer can specify textually the DEVSmodels. After that, a model specification in DEVSpecL is translated into DEVSpecLAbstract Syntax Tree (AST) and AST is used to check ill-structured coupling relations.The advantage of our approach is that using UML statecharts we do not need any newformalism to make the verification, because there are tools that make the analysis ofstatecharts.

6 Conclusions

The recent release of the WSRP and JSR168 standards promises to achieve portlet in-teroperability. This will certainly fuel the transition from content syndication to portletsyndication. In this context, the ability to aggregate portlets will become crucial to im-prove the user experience.

This work proposes the use of extended statecharts (i.e. HMBS statecharts) to model“portlet-intensive” portals. The approach benefits from all the advantages brought bythe use of statecharts as well as improvements in the maintainability and modularity ofthe portal presentation.

Moreover we present a first approach for the design of this type of portals: (1) find-ing the tasks to show in the portal and then finding the portlets that will implement those

tasks; (2) defining the s2p mapping function (each portlet is related to a basic state) andthe deskflow (statechart) model (the designer decides the transitions between states, i.e.portlets); (3) describing the presentation model based on the navigation model. The de-signer is not concerned about the construction of portal pages, they will be generatedby the portal engine, based on the deskflow and presentation models and s2p mappingfunction. Details about the implementation of the process of portal page generation areout of the aim of this paper.

Acknowledgments. Maider Azanza enjoys a doctoral grant for the Basque Govern-ment under the "Young Researchers Program".

References

1. D. Berardi, D. Calvanese, G. de Giacomo, M. Lenzerini, and M. Mecella. Automatic com-position of e-services that export their behavior. In Proc. of the 1st International Conferenceon Service Oriented Computing (ICSOC 2003), Lecture Notes in Computer Science, pages43–58. Springer, 2003.

2. F. Casati and M. C. Shan. Dynamic and adaptive composition of e-services. InformationSystems, 26(3):143–163, May 2001.

3. O. Díaz and J.J. Rodríguez. Portlets as Web Components: an Introduc-tion. Journal of Universal Computer Science, 10(4):454–472, Apr 2004.http://www.jucs.org/jucs_10_4/portlets_as_web_components.

4. Oscar Díaz, Jon Iturrioz, and Arantza Irastorza. Improving portlet interoperability throughdeep annotation. In WWW ’05: Proceedings of the 14th international conference on WorldWide Web, pages 372–381, New York, NY, USA, 2005. ACM Press.

5. M.C. Ferreira de Oliveira, M.A. Santos Turine, and P.C. Masiero. A Statechart-Based Modelfor Hypermedia Applications. ACM Transactions on Information Systems, 19(1):28–52, Jan-uary 2001.

6. D. Harel and A. Naamad. The STATEMATE Semantics of Statecharts. ACM Transactionson Software Engineering and Methodology, 5(4):293–333, October 1996.

7. D. Harel, A. Pnueli, J.P. Schmidt, and R. Sherman. On the Formal Semantics of Statecharts.In 2nd IEEE Symposium on Logic in Computer Science, pages 54–64, 1987.

8. K.J. Hong and T.G. Kim. Devspecl: Devs specification language for modeling, simulationand analysis of discrete event systems. Information and Software Technology, 48(4):221–234, April 2006.

9. Z. Maamar, B. Benatallah, and W. Mansoor. Service Chart Diagrams - Description andApplication. In Proc. of the 12th International World Wide Web Conference (WWW2003),May 2003.

10. I. Manolescu, M. Brambilla, S. Ceri, S. Comai, and P. Fraternalli. Model-driven design anddeployment of service-enabled web applications. ACM Transactions on Internet Technology(ACM TOIT), 5(3):439–479, August 2005.

11. M. Paolucci, T. Kawamura, T. R. Payne, and K. Sycara. Semantic Matching of Web Ser-vices Capabilities. In 1st International Semantic Web Conference, pages 333–347. Springer-Verlag, June 2002.

12. P. Pinheiro da Silva and N.W. Paton. User interface modeling in UMLi. IEEE Software,20(4):62–69, Jul/Aug 2003.

13. E. Sirin, J. Hendler, and B. Parsia. Semi-automatic Composition of Web Services usingSemantic Descriptions. In 1st Workshop on Web Services: Modeling, Architecture and In-frastructure. In conjunction with ICEIS 2003, pages 17–24. ICEIS Press, April 2003.