| Kaiser, G. E. et al., 1993. A Bi-Level Language for Software Process Modeling. 15th International Conference on Software Engineering, Baltimore, MY, pp. 132-143. |
....plans that cause the pre condition of an action to be satisfied so that it can be executed. Dynamic plans take into consideration actual state of a project and can thus describes a broader range of possible alternative unfoldings than is usually possible in purely prescriptive, topological models [35]. Operations can therefore be read as goals that users want to achieve, perhaps in many steps, if necessary. Once the necessary preceding actions are identified, forward chaining causes their automatic execution, if possible; non automatic actions are directed to the user. While backward ....
G. Kaiser, S. Popovich, I. Ben-Shaul, A bi-level language for software process modeling, in: W. Tichy (Ed.), Trends in Software, Vol. Configuration Management issue, John Wiley & Sons, 1994, Ch. 2, pp. 39--72.
....instance, organizations and products are modeled using different languages. Again, the rationale is not to freeze into the core PIL those concepts that can change from process to process. In this class we have EPOS. This might be considered a generalization of the bi level approach advocated in [47]. Clearly, this strategy introduces the critical issue of how to manage the interoperation among different languages [56] More in general, according to our experience, the features that have to be offered by a PIL are the following ones: 1. Modeling of concurrent activities. This requirement ....
G. Kaiser, S. Popovich, I.Z. Ben-Shaul. A bi-level language for software process modeling. In Proceedings of 15th International Conference on Software Engineering (ICSE 15). IEEE Computer Society, Baltimore (USA), 1993.
....instance, organizations and products are modeled using different languages. Again, the rationale is not to freeze into the core PIL those concepts that can change from process to process. In this class, we have EPOS. This might be considered a generalization of the bilevel approach advocated by Kaiser et al. 1993]. Clearly, this strategy introduces the critical issue of how to manage the interoperation among different languages [Montangero 1995] According to our experience, the features that must be offered by a PIL are as follows: 1) Modeling of concurrent activities: This requirement derives from the ....
KAISER, G., POPOVICH, S., AND BEN-SHAUL, I. Z. 1993. A bi-level language for software process modeling. In Proceedings of 15th International Conference on Software Engineering (ICSE 15) (Baltimore, Md.). IEEE Computer Society, Washington, D.C.
....process modelling and enactment: in the former the order in which activities (or processes) have to be enacted is specified explicitly, whereas in the latter this order is only specified implicitly by the pre given goals which have to be satisfied when the process model is enacted. Similar to ASL [17], PM MetaFrame realizes a mixed approach as proposed in [3] since the use of the temporal logic SLTL (Semantic Linear time Temporal Logic) allows specifications ranging from extremely concrete descriptions, which fix every detail of the final PM, to abstract safety and liveness properties, which ....
....descriptions, which fix every detail of the final PM, to abstract safety and liveness properties, which exclude only a few bad cases. Several PM environments 3 support the description of global aspects of process models within a construction oriented approach: ALF (MASP) 22] MARVEL (ASL) [17], PEACE [2] Oikos (ESP) 1] Merlin [23] DYNAMITE (Task Nets) 14] SPADE (SLANG) 4] and EPOS (SPELL) 15] use only limited forms of global constraints to specify ordering constraints for software process activities, but are not able to specify more abstract properties. In particular, they do ....
G. Kaiser, S. Popovich, I. Ben-Shaul: "A Bi-Level Language for Software Process Modeling", Proc. ICSE'93, 1993, pp. 132-143.
....preserve the precious commodity. Process based selection addresses the problems encountered with manual and heuristic selection. However, the process based approach is not as simple as it sounds. Practical industrial scale processes are complex, with numerous opportunities for choice or iteration [10]. Since each rule may have conditions which lead to backward chaining and effects which lead to forward chaining, we can construct a graph of a portion of the process, showing the relationships amongst specific rules. Expanding the graph to show the transitive closure of consequences emanating ....
Gail E. Kaiser, Steven S. Popovich, and Israel Z. Ben-Shaul. A Bi-Level Language for Software Process Modeling. In 15th International Conference on Software Engineering, pages 132--143, Baltimore MD, May 1993. IEEE Computer Society Press.
.... blocks have at most a syntactic presentation, but their semantic definition is given either informally or in the same language: as a consequence it is difficult to keep the necessary distinction between the global goals of a model fragment, and the local constraints, as advocated for instance in [18]. We support this attitude, that we consider one of the ways to reach a good understandability of process models. Indeed, this is one of the goals of our work in SPT, as already mentioned in the introduction. In a programming view based on refinements, this decoupling is obtained by using two ....
G.E. Kaiser, S.S. Popovich, and I.Z. Ben-Shaul. A Bi-Level Language for Software Process Modeling. In Proc. 15th International Conference on Software Engineering, pages 132--143, Baltimore, Mariland, May 1993.
....one developer to another informing the new developer of work needing to be done. For example, after checking in a module into the configuration library, an automatic prompt could inform testing personnel that a new module needs to be incorporated into the latest build of the system. MARVEL [8] [9] [10] is an example of an enforcement oriented process centered software engineering environment. The MARVEL environment uses strategies which are predefined by the process engineer. A strategy consists of an objectbase description, tool descriptions, and or rules that model the software ....
Kaiser, G.E., A bi-level language for software process modeling. ACM/IEEE 15 th International Conf. on Soft. Eng., Baltimore, MD (May, 1993), 132-142.
....UC, NDWg ] The following relations hold: ISPW7 0 Delta ISPW7 0:1 Delta ISPW7 1 and we have a new refined top level specification of the process. So, the refinement hierarchy is a natural support for the distinction between global and local properties, as advocated, among others, by Kaiser in [25]. 3.4. Heterogeneous refinement According to the method proposed in section 2, we introduce a rule fulfilling a goal and guaranteeing safety. A rule is composed of: a name; a guard, specifying atoms to be read or consumed from the tuple space; a commit operator j ; a tell part, specifying ....
G. Kaiser, S. Popovich, and I. Ben-Shaul. A Bi-Level Language for Software Process Modeling. In Proc. 15 th ICSE, pages 132--143, Baltimore, Maryland, May 1993.
....of a software process. This paper is focused on the design of processprograms and therefore existing PSDEs are examined under its support for a user friendly representation of the process. Marvel [BK90] uses a rule based language for process modeling. The recently developed language ASL [KPBS93] is an extension of MSL [EFP88] and combines the specification of local constraints on individual tools and data with the specification of global control flow and synchronization. A main disadvantage of MSL, using post conditions to specify how an activity on one object might influence all ....
Gail E. Kaiser, Steven S. Popovich, and Israel Z. Ben-Shaul. A Bi-Level Language for Software Process Modeling. In Proceedings of the 15 th International Conference on Software Engineering, pages 132--143, Baltimore, Maryland, May 1993. IEEE Press.
....also on organizational, methodological, and technological support. Second, first generation languages generally have obvious limitations. This is in part because many of these languages were based on existing paradigms that were not particularly well adapted to the domain of software process [9, 22, 31, 24, 13, 4, 23]. Finally, research in other areas of software process has affected our ideas about what can and should be done with process languages. In this paper we report on the design of a next generation process language that is intended to capitalize on lessons learned from first generation languages, ....
G. E. Kaiser, S. S. Popovich, and I. Z. Ben-Shaul. A bi-level language for software process modeling. In W. F. Tichy, editor, Configuration Management, number 2 in Trends in Software, chapter 2, pages 39--72. John Wiley & Sons, 1994.
....the precious commodity. Process based selection addresses the problems encountered with manual and heuristic selection. However, the process based approach is not as simple as it sounds. Practical industrial scale processes are complex, with numerous opportunities for choice or iteration [10]. Since each rule may have conditions which lead to backward chaining and effects which lead to forward chaining, we can construct a graph of a portion of the process, showing the relationships amongst specific rules. Expanding the graph to show the transitive closure of consequences emanating ....
Gail E. Kaiser, Steven S. Popovich, and Israel Z. Ben-Shaul. A Bi-Level Language for Software Process Modeling. In 15th International Conference on Software Engineering, pages 132--143, Baltimore MD, May 1993. IEEE Computer Society Press.
....mrsolve mr.name (28) mr.status = solved) 29) 425) The rule declaration models the creation of a code solution for an individual modification request, after which the status of the modification request changes from open to solved. 426) Recently, the Activity Structures Language (ASL) [50] has been implemented in the context of Marvel. ASL is a variant of Riddle s constraint expressions that enables to model process model topology by means of regular expressions extended with concurrency operators. ASL fragments can be translated into MSL ones. 3.5.3 Process Weaver (427) Process ....
G.E.Kaiser, S.S. Popovich, and I.Z.Ben-Shaul. A Bi-Level Language for Software Process Modeling. In Configuration Management, Ed. by Tichy, John Wiley and Sons Ltd 1994.
....model, rather than implementing a completely new process engine for each approach, as well as possibly improving the process visualization capabilities of the environment s user interface compared to that afforded by the process assembly language. The third goal is discussed in other papers [21, 13]. This paper focuses on the first and second goals, particularly with respect to exploiting the process engine extension parameterization facilities to support integration of the process server component with separately produced process centered environments. Our preliminary formulations of these ....
....modeling process topology, the big picture of concern to managers and other non technical users, whereas Amber is optimized for individual task constraints and the detailed definition of enactment options with respect to individual rules and rule chains. We elaborate on this dichotomy elsewhere [21], but suffice to say here that including both complementary aspects in the same process centered environment seems quite valuable. Another motivation for integrating Amber and TeamWare would be for the latter to exploit Amber s more powerful execution facilities (e.g. both goal driven and ....
Gail E. Kaiser, Steven S. Popovich, and Israel Z. Ben-Shaul. A bi-level language for software process modeling. In Walter F. Tichy, editor, Configuration Management, number 2 in Trends in Software, chapter 2, pages 39--72. John Wiley & Sons, 1994.
....the users in carrying out the finer details of such tasks, e.g. editing, compiling, constructing test harnesses, and debugging would be separate steps triggered by the code and test task. We have explored elsewhere the advantages of integrating higher level and lower level process definitions [37]. We assume here that the controlled PCE is itself designed and implemented as a multi user system, e.g. following a client server architecture as in Oz, to allow teamwork within each coarse grained step as determined by the finer grained process. The two PCEs may or may not be distinct ....
....workflow system. This could potentially address a certain limitation of Oz as a PCE, namely that relationships among tasks within a process are formed only with respect to satisfying local constraints, the task prerequisites and obligations, and there is no global topology or grand view [37]. However, that grand view could feasibly be defined by the meta process, by directing the workflow among abstract or at least aggregate tasks, while each MTP invoked process itself directs only the workflow among concrete, perhaps primitive tasks, effectively filling in the details left out of ....
Gail E. Kaiser, Steven S. Popovich, and Israel Z. Ben-Shaul. A bi-level language for software process modeling. In Walter F. Tichy, editor, Configuration Management, number 2 in Trends in Software, chapter 2, pages 39--72. John Wiley & Sons, 1994.
.... it is hoped that the language level can be addressed by translating various PMLs to an underlying assembly PML, similar to the approach taken in some Heterogenous Distributed Data Bases (HDDBs) e.g. 66] In fact, some evidence that this approach is feasible was given by the work described in [60]. Furthermore, in investigating architectural support for decentralization, some level of system heterogeneity, namely componentization, is considered and is one of its guidelines (see Chapter 5) Nevertheless, multi PML support and componentization are, by and large, guidelines (and constraints) ....
....between steps in a process can be implicitly formed by matching predicates in the condition of one rule and an effect of another rule, and the enactment engine enforces and or automates the sequencing. However, the process is not in any sense limited to a deterministic sequence of steps. See [60] for discussion of the specification of alternatives, iteration and synchronization through the conditions and effects of rules. 2.2.3 Process Enactment Enactment is provided in Marvel by chaining. Forward and backward chaining over the rules enforces consistency in the objectbase and automates ....
[Article contains additional citation context not shown here]
Gail E. Kaiser, Steven S. Popovich, and Israel Z. Ben-Shaul. A bi-level language for software process modeling. In 15th International Conference on Software Engineering, pages 132--143, Baltimore MD, May 1993. IEEE Computer Society Press.
....Strategy This section explains how we translated ProcessWeaver Petri nets into rules that the Amber process server could execute. The general idea that we followed, similar to the translation for activity structures (a process formalism based on regular expressions) in our earlier work on ASL [15], was to reify each Petri net definition as a class definition in Amber, and each instance as an object in Amber s objectbase containing the Petri net s state information. Each transition produced a rule, defined on the appropriate Petri net class. Thus, each cooperative procedure file processed ....
.... process formalisms to a single process assembly language , and in particular to our idea that this language should be rule based [19, 14] It confirms, in this way, the results of our previous experiments using Marvel as a rule based process engine for the ASL bi level process modeling language [15] and for StateMate finite state machines [8] While implementing the translation, we found and corrected one substantial design flaw in the Amber language its support for only one (parallel breadth first) chaining order. Amber now has support for depth first, sequential breadth first and ....
Gail E. Kaiser, Steven S. Popovich and Israel Z. Ben-Shaul. A Bi-Level Language for Software Process Modeling. In Walter F. Tichy (editor), Trends in Software. Number 2: Configuration Management, chapter 2, pages 39-72. John Wiley & Sons, 1994.
....that prerequisites imposed by the process step enclosing the activity are satisfied locally; this may be regarded as internal constraints. 2) Verification that the activity can be executed with respect to the overall task workflow; this may be regarded as external constraints (see [31] for more on this distinction) 3) Active invocation of related activities, e.g. to satisfy (1) and (2) And (4) Deriving and binding data arguments that are required by the activity but were not specified as parameters. Note that Pre Summit requires that all involved SubEnvs identify the same ....
.... end (what Heimbigner calls a prescriptive process [22] to sentence recognition (parsing) at the other (proscriptive) 29] The PDL project employed the former for context free grammars [28] while the implementation of the Activity Structures Language on top of Marvel follows the latter approach [31]. One group experimented with both in the context of attribute grammars for HFSP [32] and Objective Attribute Grammars [47] respectively. Considering the grammar based PMLs, a terminal symbol corresponds to an activity in our context hierarchy, a non terminal symbol to a task, and a production ....
Gail E. Kaiser, Steven S. Popovich, and Israel Z. Ben-Shaul. A bi-level language for software process modeling. In Walter F. Tichy, editor, Configuration Management, number 2 in Trends in Software, chapter 2, pages 39--72. John Wiley & Sons, 1994.
....chaining. It is important to understand that only automation chaining is optional; users are still obliged to follow some legal process step sequence implied by the conditions and effects of rules, whether through manual selection of commands or automation chaining. We discuss in another paper [19] the specification of alternatives, iteration and synchronization through the conditions and effects of rules; the process is not in any sense limited to a deterministic sequence of steps. Possible chains are compiled into a network when the kernel is tailored [18] The process engine chains among ....
Gail E. Kaiser, Steven S. Popovich and Israel Z. Ben-Shaul. A Bi-Level Language for Software Process Modeling. Technical Report CUCS-016-92, Columbia University Department of Computer Science, September, 1992. Submitted for publication.
....process(es) effecting a form of hierarchical workflow system. This could potentially address a certain limitation in Marvel, shared by Oz, that relationships among tasks within a process are formed only with respect to satisfying local constraints, and there is no global topology or grand view [20]. However, that grand view could feasibly be defined by the meta process, by directing the workflow among the entry points of aggregate tasks, while the process itself directs only the workflow among primitive tasks. Further discussion of this idea is outside the scope of this paper. 32 ....
Gail E. Kaiser, Steven S. Popovich, and Israel Z. Ben-Shaul. A bi-level language for software process modeling. In Walter F. Tichy, editor, Configuration Management, number 2 in Trends in Software, chapter 2, pages 39--72. John Wiley & Sons, 1994.
....sense of multiple independent processes but a single PML in which they are defined, as well as multiple schemas but a single data definition language. This is in contrast to ProcessWall [15] where multiple formalisms can be used to define a single process, or to the Activity Structures Language [19], where high and low level modeling formalisms are combined into one. 3. Data Sharing and Presentation A DEPCE should provide non transparent, but nevertheless efficient and highly available data access capabilities. In particular, SubEnvs should be able to access and browse through data ....
Gail E. Kaiser, Steven S. Popovich, and Israel Z. BenShaul. A bi-level language for software process modeling. In 15th International Conference on Software Engineering, pages 132--143, May 1993.
....understood only by Oz servers. So difficulties arise only when pending tasks posted through the Foundation involve non Oz SubEnvs. Fortuitously, we have already shown fairly straightforward mappings from most of the major PCE paradigms, including Petri nets [55] task graphs [25] and grammars [39], into Oz rules, and reverse mappings are not inconceivable. And as previously noted in Section 1, Mentor supports translation from one notation into another, as does the process interchange format standardization effort. However, the general case requires substantial translation capabilities ....
Gail E. Kaiser, Steven S. Popovich, and Israel Z. Ben-Shaul. A bi-level language for software process modeling. In Walter F. Tichy, editor, Configuration Management, number 2 in Trends in Software, chapter 2, pages 39--72. John Wiley & Sons, 1994. ftp://ftp.psl.cs.columbia.edu/pub/psl/CUCS-01692. ps.Z.
....with an external task scheduling mechanism [24] The second approach is based on layers, with translators from higher to lower levels and a process assembly language at the bottom. We have begun investigation of the former approach, see [7] and studied the latter extensively as described in [26, 14, 19]. While enhancing the level of abstraction and potentially realizing the various enactment models intended for the different languages, the multi lingual approach is ultimately still dependent on the capabilities of the underlying interpreter (and or the assembly language) in the layered case, or ....
....But there is no roadmap , the user has to know what to do next. Only simple single user processes can easily be written as one long forward chain, where the user is told what to do next, although we describe two different experimental extensions that would support this for multiple users in [19, 8]. Amber Oz, and the original Oz, provide powerful execution facilities (e.g. both goal driven and eventdriven automation) and sophisticated multi user contextswitching support (with collaborative concurrency control policies achieved through the mediator interface to an external transaction ....
G. E. Kaiser, S. S. Popovich, and I. Z. Ben-Shaul. A bi-level language for software process modeling. In W. F. Tichy, editor, Configuration Management, number 2 in Trends in Software, chapter 2, pages 39--72. John Wiley & Sons, 1994.
....understood only by Oz servers. So difficulties arise only when pending tasks posted through the Foundation involve non Oz SubEnvs. Fortuitously, we have already shown fairly straightforward mappings from most of the major PCE paradigms, including Petri nets [53] task graphs [26] and grammars [38], into Oz rules, and reverse mappings are not inconceivable. And as previously noted, Mentor involves translation from one notation into another, as does the standard process interchange format work. However, in the general case we also require substantial translation capabilities regarding both ....
Gail E. Kaiser, Steven S. Popovich, and Israel Z. Ben-Shaul. A bi-level language for software process modeling. In Walter F. Tichy, editor, Configuration Management, number 2 in Trends in Software, chapter 2, pages 39--72. John Wiley & Sons, 1994.
No context found.
Kaiser, G. E. et al., 1993. A Bi-Level Language for Software Process Modeling. 15th International Conference on Software Engineering, Baltimore, MY, pp. 132-143.
No context found.
G. E. Kaiser, S. S. Popovich, and I. Z. Ben-Shaul, "A Bi-Level Language for Software Process Modeling," Proc. Fifteenth International Conference on Software Engineering, Baltimore, Maryland, 1993.
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