Taxonomy of Process Modeling Languages

The International Federation for Information Processing

Processes are very important for the success within many business fields. They define the proper application of methods, technologies, tools and company structures in order to reach business goals. Important processes to be defined are manufacturing processes or product development processes for example to guarantee the company's success. Over the last decades many process modeling languages have been developed to cover the needs of process modeling. Those modeling languages have several limitations, mainly they are still procedural and didn't follow the paradigm change to object oriented modeling and thus often lead to process models, which are difficult to maintain. In previous papers we have introduced PML, Process Modeling Language, and shown it's usage in process modeling. PML is derived from UML and hence fully object oriented and uses modern modeling techniques. It is based on process class diagrams that describe methods and resources for process modeling. In this paper the modeling language is described in more detail and new language elements will be introduced to develop the language to a generic usable process modeling language.

IEEE Computer Society, 1996

Software engineering environments have a history of about two decades. Early environments provided support for small fragments of the software process (usually focusing on programming-in-the small). Then there was a trend towards support for more complete software processes (from early phases like requirements analysis and design down to testing and configuration management). Ten years ago the notion of process-centered software engineering environments initiated a new field in software engineering: software process research. The key idea is to use a model of a software process as input parameter for a software engineering environment. The environment is supposed to "behave" in accordance to the process model. Some aspects of this vision became true, others turned out to be of little practicability. In this article, we discuss the history of software engineering environments with a particular focus on process-centered software engineering environments (PCSEEs). We discuss the notion of distributed software processes (as one of the most substantial current trends in software process research) and we motivate the notion of a software process middleware which serves as basis of real-world software processes spread over various sites. In addition, we discuss some other trends in the software process research arena.

… 6081, National Institute of Standards and …, 1997

Roundtable was to assemble key champions and stakeholders of various approaches towards process representation in order to discuss the relative merits to reach consensus on a language architecture and to establish a technical approach for proceeding. It was agreed that the language architecture should be based upon a formal semantic foundation, upon which would be layered a number of syntactic mappings, each with one or more presentations. In discussions about principal concepts of any process representation ...

ACM SIGSOFT Software Engineering Notes, 1994

The basic idea behind a Process-Centered Software Engineering Envkonment (PSEE) is that, in addition to storing information about the products produced and used in a software life cycle, it is also important to explicate and store information regarding the process by which those work products are produced and used-indeed, these processes are at the heart of the system. The information about such processes can be used to: (1) tailor the environment to the needs of different processes, (2) provide automation support for appropriate aspects of the process, (3) provide guidance in terms of the ordering of software activities, and (4) help in continuous process improvement.

2000

This document describes Version 1.0 of the Process Specification Language (PSL). PSL is an interchange format designed to help exchange process information automatically among a wide variety of manufacturing applications such as process modeling, process planning, scheduling, simulation, workflow, project management, and business process re-engineering tools. These tools would interoperate by translating between their native format and PSL. Then, any system would be able to automatically exchange process information with any other system via PSL.

1996

Software engineering environments have a history of about two decades. Early environments provided support for small fragments of the software process (usually focusing on programming-in-the small). Then there was a trend towards support for more complete software processes (from early phases like requirements analysis and design down to testing and configuration management). Ten years ago the notion of process-centered software engineering environments initiated a new field in software engineering: software process research. The key idea is to use a model of a software process as input parameter for a software engineering environment. The environment is supposed to "behave" in accordance to the process model. Some aspects of this vision became true, others turned out to be of little practicability. In this article, we discuss the history of software engineering environments with a particular focus on process-centered software engineering environments (PCSEEs). We discuss the notion of distributed software processes (as one of the most substantial current trends in software process research) and we motivate the notion of a software process middleware which serves as basis of real-world software processes spread over various sites. In addition, we discuss some other trends in the software process research arena.

Information Sciences, 1995

This pap.er discusses the evolution of "programming in the large" environments and presents major innovations in software product structuring, configuration management, and software process integration. The main evolutions that are highlighted show the efforts toward integration, generalization, and modelization in order to achieve a formal description of the software process. We analyze current tendencies from the point of view of both support for resource management and software process. Focussing on the product we illustrate, using examples, the main efforts required to manage the resources involved in a software process. We show the earliest efforts to produce formal representations, applying data modeling concepts to integrate version and configuration management systems using software engineering databases. Turning to the process side of the question, we highlight recent work developing formal method to describe the process model. We conclude by presenting the Adele project, a process software engineering environment (PSEE) that achieves combined resources management (description of resources and product to be consumed and produced by the execution of activities and software process).

A recent trend in software engineering is the shift from a focus on laboratory-oriented software engineering to a more industry-oriented view of software engineering processes. This complements preceding ideas about software engineering in terms of organization and process-orientation. From the domain coverage point of view, many of the existing software engineering approaches have mainly concentrated on the technical aspects of software development. Important areas of software engineering, such as the technical and organizational infrastructures, have been left untouched. As software systems increase in scales, issues of complexity and professional practices become involved. Software development as an academic or laboratory activity, has to engage with software development as a key industrialized process.

