S. Dami, J. Estublier, and M. Amiour. APEL: a Graphical Yet Executable Formalism for process Modeling. Automated Software Enginnering (ASE), D(2.9), 1997.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....instances of the metamodel classes and give values to its metafeatures. The PROMENADE approach to process modelling defines a universal or reference model (an instance of the PROMENADE metamodel) that constitutes the basis on which any other process model will be built (as done for instance in [DEA98]) Hence, this reference model is the common and extensible kernel shared by all processes modelled in PROMENADE. It is responsible for defining the core elements that will be a part of any model described in PROMENADE (e.g. the classes Task, Document and Model are defined by the reference ....

....as class instance features. Figure 1 shows the association relationships Feature Existing SPMLs PROMENADE Expressivity Pure reactive control flow (Adele [FKN94] basic behavioural features (Merlin [FKN94] Petri nets (SPADE [BFG94] imperative programs (APPL A [SHO95] transitions (APEL [DEA98]) goalorientation (Peace [ALO96] Different kinds of basic precedence relationships between tasks, ability to define derived precedences, dynamic precedences. Flexibility Several realizations for a single task [JH99] changes on the fly ( CLM95] KD96] goal oriented approaches ....

Dami, S.; Estublier, J.; Amiour, M.: APEL: a Graphical Yet Executable Formalism for Process Modeling. E. di Nitto, A. Fuggetta (eds.), Kluwer Academic Publishers (1998).

....extensively: events are the standard means of communication between di#erent business partners. Events are also used quite extensively in business modelling, especially in UML based approaches, for example [59] In academia, several WFMS research prototypes use event based workflow models (e.g. [30, 45, 77, 84, 85, 130]) often inspired by active databases [156] see Section 9.6) 9.5 Other workflow modelling languages There are several languages for modelling workflows, mostly informal ones. We here focus on languages that have some kind of execution semantics. Event driven process chains (EPCs) are part of ....

S. Dami, J. Estublier, and M. Amiour. Apel: A graphical yet executable formalism for process modeling. Automated Software Engineering, 5(1):61-- 96, 1998.

....Many workflow management systems and process centered environments incorporate facilities for specifying aspects of software agents, many of which may function in a distributed fashion. Examples include SPADE [21] Oz [22] ProcessWEAVER [23] ADELE TEMPO [24] Serendipity [3] and APEL [25]. Some systems, like ADELE and Oz, only provide textual, rule or event based languages for specifying software agent behavior. While these tend to be powerful and expressive, they give little high level overview of agent interaction and structure, and are very difficult for end users to ....

S. Dami, J. Estublier and M. Amiour, APEL: A Graphical Yet Executable Formalism for Process Modelling, Automated Software Engineering 5 (1998), 61-96.

....The process server interface allows 17 components to create any entity and to change the current process as well as the process model. This capability is the basis for evolution support. A common PSEE, which executes the common process model with respect to the common meta model semantics [27], and makes the common state evolve. The common PSEE ignores other PSEEs, which coordinate through the common state. The common process model includes a high level description of the functional aspects of the overall process, ignoring the operational aspects. An interoperability PSEE, which ....

S. Dami, J. Estublier, and M. Amiour, "APEL: a Graphical Yet Executable Formalism for Process Modeling". Kuwler Academic Publisher, pp. 60-96, Boston, January 1998.

No context found.

J. Estublier, S. Dami, and M. Amiour. "APEL: A Graphical yet Executable Formalism for Process Modeling". Automated Software Engineering, ASE journal. Vol. 5, Issue 1, 1998

.... layer provides concepts for the consistency of concurrent activities, for structuring the workspaces, and for defining and enforcing cooperative work policies which satisfy some consistency requirements (see Fig 2) A fourth layer, not presented here, deals with general process support; see [1] 5][6][19] 20] Software Configuration M anager X,Y X,Y Central repository W ork Spaces Applications Figure 1: Usual SCM Architecture An object is an instance of a class in which the content and the behavior of each instance is defined. An object contains attributes. Attribute domains can be ....

....It is no surprise to note that these extensions are proposed by ClearCase, the leading SCM product [17] 18] Pushing this initiative further could lead to propositions similar to those contained in this paper[8] Without surprise, SCM systems are those products coming closer to our reauirements. [6][14] 13] 11] 21] but SCM systems, generally, manage files rather than objects, they know a single representation (the file) and evolution constraints are missing or unclearly stated[7] 12] 8 CONCLUSION Object management in SCM sets a number of very hard constraints. Our experience shows that ....

