Topological properties for characterizing well‐formedness of process components

Abstract

RHODES is an environment for modelling software processes, in which software processes are described by using a Process Modelling Language called PBOOL+. In this environment, a software process is built from PBOOL+ process components that can be reused to construct other processes. To identify well-formed process components, we study properties to be able to characterize topological structure of the components. These properties should relate intrinsically to cohesion of a component, and coupling between components. We will consider two classical properties that originated from graph theory, which are connection and transitive closure. These two properties are sometimes too strict to be applied, so we propose several weaker properties that are still useful for characterizing good components. The article aims to present these topological properties and their applications to reusable process components in context of the RHODES environment.

Software process modeling languages: A systematic literature review

“…To document processes in order to improve communication among people in real situations [49] To manage knowledge in a large software development organization [50] To provide a high-level representation to non-experts, so that it can be easy to use [24] To provide an adequate process representation that is vital for software organizations: understandable for people and formalized to avoid ambiguity [49] To define, verify and validate an organization's process [38] To create a formalism to represent and exchange software processes [21] To extend the abstraction level to improve model understandability and reduce model maintenance effort [38] To allow software process analysis and simulation [52] To control the human participation in software development activities [43,53] To support a more fine-grained behavior model and life cycle modeling [31] To model a process that integrates engineering and management practices [50] To exchange and subcontract results and components [50,52] To reuse software processes [24,37,55,56,58] To validate a process before enactment [15,16] To facilitate software process management automation [43,53] To apply the idea of software product lines to software processes [57] To include architectural concepts in software process modeling [14] To model controlled flexibility in software process [47] To deal with the increasing size and complexity of large systems of processes [32] To support software process tailoring to meet the specific goals and characteristics demanded by organizations and projects [45,46] Existing MDA tools are focused on code generation but other activities in a software process are usually not considered [44] To achieve integration of MBE into system and software process models [41] To support enactment by exploiting the full potenti...…”