Universidad de los Andes, 2007

This paper presents the use of Domain-Specific Modeling (DSM) technologies to tackle the complexity associated to the definition and improvement of software process models. This complexity arises because these tasks involve the description of different activities as well as the relationships with other processes. In this work, we propose the use of viewpoint models to represent, in a modular and non-intrusive way, concerns expressed on a software process model. We developed a Domain-Specific Aspect Language, called AspectViewpoint, to create viewpoint models using a vocabulary based on the workflow control patterns.

Introduction: Software engineering goes through a series of passages that account for their inception, initial development, productive operation, upkeep, and retirement from one generation to another. This article categorizes and examines a number of methods for describing or modelling how software systems are developed. It begins with background and definitions of traditional software life cycle models that dominate most textbook discussions and current software development practices. This is followed by a more comprehensive review of the alternative models of software evolution that are of current use as the basis for organizing software engineering projects and technologies. Background: These classic software life cycle models usually include some version or subset of the following activities: System Planning: New feasible systems replace or supplement existing information processing mechanisms whether they were previously automated, manual. Requirement Analysis: Identifies the problems a new software system is suppose to solve, its operational capabilities, its desired performance characteristics, and the resource infrastructure needed to support system operation and maintenance. Prototyping: Identifies and potentially formalizes the objects of computation, their attributes and relationships, the operations that transform these objects, the constraints that restrict system behavior, and so forth. Architectural Design: Defines the interconnection and resource interfaces between system subsystems, components, and modules in ways suitable for their detailed design and overall configuration management. Component Implementation and Debugging: Codifies the preceding specifications into operational source code implementations and validates their basic operation. Software Integration and Testing: Affirms and sustains the overall integrity of the software system architectural configuration through verifying the consistency and completeness of implemented modules, verifying the resource interfaces and interconnections against their specifications, and validating the performance of the system and subsystems against their requirements. Documentation and Delivery: packaging and rationalizing recorded system development descriptions into systematic documents and user guides, all in a form suitable for dissemination and system support. Deployment and Installation: providing directions for installing the delivered software into the local computing environment, configuring operating systems parameters and user access privileges, and running diagnostic test cases to assure the viability of basic system operation. Software Maintenance: sustaining the useful operation of a system in its target environment by providing requested functional enhancements, repairs, performance.

Lecture Notes in Business Information Processing, 2012

Streams of research are emerging that emphasize the advantages of using declarative process modeling languages over more traditional, imperative approaches. In particular, the declarative modeling approach is known for its ability to cope with the limited flexibility of the imperative approach. However, there is still not much empirical insight into the actual strengths and the applicability of each modeling paradigm. In this paper, we investigate in an experimental setting if either the imperative or the declarative process modeling approach is superior with respect to process model understanding. Even when task types are considered that should better match one or the other, our study finds that imperative process modeling languages appear to be connected with better understanding.

Advanced Information Systems Engineering, 2006

The increasing interest in process engineering and application integration has resulted in the appearance of various new process modelling languages. Understanding and comparing such languages has therefore become a major problem in information systems research and development. We suggest a framework to solve this problem involving several instruments: a general process meta-model with a table, an analysis of the event concept, and a classification of concepts according to the interrogative pronouns: what, how, why, ...

Proceedings of IMECE: International Mechanical …, 1999

In all types of communication, the ability to share information is often hindered because the meaning of information can be drastically affected by the context in which it is viewed and interpreted. This is especially true in manufacturing because of the growing complexity of manufacturing information and the increasing need to exchange this information among various software applications. Different manufacturing functions may use different terms to mean the exact same concept or use the exact same term to mean very different concepts. Often, the loosely defined natural language definitions associated with the terms contain so much ambiguity that they do not make the differences evident and/or do not provide enough information to resolve the differences.

Introduction Software systems come and go through a series of passages that account for their inception, initial development, productive operation, upkeep, and retirement from one generation to another. This article categorizes and examines a number of methods for describing or modeling how software systems are developed. It begins with background and definitions of traditional software life cycle models that dominate most textbook discussions and current software development practices. This is followed by a more comprehensive review of the alternative models of software evolution that are of current use as the basis for organizing software engineering projects and technologies.

2009

It is known that different process models are used during various phases of the Business Process Modeling (BPM) life cycle. Many efforts have been introduced to overcome the disintegration between these process models to provide a standard process model for design and execution. However this integration is still a problem that mazes the researches in this field till now. This paper discusses the problem of translation between process models, which known as the conceptual mismatch. Different perspectives are described considering the case of Business Process Modeling Notation (BPMN) vs. Business Process Execution Language (BPEL).