S. Dami, J. Estublier and M. Amiour. "APEL: a Graphical Yet Executable Formalism for Process Modeling". Automated Software Engineering journal, January 1998.

....with, the same process manager, and that the federation mapping is flexible enough to impose almost no constraints on the interface and actual concepts of product and resource in their specific managers. Indeed, in our implementation, the process domain is implemented by the Apel Process Engine [6], where a product is defined as an atomic entity with a name (a string) a type (a string) and attributes. Our actual Product Manager defines a product as a potentially complex hierarchy of directory and files, having predefined (file system) and user defined attributes, which can be in turn ....

....and lightweight. Refinement and Extension are the mechanisms we have used to add state transition diagrams, collaboration, and interoperability with other process support systems in a fully transparent way; precisely the functionalities that were provided monolithically in the previous Apel system [6]. This new Apel System is about 10 times smaller and runs 10 times faster than previous Apel one (V4) not talking about complexity and maintainability. The process domain ignores the extensions and refinements and does not need them to work. In fact, we could easily contemplate a low cost entry ....

J. Estublier, S. Dami, and M. Amiour. "APEL: A graphical yet Executable Formalism for Process Modelling". Automated Software Engineering, ASE journal. Vol. 5, Issue 1, 1998.

....like software construction, both deterministic (product exchange) and non deterministic (message exchange) routing are needed. Most systems use either formal messages or non formal communication. We believe we need both. Over the last two years, we have built a process support system, APEL [5], in which the main process model which describes products and activities is independent from the communication model (describing messages) both deterministic and non deterministic, and formal communications can be modeled and supported. The description of coordination and collaboration aspects ....

....model which describes products and activities is independent from the communication model (describing messages) both deterministic and non deterministic, and formal communications can be modeled and supported. The description of coordination and collaboration aspects may be found in [1] and [5]. 2. Communication aspects Communication has been addressed in different fields of computer science. Middleware tools such as CORBA, RPC, BMS, OLE COM, etc. CSCW (groupware) 17] and workflow systems [18] The different facilities provided by those systems can be classified in the following ....

[Article contains additional citation context not shown here]

J. Estublier, S. Dami and M. Amiour. "APEL: a Graphical Yet Executable Formalism for Process Modeling". ASE journal. Vol. 5, Issue 1, 1998.

....the process model changing the values within an Universe in which are represented (as objects) the entities of the real world. Process technology takes provision for handling the discrepancies between the Universe state and the real world state, to handle non deterministic world evolution andsoon[2]. In our system, a process model describes the application behavior in term of the CU evolution. This model can be seen as a formal representation of the application goal. 3.3 Paradigm control As seen above, in the anarchic paradigm, there is no rule, no right, and no control. Tools perform ....

....We have developed an environment where high level models and graphical interfaces allows to design quite simply and rapidly a federation. Our platform, from these models, generate the code using transparently all the needed technology means (RMI, the JMS event server, the Apel process support [2], and so on) Our run time (the CCC, initiative controller, FCU, process engine and so on) ensures that everything, at execution, will perform as defined. Our federation support system is currently operational; after some preliminary validation cases[1] 5] we are in the process to install it in ....

J. Estublier, S. Dami, and M. Amiour. "APEL: A graphical yet Executable Formalism for Process Modelling". Automated Software Engineering,ASE journal. Vol. 5, Issue 1, 1998.

