Representing the Software Process Model and Meta-Model in EPOS Reidar Conradi, M. Letizia Jaccheri*, Jens-Otto Larsen Div. of Computer Systems and Telematics, Norwegian Institute of Technology, N-7034 Trondheim, Norway Phone: +47 7 593444, Fax: +47 7 594466, Email: conradi@idt.unit.no * Politecnico di Torino,Corso Duca degli Abruzzi n.24, I-10129 Torino, Italy 27 April 1992 ABSTRACT This paper presents some aspects of EPOS, a kernel software environment with integrated configuration and software process management. EPOS features a structurally object-oriented and uniformly versioned DBMS (EPOSDB) to manage software products and processes, and their models (types). We focus on the object-oriented Process Modeling Language (PML), extending to the underlying data model, and on meta-information to control evolution of process models, i.e. meta-processes. The PML is implemented as a versioned, reflective, concurrent, object-oriented Prolog. 1. PM Framework and PM Meta-processes Software Process Modeling (PM) and associated environments have drawn increased attention within the Software Engineering community. The need for flexible customization and evolution has lead to very dynamic process modeling formalisms, e.g. utilizing an object-oriented (OO) framework. Process models (often types) consist of a "passive" product model, an "active" activity model, a tool model (perhaps covered by the former), and an organizational model (briefly dealt with here). There are three basic paradigms for activity modeling: AI RULES (PRE--CODE--POST or triggers), TASK NETS (e.g. extended Petri Nets), PROCESS PROCESS LANGUAGES (PMLs) -- plus hybrids (as in EPOS). All the corresponding formalisms are rather low-level, with insufficient facilities for design, structuring and customization/evolution of models and their rule bases. The last point involves meta-processes, and we can identify six PM "meta-process" phases. All these must be supported by explicit representations, methods, formalisms and tools, and we indicate some of these for EPOS /Jacc92/ below: 1. Establishing a PM FRAMEWORK. In EPOS this consists of an EPOS DBMS, a PML, a set of pre-defined types, some EPOS PM facilities. The latter consist of a PM Manager with a PML translator/editor/analyzer, a PML Code Interpreter and Execution Manager, and a Planner. 2. Eliciting/designing an INFORMAL PROCESS MODEL. This is done with input from the application domain(s). 3. Establishing/analyzing a formal, GENERIC PROCESS MODEL. A process model in EPOS is a set of types for products, activities (tasks) including tools, and projects/organizations. Thus, this meta-phase involves browsing, editing, and analyzing a library of reusable model fragments by a PM Manager. 4. Compiling/customization a SPECIFIC PROCESS MODEL. Here the selected (sub)types etc. are refined and bound, again by the PM Manager. 5. INSTANTIATION of concrete subprocesses. Task subnetworks are made according to the actual products, schedules, tools, and human resources. All this is assisted by the Planner. 6. EXECUTION/MONITORING of processes, plus feedback. This mainly consists of guided or enforced use of application tools by the Execution Manager, interpreting a specific process model. In PM systems with dynamic binding, like EPOS, the meta-process phases 3--6 are incremental and never-ending. 2. Overview of EPOS The EPOS system is layered as follows: 1. CLIENT-SERVER EPOSDB, with uniform ("change-oriented") versioning /Lie89/. It offers a structurally OO EPOS-OOER data model and its DDL. All (meta-)type information are stored as TypeDescr's, and thus explicitly manipulable and versionable. EPOSDB is implemented in C and with a client interface in Prolog, our DML. Database operations are performed in the context of a nested and long transaction, coupled to a project and with a checked-out workspace. The current version context determines the "visible" subdatabase. 2. A BEHAVIORALLY OO PML extension in Prolog. This incorporates the DDL and DML above, and adds type-level attributes and instance/type-level procedures and triggers. Flexible inheritance policies can be defined (redef, append, inner). The type-level procedure i_create is used to create a new instance, and t_create, t_delete and t_change are used to control type evolution by the PM Manager (see next section). The PML is implemented by the PML Translator/Editor and PML Code Interpreter, using the underlying EPOSDB. The Interpreter's dynamic binding semantics for procedures (with triggers) and attributes is implemented by one predicate: call_proc(Caller, Callee, ProcName, InParms, OutParms). This EPOS layer supports the previous metaprocesses 3--4 in making generic and specific process models. 4. An EPOS PM TASKING FRAMEWORK, using the PML. This defines special type-attributes for a root TaskEntity type. It has static PRE--POST first-order logic predicates for reasoning, dynamic PRE--CODE--POST for activation, FORMALS to constrain horizontal task chaining (via actual input/output products), and DECOMPOSITION to constrain vertical task breakdown. The PML tasking implementation relies on the Execution Manager and the task network instantiation on the Planner (next section). Thus, this EPOS layer supports the previous metaprocesses 6 and 5 in executing and instantiating processes. All PM tools in layers 2 and 3 use the XPCE User Interface package. 5. PROJECT-SPECIFIC TYPES AND INSTANCES, including application tools. The standard product model is hierarchical, with separate Family interfaces/bodies and general dependencies. Instances often constitute a network of tasks and products, connected to tools and human resources. 3. Reflections on PM Information and Rules in EPOS EPOS is able to model structuring, behavior, and customization/evolution of the main categories of PM relevant information: products, processes with tools, projects, and models themselves (types). Versioned products evolve through processes. Processes are again driven by the products, and are themselves versioned objects. This circularity applies both for processes and meta-processes (and their products), and is regulated by the current set of types. Different rules are controlling operations on these four categories: 1. For PRODUCTS: the Execution Manager is responsible for task execution upon these, applying dynamic rules (PRE/POST) and CODE, and calling instance-level procedures. 2. For PROCESSES: the Planner /Liu91b/ is instantiating these, using static rules to deduce the task network structure. The Planner combines the "passive" task type-properties (e.g. FORMALS and DECOMPOSITION) with the actual product description and a stated product goal, to produce a new or revised task (sub)network. Both hierarchical and non-linear planning are applied. Type-level procedures evaluate domain-specific subgoals, like performing closures of input files to source-code components. The Planner and Execution Manager work in close cooperation, facilitating incremental building and execution of task networks. 3. For PROJECTS (for organizational information): These are special tasks coupled to database transactions. They control general cooperation within and between teams. E.g. the propagation rules between cooperating transactions is regulated by instrumentable task types. A subproject can change old information "inherited" from the superproject (e.g. type versioning), as well as add new information (e.g. by subtyping). Thus, EPOS has powerful basic mechanisms for structuring knowledge bases. 4. For MODELS (TYPES): the PM Manager evolves these according to meta-rules, mainly expressed as type-level procedures in PML. A batch PML Translator and an interactive PML Editor use the type-level procedures to guide type changes. E.g. t_change distinguishes between hard and soft type changes. The hard ones imply changes in instance-level attributes or in the subtype structure, and are generally disallowed. The soft changes are the PM-specific ones. Here, t_change will distinguish between a change in e.g. CODE, dynamic PRE/POST-CONDITIONs, FORMALS, or procedures. Some delicate conversions and synchronizations may have to be performed. We may add that for VERSIONS in general, EPOSDB uses stored version rules. These are predicates on global options, to regulate selection and merging of database versions. EPOS has three axes of structuring and variability in process models: - Vertical structuring by subtyping and other project specialization (p.t. no subschemas), i.e. the activity rule base is hierarchic. - Horizontal evolution inside projects and customized versioning between projects. - Combined vertical/horizontal, e.g. realized by dynamic binding semantics. 4. Conclusion and Future Work Object-oriented, concurrent and interpretative formalisms implemented in Prolog have provided a sound platform to realize the EPOS PML, although various Concurrent Prologs, CLOS or Smalltalk are competing candidates. A by-product of EPOS PM has therefore been a reflective, concurrent, object-oriented Prolog! A future challenge is to better formalize the PM meta-processes. We also need to develop improved methods for PM design (with a more high-level PML?), and to clarify the methodological issues in type versioning vs. subtyping. Further, we should be able to support model elicitation and assessment, and to handle large and partly reusable process models. Bibliography: /Jacch92/ Letizia Jaccheri, Jens-Otto Larsen, and Reidar Conradi: "Software Process Modeling and Evolution in EPOS". In Proc. IEEE Fourth International Conference on Software Engineering and Knowledge Engineering (SEKE), Capri, Italy. 13 pages, June 1992. Also as EPOS TR 159. /Lie89/ Anund Lie, Reidar Conradi, Tor M. Didriksen, Even-Andre Karlsson, Svein O. Hallsteinsen, and Per Holager: "Change Oriented Versioning in a Software Engineering Database". In Walter F. Tichy (Ed.): "Proc. of the 2nd International Workshop on Software Configuration Management", Princeton, USA, 25-27 Oct. 1989, 178 p. In ACM SIGSOFT Software Engineering Notes, 14 (7), pages 56--65, November 1989. /Liu91/ Chunnian Liu: "An Expert System for Program and System Development". In Proc. AVIGNON'91, Avignon, France, May 27--31, 1991, Volume 3, pages 97--110, 1991.