MultiView Modeling of Software Processes

发布于:2021-06-23 09:53:12

Multi-View Modeling of Software Processes

Martin Verlage
Fachbereich Informatik, Universitt Kaiserslautern, 67653 Kaiserslautern, Germany a

Position Paper: 3rd European Workshop on Software Process Technology, Villard de Lans, France, February 1994

1 Introduction
The objective of software process technology is to support the derivation and analysis of software process models, and their use in projects. Software process models should represent as much as possible of a project, and thereby support as many project members as possible. But a very rare few people ever understand a large project as a whole. The rst problem is that every process element is viewed di erently depending on the contexts of the project members. The second problem is that di erent roles exist within a software project. I believe that a useful software process model can only be derived by describing the process from di erent perspectives. Concentration on a subset of information (e.g., product ow) during modeling is helpful [1]. The part of a software process model which corresponds to a role (i.e., supports the role's tasks) is called a view. Views may overlap and have to be integrated to produce a comprehensive software process model. I believe that development and use of comprehensive software process models should be performed by the application of the following three steps: 1. Modeling. Every participating role develops its own view. This results in a role-speci c description which is more likely to represent the real world than a description made by other people. 2. Integration. The separately developed views have to be integrated into a comprehensive software process model. Because all roles have described the same project, there has to be a match. If views cannot be connected, the project itself is misunderstood; cooperative work is based on no common basis. 3. Use. Every role uses its own view during project guidance. The comprehensive software process model is not presented as a whole, and unnecessary information is ltered. The process is presented using the role's own terms de ned in the corresponding view. It is my belief that the views developed in step 1 are the elements to be reused, and not the comprehensive software process model. Each view represents a set of processes aiming at a goal (e.g., veri cation); a project represents a collection of goals. This collection is unique in every project, but the single goals represented by a view remain stable over project lifetime.

2 Requirements for Multi{View Approaches
Models to be integrated may represent complex processes and may overlap. Therefore, multi{view modeling requires powerful approaches. In our opinion, at least the following requirements for supporting approaches must be ful lled by a supporting approach: R1. Di erent perspectives on the same process element must be offered. Di erent roles need di erent information about a product, process or resource. R2. Tailorable (user-de ned) perspectives. We can not assume a static set of prede ned perspectives will be sucient since it is impossible to de ne a static set of roles. R3. Structuring of views. Process elements should be explicitly grouped to form a view. R4. Independent modeling of views. The description of views may not be in uenced by other views. Correspondence between views should be established after their description. R5. Detecting similarities between views. Separately de ned views may describe the same process elements. Similarities have to be detected to connect views. R6. Detecting inconsistencies between views. Views developed independently may contain inconsistent information. Semantic information about software processes has to be provided in order to detect such situations. R7. Dynamic change of perspectives. Not all roles participate during the whole project. Actors are assigned and released asynchronously; even the same process element may be viewed di erently by the same role in di erent situations. Mechanisms are needed to support a change of perspectives. R8. Concurrent views. Many people are involved in a project. Di erent views should be presented concurrently to the di erent people. R1{R4 belong to modeling (step 1); R5 and R6 support integration (step 2); and R7 and R8 allow independent use of views (step 3).

3 Does Existing Technology Meet the Requirements?
Various approaches exist in the area of system development which support simultaneously displaying information. We describe a few approaches brie y. The idea of de ning system functionality by di erent approaches is rooted in the context of multiparadigm languages [2]. Di erent vies ( les) may be described by using languages employing di erent programming paradigms.Merging di erent views is established by procedure calls. Software Engineering Environments may o er multiple views simultaneously to the user (e.g., Pecan [3]). Separate views are derived from an internal representation based on abstract syntax trees.

These two approaches o er support for solo programming. An approach explicitly supporting parallel development is ViewPoint speci cation [4]. Evolutions of software speci cations are performed by using associated ViewPoints, which are built out of ve slots: a style, a domain (in our case xed: software process), the speci cation, a work plan and a work record, which contain operations on the speci cation and the history of applied operations. ViewPoints are related by identical entities, which are propagated top{down. An approach developed for the speci cation of systems but also used to model software processes is STATEMATE [1]. It has been used to describe software processes from three prede ned perspectives, namely the organizational, the behavioral, and the functional view. Independent evolution of multiple speci cation lines and later integration is described in [6]. The main problems occur when detecting correspondences and inconsistencies [7]. ORM is used as an object{oriented basis for integration of classes with roles (i.e., sets of features) [8]. The approach developed within the ITHACA ESPRIT project employes general but simple techniques in order to detect correspondence between classes. ES-TAME [5] is a modeling tool for specifying high{level software process models. Templates for measurement plans, which express development goals in an operational and measurable manner, may also be de ned. Users modify process elements by using viewpoints, which are de ned in the elements itself. Every model de nes its own appearance to the real world. The following table expresses which requirements are ful lled by the presented approaches. A '' denotes that a requirement is ful lled, '()' means that the approach covers only a subset of the corresponding problem. An empty box means that this requirement is not ful lled by the approach.
Approach R1 R2 R3 R4 R5 R6 R7 R8 Multi-Paradigm Languages    SEEs   ViewPoints     () () STATEMATE  ()   Multi-Line Speci cation    () () ITHACA (ORM)    () () () () ES-TAME     Table 1: Requirements Satisfaction of Multi-View Techniques

4 What is Needed for Multi{View Modeling
The requirements introduced in Section 2 are not ful lled completely by any of the seven approaches shown in Table 1. The two main reasons are that they do not support all three steps presented in Section 1, and are not tailored to the speci c needs of multi-view modeling of software processes (except ES-TAME). The second reason means that the approaches lack the knowledge about software

processes which is primarily needed during integration of views (R5 and R6). Therefore, I identify the following points as important for future research e orts: Do any standard views exist? Experience has shown a distinction between managerial and technical perspectives on a software development or maintenance project. Re nement of these views is needed in order to describe the relevant aspects on which a role should concentrate, i.e. to support learning and integration of new project members. Company{wide standard views ease reuse of process knowledge. How are identical objects identi ed in di erent views? Matching identical information in separate views is needed to connect views. This becomes more evident when aspects of di erent views have only small intersections, e.g. one view shows product ow, whereas a second presents process attributes. Where to begin when merging di erent views? Does there exist an order, determined by the roles, which eases the merging of models? For instance, selecting a high{level role like project manager as a starting point for merging activities could serve as a framework for integration. How is consistency achieved when merging di erent views? Specifying a project from di erent viewpoints can lead to inconsistent descriptions. Sometimes this inconsistency may be required, for example when the roles misunderstand the processes. Finding these inconsistencies requires additional semantic knowledge about software processes. Finding solutions to these problems will allow describing software process models from di erent perspectives. This requires a tailoring of existing approaches to the speci c needs of multi{view modeling of software processes. Additional semantic information about software processes has to be considered in the design of future tools and methods to support development and use of software process models.

1. Humphrey, Watts S. and Kellner, Marc I. "Software Process Modeling: Principles of Entity Process Models", Proceedings of the 11th International Conference on Software Engineering, May 1989, pp. 331{342. 2. Brent Hailpern, "Guest Editor's Introduction: Multiparadigm Languages", IEEE Software, January 1986, pp. 6-9 3. Steven P. Reiss, "PECAN: Program Development Systems That Support Multiple Views", Proceedings 7th International Conference on Software Engineering, 1984, pp. 324-333 4. A. Finkelstein, D. Gabbay, A. Hunter, J. Kramer, B. Nuseibeh, "Inconsistency Handling in Multi-Perspective Speci cations", Proceedings European Software Engineering Conference, Garmisch-Partenkirchen, Germany, 1993 5. Markku Oivo, Victor R. Basili, "Representing Software Engineering Models: The TAME Goal Oriented Approach", IEEE Transactions on Software Engineering, October 1992 6. W.N. Robinson, "Integrating Multiple Speci cations Using Domain Goals", 5th Int. WS on Software Speci cation and Design, Pittsburgh, USA, May 1989

7. M.S. Feather, "Detecting Interference when Merging Speci cation Evolutions", 5th Int. WS on Software Speci cation and Design, Pittsburgh, USA, May 1989 8. C. Francalanci, B. Pernici, "Object-Oriented View Integration to Support Reuse of Requirement Speci cations", Proc. 2nd International Computer Science Conference, Hong Kong, December 1992

a This article was processed using the L TEX macro package with LLNCS style