....related to software process. On the contrary, it should be more about developing an open software process support environment where different and heterogeneous components can cooperate and work together. Over the last 4 years we have developed a software process environment called APEL (V3) [11]. It differs from most existing systems in many ways: High level (graphical) yet executable (rich semantic) and wide scope (cooperative work support, configuration management, organizational aspects, etc. APEL V3 was also a monolithic environment which suffers from the limitations listed ....

....(high level and executable) but also provide a flexible, extensible and open software process support environment. For example, APEL V3 contained what are now the following independent components: Communication [2] which deals with the modeling and management of messages. Resource Management [11] which models and manages organizational aspects, including the company structure, resources allocation, constraints etc. Software Configuration Management [17] which aims at modeling and managing workspaces and collaboration strategies (concurrent data manipulation, versionning, etc. User ....

[Article contains additional citation context not shown here]

S. Dami, J. Estublier and M. Amiour. "APEL: a Graphical Yet Executable Formalism for Process Modeling", Kluwer Academic Publishers,Pages 60 - 91. Boston, January 1998.

....is a real critical issue. For us concurrent engineering control means: Merge control (what is to be merged, when. Activity structuring and control . High level policy modeling and enforcement. We will see shortly theses topics. For more info on activity structuring and control see [11][12] 15] 18] 1.1. Merge control The above values apply to files whereas, in this work and at Dassault Systmes, we deal with objects (files are atomic attributes in our object model) Our experience shows that concurrent changes to the same attribute of different objects (typically the source ....

J. Estublier, S. Dami, and M. Amiour. "APEL: A graphical yet Executable Formalism for Process Modelling". Automated Software Engineering, ASE journal. Vol. 5, Issue 1, 1998.

....capable of supporting enterprise application deployment. Our mid to long term purpose is of course to develop such an infrastructure. It will probably be based on an existing tool (an Installation Tool or an Application Management System) for physical (user) deployment support, the Apel tool [26] for enterprise deployment process modeling and support, and active repositories for storing the different models: application, organization, deployment, user site. The infrastructure will reflect the three layers of enterprise deployment. It will be made of three main components: a Producer ....

S. Dami, J. Estublier, M. Amiour. "APEL: a Graphical Yet Executable Formalism for Process Modeling.", Automated Software Enginnering (ASE), March 1997.

....The third layer provides concepts for concurrent activities consistency, for structuring the workspaces, and for defining and enforcing cooperative work policies which satisfy some consistency requirements. The fourth layer deals with general process support, and will not be developed here; see [1][4][7] 14] 15] 2.3 Concepts and definitions An object is an instance of a class in which is defined the content and the behavior of each instance. An object instance contains attributes. Attributes domains can be literals (i.e. strings, integers, file) or another object type; in the later case ....

S. Dami, J. Estublier and M. Amiour. "APEL: a Graphical Yet Executable Formalism for Process Modeling". Automated Software Engineering journal, January 1998.

....for further work on the topic. In particular, it presents a spec trum of possible architectures for interoperability, ranging from simple semantics free communication to integration. Finally it presents the interoperability environment APEL that has been built and experimented in Grenoble [13]. The rest of the paper is organized as follows. Section 2 defines some basic process terminology and what we mean by interoperability of PSSs. Section 3 introduces an example that demonstrates interoperability at the process level; the example is used throughout the paper to clarify ideas. ....

....achieved only if the common meta model is focussed enough (domain dependent) and high level enough (for real semantic interoperability) in order for most PSSs to agree on it and interoperate at high level. The definition of that Common Meta Model is a difficult task. In previous version (APEL V3 [13]) the meta model was formal and high level, but too wide, embedding, for example, concepts required only for SCM. Currently, SCM is an external and autonomous PSS, which allows other SCM systems to interoperate in the environment, using other concepts. This meta model is based on three entity ....

S. Dami, J. Estublier and M. Amiour. APEL: A Graphical yet Executable Formalism for Process Modelling. Automated Software Engineering Journal. Kluwer Academic Publisher. To appear.

....as the current state of the art in composition mechanisms. Workflow management sys tems (WfMC) evolved to deal with manufacturing and office processes. They typically identify concepts of tasks (activities) rules and procedures. They implement and execute tasks using heterogeneous applications [10,4,3]. Recently, workflow technology has been used to compose heterogeneous applications in order to build a new one (called global application in the following) 9,7,6] The approach is based on the two level programming paradigm: existing applications provide the core functionality and the ....

