Process Modeling Paradigms: An Evaluation Reidar Conradi, Chunnian Liu, Maria Letizia Jaccheri Norwegian Institute of Technology (NTH), Trondheim, Norway.
Position paper at 7th Int'l Software Process Workshop (ISPW7), Yountville, Ca, USA
4. Customization and evolution of the process model, i.e. basic activation rules, guiding policies, tools, roles etc. This is needed to avoid strait-jacketing e ects. Variability and project customization may be achieved either by subtyping or metaprogramming techniques such as re ection. 5. Multi-actor, distributed environment. E.g. cooperative transactions must be modeled to cope with general change propagation. 6. Integration with a versioned DBMS and its surrounding CM system, i.e. CM + PM. That is, CM needs PM to express changes on evolving products, while the PM information itself is an evolving \product".
A software process is the set of software engineering activities needed to transform a user's requirements into functioning software. A Semantic Data/Process Model (or Process Architecture) is a framework to incorporate generic process models, i.e. de nitions, structures, standards, and relationships of the various process elements so that common technology, methods and measurements can be applied by any software project. A projectspeci c software process model (e.g. waterfall, spiral, and iterative enhancement models) is a re nement of the generic model to re ect the particular needs of the project. This again can be instantiated to an executable process (with subprocesses) to develop a particular software. Thus we have the following bindings: underlying semantic model ! generic process model ! project-speci c process model ! concrete process(es). A Software Process Management (PM) environment should enact and control development activities semi-automatically and concurrently. The following six themes seem to us the most interesting for clarify and assess existing PM systems and paradigms:
In the following, we summarize and compare ve di erent software process modeling paradigms and associated PM systems. The paradigms are: active databases (DBs), AI rules, task nets, process programming, and hybrids. In Figure 1 we sum up the paradigms and PM systems.
1. Basic PM apparatus and its enaction and reasoning mechanism. 2. Coverage of software life-cycle and process entities: Software Products, Software Development Activities (tasks), Tools, and Humans (roles). 3. Structuring Mechanisms for the process model, e.g. by project-level aggregation of process types or sub-models. Detailed address: Div. of Computer Systems and Telematics, N-7034 Trondheim-NTH, Norway. Email:
[email protected], Fax: +47 7 594466, Phone: +47 7 593444.
1
The Active DB Paradigm is based on
DBMS embedding Event-Condition-Action (ECA) rules which model the software development activities. An active DBMS is a preliminary PM system aimed at short transactions and low-level (programming) task. Versioned DB support and CM coupling depend on the capacity of the underlying DBMS. Project customization depends on the rule structuring. In Adele the programmable triggers are around normal DB operations, being described in object or relationship types. This models the software development activities and controls change propagation within one
con guration. The types are clustered in project-speci c partitions, which o er dynamic binding. AI rule-based systems exploit planning techniques or blackboard architectures both in process modeling and in interpretation of the models. Project customization can be done by rule grouping (subproject environments), change can be dealt with by re-planning and re-execution. Rule structuring except from simple grouping is dicult, and AI techniques have to be extended to support cooperative transactions, DB versioning or CM coupling. MARVEL is a simple rule-based system providing forward and backward (sequential) chaining of menial software development activities. Project customization is done by user selected strategy { a subset of the rules. It has only simple, non-versioned DBMS support, hence no coupling with any CM systems. OIKOS uses a hierarchy of blackboards to model and enact software process. The mechanism is non-deterministic, concurrent and distributed. ALF proposes a formal, generic process model MASP which can be customized into any projectspeci c process IMASP by adapting MASP to project-speci c requirements (parameterization). ALF aims at comprehensive process modeling and taking a knowledge-based approach. The Graph/Net approach observes that software process is fairly similar to a "real time" system. Petri-nets seem capable of modeling the dynamic triggering and concurrency aspects of processes. However the structuring facility is limited, and process customization and evolution are dicult (the graph is too sti ). The generic model describes the syntax and semantics of the Graph/Net, a project-speci c model is a particular Graph/Net. MELMAC/MSP uses FUNSOFT nets (high-level Petri nets) as the uniform, executable description of all the process entities originally expressed in di erent views. DesignNet proposes a formal process model combining AND/OR graph and Petri nets notation to improve the structuring facility.
2
In the Process Programming Paradigm the semantic model is a process programming language (usually procedural). There is hardly a generic model, and the projectspeci c model is de ned by a program in the language, and the real software development is the execution of this program. A general-purpose programming language like Ada seems too "heavy" for process modeling and not sucient for process modeling. Arcadia has a prototype process programming language APPL/A that extends Ada with programmable relations between objects, triggers on relation operations, optional-enforcible predicates on relations, and composite statements that provide transaction-like capacities. It o ers no subtyping. IPSE 2.5 has a process programming language PML, which is an imperative, concurrent language. Models or model fragments can be customized. Executing roles may be evolved by introducing new classes of roles and interactions. The Hybrid Paradigm derives from the fact that no single paradigm satisfy all the requirements of process modeling. Some of the presented systems are actually multiparadigm, though we classify them according to their main paradigm. E.g. SPECIMEN merges FUNSOFT nets and a rule-based process modeling language MERLIN to design its own process modeling language PML. EPOS has an hybrid PM model: it couples PM and multi-actor CM, supports planning, o ers project-level structuring and simple PM customization.
Figure 1: PM System Summary and Comparison 3
