Software process improvement requires high level formalisms for describing project-specific, organizational and quality aspects. These formalisms must be convenient not only for capture but also for execution purposes. In order to fulfill these requirements and to build a software process environment capable of supporting engineering tasks we have designed a new graphical, but still enactable, formalism called APEL (for Abstract Process Engine Language).APEL is very ambitious in the sense that it aims at covering a wide spectrum of needs and approaches expressed not only in the software engineering field but also in many others such as real-time systems, object-oriented methodologies, tool integration, CSCW, workflow and information systems. It is then not surprising to see that many concepts and techniques used in APEL are borrowed from these connected fields. A major outcome of the work presented here was to integrate a broad range of concepts and paradigms in a single and coherent framework, but on the basis of a minimal set of primitive concepts which makes it very easy to extend. Globally, the aspects which received most attention are: openness, reuse, scalability, human orientation and cooperative work.
Now applications are built from a collection of existing offthe-shelf (large) tools which interoperate with each other. Each one of the components may embody its own data and process management, often in an ad hoc way. The work presented here investigates a way to make different built-in process fragments, and general process engines (1) communicate and synchronize with each other; (2) behave in a consistent way; (3) appear to modelers and users as a single process support tool. We have addressed those issues about interoperability in developing an heterogeneous process engine built atop two commercially available tools: Process Weaver and Adele. The main objective was to build an Abstract Process Engine out of the two basic tools, which, without implying any change in their kernels, makes both the two interoperate in a peer-to-peer fashion and with respect to the three requirements stated above. The paper describes the major difficulties encountered in our experience doing this work, how they were overcome, as well as the lessons learned. Finally and in order to put this work in a broader context, an analysis of the current state of the art in the domain of Process Engine Interoperability will conclude the paper.Keywords: Software Process Technology, Process Support, Process Interoperability, Communication, Software Environments. MotivationsThe age of monolitic tools has gone. The hope of building an application just assembling procedures found in libraries has vanished. Now it is a matter of fact that applications are built from a collection of existing off-the-shelf tools using their API interfaces to interoperate with each other. These tools are large and even act as environments themselves presenting various differences at different levels (e.g., they use different languages, run on separate hardware/software platforms, communicate in a peer-based or/and server-client fashion, etc.). Examples span from text editors to programing environments through databases and graphical interfaces.In this context, researchers soon recognized that building applications over distributed architecture requires new concepts, techniques and skills. The difficulty comes from the fact each one of the overall system components embodies its own data and process management, often in an ad hoc way. The first topics seriously worked out were data interoperability, including work around database interoperability and, perhaps the most known standard, CORBA [OPR96]. CORBA ambition is to define a standard representation of all data, a common agreement on the way to transfer the information and to call services over heterogeneous architecture. The goal is to make possible for a component, developed independently, to be plugged in without disturbing the environment, and each component can make use of the data managed by the others.In the software process field, little work has been conducted in connection with tool/ process interoperability problem: different process fragments described in their native languages are destined to r...
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.