Dami, S., J. Estublier and M. Amiour, APEL: A Graphical Yet Executable Formalism for Process Modeling, ASE Journal (1998).

....the process model changing the values within an universe in which are represented (as objects) the entities of the real world. Process technology takes provision for handling the discrepancies between the universe state and the real world state, to handle non deterministic world evolution andsoon[1]. In our system, a process model describes the application behavior in term of the ACU evolution. This model can be seen as a formal representation of the application goal. 3.2 Paradigm control As seen above, in the anarchic paradigm, there is no rule, no right, and no control. Tools perform ....

....behavior and its characteristics, and (2) in mapping the abstract federation to the real tools. The control foundation proposes a set of tools whose mission is to facilitate federation design. The process paradigm is expressed in the Apel process modeling language (a set of graphical interfaces) [1]; the interoperability paradigm is handled by the right control tool, which is part of the component model,andbythe CCC design tool.Themulti model paradigm is handled by the CCC design tool, which associate ACU event with roles and by the role design tool which associates roles with proxies. ....

J. Estublier, S. Dami, and M. Amiour. "APEL: A graphical yet Executable Formalism for Process Modelling". Automated Software Engineering,ASE journal. Vol. 5, Issue 1, 1998.

....related to software process. On the contrary, it should be more about developing an open software process support environment where different and heterogeneous components can cooperate and work together. Over the last 4 years we have developed a software process environment called APEL (V3) [6]. It differs from most existing systems in many ways: High level (graphical) yet executable (rich semantics) and wide scope (cooperative work support, configuration management, organizational aspects, etc. In this version, a process is described in a rather monolithic model covering all the ....

....extensible and open software process support environment. For instance, the following components are now autonomous and can be integrated into the environment according to application needs: Communication [1] which deals with the modeling and management of messages. Resource Management [6] which models and manages organizational aspects, including the company structure, resources allocation, constraints etc. Software Configuration Management [8] which aims at modeling and managing workspaces and collaboration strategies (concurrent data manipulation, versionning, etc. User ....

[Article contains additional citation context not shown here]

S. Dami, J. Estublier and M. Amiour. "APEL: a Graphical Yet Executable Formalism for Process Modeling", Kluwer Academic Publishers,Pages 60 - 91. Boston, January 1998.

No context found.

S. Dami, J. Estublier and M. Amiour. "APEL: a Graphical Yet Executable Formalism for Process Modeling". Automated Software Engineering journal, January 1998.

No context found.

S. Dami, J. Estublier, and M. Amiour. APEL: a Graphical Yet Executable Formalism for process Modeling. Automated Software Enginnering (ASE), D(2.9), 1997.

No context found.

S. Dami, J. Estublier, and M. Amiour. APEL: a Graphical Yet Executable Formalism for process Modeling. Automated Software Enginnering (ASE), D(2.9), 1997.

No context found.

S. Dami, J. Estublier, and M. Amiour. APEL: a Graphical Yet Executable Formalism for process Modeling. Automated Software Enginnering (ASE), D(2.9), 1997.

No context found.

S. Dami, J. Estublier and M. Amiour. APEL: A Graphical yet Executable Formalism for Process Modeling. Kluwer Academic Publishers, Boston. Process Technology. Edited by E. Di Nitto and A. Fuggetta..Pages 61 - 97. January 1998.

No context found.

S. Dami, J. Estublier, and M. Amiour. APEL: A graphical yet executable formalism for process modelling. Automated Software Engineering, 5(1):61--96, January 1998.

No context found.

S. Dami, J. Estublier, and M. Amiour. APEL: a Graphical Yet Executable Formalism for process Modeling. Automated Software Enginnering (ASE), D(2.9), 1997.

No context found.

S. Dami, Jacky Estublier, and Mahfoud Amiour. Apel: a graphical yet executable formalism for process modeling. PIE Technical Report, January 1997.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC