Toward Process-Model-based Software Environment Kernels N. Boudjlida - J.C. Derniame C.R.I.N. - Nancy I University - B.P. 239 54506 - Vandoeuvre Les Nancy Cedex (France) E-mail address :
[email protected] Abstract : The main role of the software pro- them ? An other way is to consider wether the en-
vironment is method-dependent or not. In the rst case, the environment is based on a given method, while, in the second case, it can be considered as a toolkit and the method depends on the skill of the persons who use the available tools. Similarly, one can consider wether the environment is languagedependent or not. For example, GANDALF [16] falls in the rst category since it is Ada-dependent. Considering these dictinctive features, various strategies for software environment development can be followed. The most commonly adopted is to build a toolbox. Even if a kind of on-line help is provided in this kind of environment, it is clear that it cannot signi cantly contribute to sophisticated assistance in software development. A second strategy consists in adopting a development method or a tool and make them evolve by adding new tools. A third approach is to x a kernel and to enrich it by concentric layers. The kernel may be a language, like in [16], or an object management system like in [9, 10]. A nal strategy is to develop a kind of metaenvironment which enables developing environments. This meta-environment, we'll call environment kernel, should oer mechanisms to de ne speci c environments. It is the approach adopted in the ALF project [1, 2] and we shall focus on it in this paper trying to exhibit the features and the mechanisms needed for achieving such a kernel. The main feature is to provide means for explicit description of the structure and the intended behaviour of the speci c environments. This will be called a Model of the Software Process [24, 28, 26,
cess model is to describe a-priori how the development should run. The intent of such a description is to be interpreted by the infrastructure on which the development is done in order to safely drive it. Indeed, a large variety of knowledge is needed which concerns the software products, the tools which can be used, the policies to be obeyed. Considering this variety of knowledge, we rely on a "multiparadigm" approach to propose requirements and concepts for software process modeling i.e. for capturing, describing and using this knowledge to build model-based Software Engineering Environment tted with assistance capabilities. Design and implementation issues are also considered. Keywords : Software engineering, Software environment, software process model, object-type, operator type, assistance, Model for Asisted Software Process, CASE, database technology, arti cial intelligence.
1 Introduction Software Engineering environments can be classi ed dierent ways. A rst way is to consider the steps of the software life-cycle the environment deals with i.e. does the environment cover the whole steps, from the requirement stage to the software maintenance one going through the design, coding and integration stages, or does it cover only some of In
Proceedings of the 10th International Conference of the Chilean Computer Science Society, Santiago de Chile, July 1990.
1
19, 17, 11, 3, 22, 31]. A consequent need is a set of mechanisms to deal with a given model of software process. Further, considering the variety of things to be described (object structures, available tools, various relationships among objects, policies induced by the tools or by a software development method, . . . ), we'll show that database technology can widely contribute to our aim. Furthermore, considering the complexity of the software-project-development task, the availability of sophisticated assistance mechanisms inside the environment is not a luxury nor a new preoccupation [32, 20, 21, 12, 4, 23]. We shall show that knowledge required for assistance can be part of the Software Process Model and, in this framework, we will point out the contribution of arti cial intelligence techniques in the development of the environment kernel. Thus, the second section of this paper exposes the role of database techniques in software environments. The third section points out requirements for a software process model. In the fourth section, we brie y review some proposals for software process model, focusing on the one we have de ned and which is currently under implementation and validation in the European Esprit Project "Advanced Logistic Framework". Finally, we discuss some architectural aspects of model-based environment kernels.
2 The role of a database in a software environment The development of software systems, including the development of software environments themselves, manipulates lot of objects of various and unusual types (speci cation, design and documentation documents, nancial and human resources, source and object-code les, . . . ). The need for a sophisticated database to manage these objects a consistent way is obvious and commonly adopted [27, 25, 6, 29]. In this framework, instead of making an operating system communicate with a conventional database
management system, a current approach [13, 7, 30] consists in extending the operating system with database management facilities. Thence, the operating system acts as an actual database management system. It means that it provides data structuring and data manipulation mechanisms to enable a user de ning its object-base schema similarly to a classical database de nition schema and then to act on it. We shall call Object Management System (OMS) the part of this kind of operating system which is in charge of managing the object base. For instance, EMERAUDE [15], which is an implementation of PCTE [14], encapsulates the UNIX system and its object model is based on the entityrelationship data model [8]. Thus, the role of the object base is to be the repository of all the information needed for the development of a software project. It contains the description of the objects, occurrences of the objects, the description of object relationships,. . . Furthermore, if we want the software environment to provide intelligent facilities either in software development or in project management, the object base can be viewed as a knowledge base and the OMS as a knowledge base manipulation system [25, 20, 18].
3 Software Process Modeling The explicit description of the knowledge is provided through a Model of the Software Process. Let us state some objectives and requirements for such a model.
3.1 Objectives of Software Process Modeling
Understanding the development process.
Reasoning to improve the development process, to verify it and to verify what it produces
Controling the development process, the activities, the sta . . .
Measuring the development for a better understanding and for risk estimation. Evaluating the process iteself, the activities, the persons from a quantitative as well as a qualitative point of view. Managing the activity, the various resources (human, nancial, material), the risks. Integrating the dierent kinds of activity which are performed during the software process, and more especially integrating development activity and project management activity Learning "from the past" either in process modeling or in project development and management. Guiding in the development process as well as in its de nition. Assisting in the various activities. Predicting the risks, the bottlenecks. Re-using an entire model or part of it, re-using software components. Evolving of the model, the software products
on). Thus, the software process model should enable the description of the objects, their properties and their relationships. Further, this description should be easily re ned and detailed to satisfy the dierent users' needs.
Description of allowed transformations of the objects : Software development mainly proceeds by object transformation : Requirements are "transformed" into speci cations which in turn are transformed into a global system design, and then into a detailed design, and so on until achieving the software system. Thence, the software model should encompass the description of these transformations. Moreover, it should explicitly mention those which are allowed on each object type at each stage of the development.
View mechanisms : The software process model should enable viewing the current state of the software project from dierent standpoints since dierent types of actors are involved in its achievement (project managers, team managers, designers, developpers, . . . ).
Structural and organizational description : The model should enable the speci cation of the structure of the software development activity as well as its organization (structure of the development teams, test and integration protocols, communicating protocols, . . . ).
Task description : Software development activity can be decomposed into tasks and those must explicitly be part of the model.
Constraint description : Objects, relationships, object transformations, tasks may be constrained dierent ways : integrity constraints, temporal constraints, nancial constraints . . . should be expressible in the model.
Type and level of assistance speci cation : Since an "ideal" and complete assisting system is di cult to achieve, the model should provide features to mention the kind and the level
3.2 Requirements for a Software Process Model and its metamodel These objectives lead to state some requirements for the software process model itself and for its conceptual framework. Life-cycle covering : Modeling should concern an entire software life-cycle, independently from the development model adopted (waterfall, spiral, . . . ). Description of objects, properties and relationships at dierent level of granularity : As already quoted, software development involves various kinds of objects. Relationships hold among them (for instance, a module uses another one, a schedule is related to a task, and so
4
of assistance expected from the software envi- they help in forward reasoning to help in going furronment during the model-driven development. ther or to nd out the actions the system can undertake. They also serve in backward reasoning to Formality : Formality is essentially required to determine what activities have to be done prior to avoid ambiguity and to ease tracking unconsis- an activity asked by the user but which is not possitency. Thus, a model should be as formal as ble in the current state of the development because possible. its precondition is not satis ed. The rule can also Readability : A software process model is in- serve in plan generation, that means that the systended for a large usage by people with dier- tem can nd out the sequence of actions that can ent technical levels. Thus the description of a be performed to lead the development into a given state. model should be readable by those. The interest in this approach is that the "intelUnderstandability : This requirement is closely ligence" is outside the tools. Thus, no change is related to the previous one. Moreover, the for the existing tools or for the ones which speci cation of a model should ease the under- required may be incorporated into the environment. Furstanding of the software process. ther, the set of rules is easily modi able since this Modularity : Modularity of a model is required is "by essence" a modular approach. Moreover, difin relationship with the two preceding require- ferent kinds of rules can be de ned, and more espements. Furthermore, it enables a kind of step- cially, one can de ne strategic rules (or meta-rules) wise re nement of the model as well as its evo- which drive the system in reasoning. Nevertheless, the consistency of the set of rules is di cult to eslutionary. tablish. Partial or total re-usability : A software process model may be entirely re-used for project A second approach uses an heterogeneous formaldevelopment. It means that the development ism for process modeling [4, 11]. It is the one we of various projects may be driven by the same propose in the ALF Project. In this framework, a process model. Further, part of a model may Software Process Model consists in : be re-used while designing a new model. an object model which describes the structure and the relationships of the objects. Evolutionary : A model must be evolutionary to enable progressive completion and tuning to an operator model which speci es the set of speci c needs or changes. operator types which are available in the environment. The operator model determines the Concepts for software pro- set of tools of the environment.
cess modeling
This section presents various approaches to software process modeling. A rst approach [5, 21] relies on an object base and a rule base. These are rule-based software process models. The rules consist in specifying the precondition of an activity and its postcondition. Then, they are used as the basis for reasoning during the eective software development. Mainly,
a characteristic model which indicates constraints which must be satis ed by software process in precise states. The environment should ensure that the characteristics are not violated.
a rule model which is a set of pairs (condition, action) which indicates to the environment what to do (action part) in some situations (condition part). These rules are the
basis for the system initiative as well as for observation and measurment of the eective software process, an ordering model which speci es constraints on operator activation, like precedence or simultaneity of operators, . . .
In this framework, the object model speci es the structure of the object base, the operator model and the ordering model specify the kinds of activity which can be performed. The policy is expressed in the order model, the characteristic and the rule model. The environment kernel should be able to interpret such a model to drive the development of a software system and to assist the dierent users of the environment.
5 Architectural considerations The model-based environment kernel tted with intelligent capabilities we are building relies on dierent layers :
The operative system layer is in charge of executing operations. The information system layer is in charge of collecting, storing, retrieving, updating information concerning the software process model itself as well as the information which concerns software projects whose development runs according to a given model. The information system is build on top of PCTE. It uses the services of the Object Management System of PCTE. The piloting system layer is in charge of coordinating the activity of the components of the kernel. The user interface layer provides dierent interfaces to the various kinds of users. Namely, interfaces will be provided for designing and checking the consistency of Models of Software Process, other ones for software developpers,. . .
6 Concluding remarks The expected bene ts of software process modeling is improvement of the productivity as well as of the quality of the products. The model we propose here is currently under validation and implementation. We hope reporting on the results very soon.
Acknowledgements :
This work is partially sponsored by the Commission of the European Communities under the ESPRIT programme (Project Ref. N 1520).
References [1] ALF. Advanced software engineering logistics framework. Technical Annex , 1987. [2] K. Benali, N. Boudjlida, F. Charoy, J-C. Derniame, C.Godart, Ph.Gi ths, V.Gruhn, Ph.Jamart, A. Legait, D.E. Old eld, and F. Oquendo. Presentation of the ALF project. In Proceedings of the International Conference on System Environment Development and Factories, Berlin, Germany, may 1989. [3] K. Benali, N. Boudjlida, F. Charoy, and J.C. Derniame. A Model for Assisted Software Process. In ICCI'89 - Int'l conference on Computing and Information, Toronto - Canada, May 1989. Canadian Scholars' Press Inc., Toronto. [4] N. Boudjlida, F. Charoy, J.C. Derniame, and C. Godart. Modeling of Software Process Assistance. In CASE'89 - 3rd Workshop on ComputerAided Software Engineering, London, July 1989. [5] N. Boudjlida and O. Gervaise. Concepts and experiments in intelligently-assisted software development. Research Report, September 1988. [6] N. Boudjlida, O. Gervaise, C. Godart, and J.C. Derniame. Fundamental Concepts and Techniques for Environment Kernels - Invited Paper. In 2nd Congress on databases - Korea Information Science Society, Seoul - Korea, February 1988. [7] P. Carr, R. Stevenson, J. Alea, J. Berthold, G. Croucher, M. Davis, G. Dobbins, V. Szarek, and W. Webster. Implementation of a prototype CAIS environment. Ada letters, 7(2), March 1987.
[8] P.P. Chen. The entity-relationship data model Toward a uni ed view of data. ACM - TODS, 1(1), March 1976. [9] PACT Consortium. PACT General Description. ESPRIT Programme, 1986. [10] PACT Consortium. The PACT Tool Writer's Guide. ESPRIT Programme, 1988. [11] W. Deiters, V. Gruhn, and W. Schafer. Process programming : A structured multiparadigm approach is needed and could be achieved. In 5th Intern. Software Process Workshop, 1989. [12] J.C. Derniame, B. Ayoub, K. Benali, N. Boudjlida, C. Godart, and V. Gruhn. Toward assisted software process. In Proceedings CASE'88, Boston MA, July 1988. [13] US DoD. Rationale for the DoD Requirements and design criteria for the Common APSE Interface Set (CAIS), September 1985. [14] F. Gallo, R. Minot, and I. Thomas. The object management system of PCTE as a software engineering database management system. ACM SIGPLAN Notices, 22(1), 1986. [15] GIE EMERAUDE. The Emeraude Environment, August 1987. [16] A.N. Habermann and D. Notkin. Gandalf : Software Development Environments. IEEE - Trans. on Soft. Eng., 12(12), December 1986. [17] H. Hitchcock and al. The Process Model of the Aspect IPSE. In 4th Intern. Software Process Workshop, Moreonhamstead Devon UK, May 1988. [18] H. Hunnekens and al. Osmose : A step towards knowledge-based process modeling. In Proceedings of the International Conference on System Environment Development and Factories, Berlin, Germany, may 1989. [19] G.E. Kaiser. Rule-based Modeling of the Software Development Process. In 4th Intern. Software Process Workshop, Moreonhamstead Devon UK, May 1988. [20] G.E. Kaiser and P.H. Feller. An architecture for intelligent assistance in software development. In Proceedings of the 9th Int'l Conf. on Soft. Eng., Monterey - CA, March 1987. [21] G.E. Kaiser, P.H. Feller, and S.S. Popovitch. Intelligent Assistance for Software Development and Maintenance. In IEEE - Software, 1988.
[22] Takuya Katayama. A hierarchical and functional software process description and its enaction. In 11th Int'l Conf. on Soft. Eng., 1989. [23] T. Khammaci, N. Boudjlida, and J.C. Derniame. Knowledge-Based Software Assistant : The Case of Software Development. In ICCI'90 - Int'l conference on Computing and Information, Toronto Canada, May 1990. [24] M.M. Lehman. Process models, process programs, programming support. In Proceedings of the 10th Int'l Conf. On Soft. Eng., April 1987. [25] B. Meyer. The software knowledge base. In Proceedings of the 8th Int'l Conf. On Soft. Eng., London, August 1985. [26] L. Osterweil. Software Processes are Software Too. In Proceedings of the 9th Int'l Conf. on Soft. Eng., pages 213, Monterey, CA, March 1987. [27] M.H. Penedo and E. Don Stucle. PMDB, a project master database for software engineering environments. In Proceedings of the 8th Int'l Conf. on Soft. Eng., London, August 1985. [28] W.E. Ridle and L.G. Williams. Modeling Software Development in the Large. In Dowson, editor, 4th Int'l Software Process Workshop, Breckenridge, Colorado, November 1986. [29] H. Tardieu. Contribution of the Entity Relationship Approach to object management in an information system - A tutorial. In 5th Int'l Conf. on Entity Relationship Approach, Dijon - France, November 1986. [30] I. Thomas. The PCTE Initiative. ESPRIT Technical Meeting, 1987. [31] B. Warboys. The IPSE 2.5 Project : Process Modelling as the basis for a Support Environment. In Proceedings of the International Conference on System Environment Development and Factories, Berlin - Western Germany, May 1989. [32] T. Winograd. Breaking the complexity barrier (again). SIGPLAN SIGIR Interface Meeting on Programming Languages - Information Retrieval, 1973. November.
