Process Integration in CASE Environments Peiwei Miy and Walt Scacchiz
Computer Science Departmenty and Decision Systems Departmentz University of Southern California1 Los Angeles, CA 90089 fpmi,
[email protected] Tel (213) 740-4782 Fax (213) 740-8494
Abstract
Integrated CASE Environments (CASEEs) have been focused on tool and object integration. In this paper, we present a new type of integration called process integration as a strategy for creating process-centered CASEEs. We argue that the major bene ts of process integration to software development include explicit process guidance and improved project management. We also present a few key components to implement process integration which form the backbone of a process-centered CASEE. These components include software process models, a process enactment mechanism, a developer's interface and a process manager's interface. Furthermore, our strategy implements process integration by merging these key components with existing CASEEs and creates process-centered CASEEs with reasonable e ort. To exemplify this strategy, we have migrated an operational CASEE, the SOFTMAN environment, into a process-centered CASEE.
Acknowledgements: This work has been supported in part by contracts and grants from AT&T, Northrop Inc. Paci c Bell, and the Naval Ocean Systems Center. No endorsement implied. Anthony Karrer, Thomas Getzinger, Mary Li, Junhui Luo, and Yu-ling Young contributed to implementation e ort. 1
1 Introduction Current research in CASE Environments (CASEEs) has been focused on two kinds of integration: tool integration and object integration. Tool integration deals with the implicit invocation and control of development tools [BGMT89, GI90, Tho89]. Object integration, on the other hand, provides a consistent view of development artifacts and easy-to-use interfaces to generate, access, and control them [AHM89, CS91]. This paper presents a higher level of integration called process integration that explicitly represents development activities as a software process model (SPM), and provides process guidance and coordination as well as tool and object integration. Accordingly, an integrated CASEE based on process integration is called a process-centered CASE environment. To realize process integration, we propose an implementation strategy that combines these key components with existing CASEEs. We rst present the concept of process integration and the architecture of a processcentered CASEE. Representation of SPMs is described next. A mechanism for executing SPMs then follows. After this, a developer's interface and a process manager's interface that provide the user interfaces for a process-centered CASEE are given. We then discuss our implementation strategy which is exempli ed by migrating an existing CASEE, the SOFTMAN environment [CS91], into a process-centered CASEE. We also describe our observations from this experiment and highlight some outstanding issues for future investigation at the end.
2 Process Integration Today's CASEEs generally support some form of tool and object integration. Tool integration provides a set of tools for software development and an invocation mechanism that controls their usage. In fact, these tools form a conceptual chain of invocation that facilitates related development activities. For example, in UNIX environments, programming is supported by text editors, language compilers, object linkers, program debuggers, and shell programs. The invocation chain is conceptual because it does not have an explicit representation in most CASEEs. Further, every programmer has his/her own version of the invocation chain that emerged through personal experience. However, variation in di erent versions of the invocation chain is minor for a small tool set. Object integration, based on an object model of software artifacts, emphasizes the management of the artifacts during development. The production and consumption of these artifacts normally has a partial order, that is, an artifact produced in an early life cycle activity will be used later in the life cycle to create another artifact. For example, an informal requirements description for a software system is often an initial artifact, while intermediate documents include the software's requirements speci cation, its architectural design, etc. A nal artifact is the software system. Again, we see a conceptual chain of resource transformation that progressively takes initial development artifacts into intermediate then nal product. On the other hand, object integration does not address the activities that produce and consume software artifacts. One common feature of these two conceptual chains is that they describe a chain of de1
Developer.1
Developer.1’s Interface
. . .
Developer.n
. . . Developer.n’s Interface
Manager
Manager’s Interface
Process Driver
Software Process Models Software Artifacts
Development Tools
Figure 1: The architecture of A Process-centered CASEE velopment task execution from di erent perspectives. The chain of tool invocation represents the use of development tools in task execution, while the chain of resource transformation represents the inputs and outputs of task execution. Process integration seeks to make the conceptual chain of task execution explicit, exible to changes, and bene cial to software development. In this paper, an SPM is the representation of this chain of task execution. Taking advantage of SPM representation to achieve more integrated support in CASEEs, therefore, is the theme of this paper. Process integration provides mechanisms that support process guidance, workspace, tool invocation, and object management. Process integration also enables software managers to monitor and control development progress. These mechanisms, including SPMs, a process enactment driver, developer's interfaces, and manager's interfaces are the key components of a process-centered CASEE. Figure 1 is the architecture of a process-centered CASEE with these components. As such, we now turn to discuss each of these components in detail. After that, we will discuss our strategy to implement process-centered CASEEs with these key components.
3 Software Process Models SPMs represent a formal way to organize and describe how software life cycle models, development methodologies, software artifacts, CASE tools, and developers go together. SPMs are speci ed as collections of objects which represent development activities, artifacts, tools, 2
and developers. Each of these objects describes a kind of information that is involved in software development and has its own representation. Further, these objects are linked through many kinds of relations. Altogether, SPMs serve as a repository of information on the status of development processes and activities that get manipulated throughout a software development project. Readers can nd a detailed de nition of SPMs elsewhere, such as in [MS90]. An SPM speci es an activity hierarchy that describes a decomposition of development activities and resource requirements including software artifacts, tools, developers, and other critical resources. We follow the scheme presented in [MS90]. An activity hierarchy represents decomposition of an SPM into a hierarchy of smaller activities called tasks and actions. Levels of decomposition can be arbitrary depending on the complexity of the process. The top-level description of an SPM is a task which is recursively decomposed into a set of interrelated subtasks (tasks and actions). Actions, at the bottom of this hierarchy, represent single tool invocation and simple resource transformation. Within a level of decomposition, a partial order for subtask execution is speci ed. The execution order de nes several types of precedence relationship among subtasks, such as sequential, parallel, iterative, and conditional. Four types of resource requirements specify descriptions of resources needed for a subtask and the expected products that result. First, a binding of users to the various developer and organizational roles taken during subtask performance. Second, software artifacts that are needed, created or enhanced during a subtask, called required and provided resources. Third, tools that are used. Last, information about subtask scheduling and their expected duration. These resources are represented as independent object classes and have relations that link them to SPMs. For example, a product model of a software system could be de ned to have a module decomposition structure, whose modules are linked to their producer and consumer subtasks.
4 A Process Enactment Driver A process enactment driver enables execution or interpretation of an SPM according to its activity hierarchy. It manages the order of subtasks to be performed and the constraints to be satis ed before subtasks are performed. It plays the role of an automated driver that initiates an SPM, enacts its subtasks, accepts developers' inputs, updates and propagates the status of these subtasks, and then triggers other subtasks. A key variable that represents the state of process enactment is its status. The status of an SPM or a subtask is an indicator of its current state of development. The status is updated by the process enactment driver based on interaction with developers. Updates to the current status value represent progress through enactment. To this end, process execution drives the status of an SPM from None to Done. The values of process status and their de nitions are listed in Figure 2. The de nition of an action's status is primitive and determined by operations on it, while the de nition of a task's status is recursively de ned and based on the status of its component subtasks. Thus, while an SPM indicates 3
Status Value De nition for Actions None Initially set Allocated Its developers, tools, and required Resources have been allocated Ready Allocated, and either without predecessors or its predecessors are done Active Its enactment is in progress. The assigned developers are performing it Stopped Not being performed, voluntarily stopped Broken Either i) one or more required resources is unavailable, or ii) unable to continue due to some other reason Done Execution is nished successfully Not-chosen Not selected for execution
De nition for Tasks Its subtasks are in status None Its subtasks are in status Allocated Some of subtasks are Ready, but none of them is Active Some of subtasks are Active Some of subtasks are Stopped, but none of them is Active, nor Broken, nor Ready Some of subtasks are Broken, but none of them is Active, nor Ready Its subtasks are in status Done Not available
Figure 2: Values of Status and Their De nition a prescribed order of subtask enactment, a record of subtask status transitions describe the order in which subtask enactment actually occurred. Figure 3 provides a complete status transition graph with transition actions. For example, Start changes an action's status from either Ready or Stopped to Active to signal that the execution of the action is in progress. The process enactment driver provides the set of operations that implements the status transition graph. Once resource allocation is done, developers start enactment of an allocated SPM by issuing start on initial Ready actions to the process enactment driver. During performance of the actions, some of them may be Done successfully, others may be Stopped, or even become Broken which needs repairing or rescheduling actions to recover it [MS91]. Once some of the actions are Done, they trigger the process enactment driver to update the SPM and assert more Ready actions. The enactment continues until the SPM is Done. Accordingly, developers enact and process managers control SPMs through two di erent user interfaces.
5 A Developer's Interface A developer's interface is a working environment that enacts an SPM. This interface enables di erent developers to execute SPMs concurrently and perform only their assigned subtasks through process guidance and workspaces. We describe each in turn. Process guidance is a way to inform developers of what subtasks they need to perform, and when these subtasks are ready to start. The developer's interface supports process guidance through navigation within an SPM by the process enactment driver previously described. In the developer's interface, a subtask can only be started by its assigned developers if its status is Ready or Stopped. When a subtask is nished, the developer's interface sends a Done signal to the process enactment driver. It uses the signal to set successor subtasks which are Allocated to Ready so they can be started by their assigned developers. In this 4
not-chosen
Branch Iterate
Allocate Resource none
Predecessor Done
allocated
Start
Finish
ready
active
done
Repair
Change
Change
Stop
Start
Allocate Resource Change broken
stopped Change
Figure 3: Transition of Process Status way, developers can start assigned tasks as soon as they become ready and are able to nish them in a timely fashion. The developer's interface accomplishes process guidance with both explicit and implicit process representation in its task windows. A task window presents the subtasks within a task, together with their current status. A stack of task windows with an explicit process representation example is shown in Figure 4. Each task window displays its immediate subtasks as a directed graph: tasks are represented as squares, actions as circles and precedence relationship as arrows from a subtask to its successor subtasks. Status of a subtask is represented as di erent colors on a color display and as di erent icons for a black-white display. Therefore, this graph indicates both task execution order and current progress of its enactment. A developer can start execution of any Ready subtask by clicking on it, which in turn opens another window. If the selected subtask is an action, the newly opened window is an action window to provide a working environment (explained next). If the selected subtask is a task, then the newly opened window is another task window with a lower level of decomposition, i.e. the subtasks of the selected subtask. As an example, in Figure 4, Mary starts a developer's interface. It shows two SPMs that are currently assigned to Mary: design FOO and reverse se at the top level (the upper left window's Task List). Also two levels of decomposition have been opened: One is for design FOO at the lower-left window and the other is for architectural design in the front-most window. In the task window for architectural design, the subtask is decomposed into a list of six actions, of which four are Done, one is Ready, and one is Allocated as indicated by the actions' status icons. Alternatively, a task window with implicit process representation displays a list of currently Ready actions within a task, called a ready list, and an action window. A developer is able to select an action from the ready list and nish it in the action window. The ready 5
Figure 4: A Developer's Interface: A Task Window Example list is updated by the developer's interface when an action is Done so that the next Ready actions can be displayed. This type of task window is a short-cut for developers who prefer not to guided by an explicit process representation, but the developer's interface nonetheless enforces the process description implicitly. Creating workspace involves two aspects: setting up a work area and invoking necessary development tools with resources as parameters. A workspace in the developer's interface is an area for a developer to perform an action. A developer accesses this workspace through an action window. Speci cation of an action provided by an SPM includes its required resources, its provided resources, and development tools. All this information is displayed in an action window such as shown in Figure 5. An action window also enables developers to invoke the tools on speci ed resources. Furthermore, in a simple situation when only one tool and one resource are speci ed in an action, tool invocation is automated, that is, once an action window for the action is opened, the developer's interface invokes the tool with the resource. Figure 5 is an action window for document architectural design where two tools have been invoked (dsn.exe and emacs), each of which operates on one resource (respectively arch spec.numil and arch spec.doc). When an action is done, the action window gets its provided resources from the tools and puts them into the right position according to the speci cation in the SPM in order for them to be used in other successor subtasks.
6 A Process Manager's Interface A process manager's interface provides software managers and process analysts with tools that de ne, monitor and control SPMs carried out concurrently through a set of developer's 6
Figure 5: A Developer's Interface: An Action Window interfaces. From the process enactment driver's point of view, a manager's interface does not change the status of an SPM,2 but retrieves information out of the SPM and presents it in easy-to-understand graphs and tables (Figure 6). These graphs and tables can also updated by the process enactment driver in real-time as developers make progress on their assigned tasks. Monitoring progress is concerned with observing process progress, such as completion of a subtask, creation of a resource, or other developers' activities. A window in the upperleft corner of Figure 6 gives a graph of activity hierarchy for design FOO. A window in the lower-right corner of Figure 6 lists a graph of task predecence relationship among a group of subtasks and their current status represented by di erent colors as before. A window on the upper-right corner of Figure 6, on the other hand, indicates resource production and consumption relationship among subtasks within a task. Finally, Controlling a process involves changing values in an SPM. This enables capabilities, such as assigning tasks to developers, removing a developer, or allocating resources. This is then done with a modi cation function shown in the lower-left corner of Figure 6.
7 The SOFTMAN Experiment As we suggested earlier, our strategy to implement process-centered CASEEs is to integrate the key components with existing CASEEs rather than building them from scratch[FO91]. To Other than to initialize an SPM and to ensure that the minimum required resources needed to start the SPM are allocated. Another facility is used to create, prototype, and simulate SPMs that are initialized by process managers [MS90]. 2
7
Figure 6: The Manager's Interface exemplify this strategy, we describe such an experiment in this section. The example CASEE is the SOFTMAN environment [CS91] developed in the USC System Factory Project over the past few years3. The comprehensive set of support mechanisms and tools in SOFTMAN, on the one hand, makes it a powerful environment to support large scale software development. On the other hand, it can be dicult to learn the SOFTMAN development methodology and to use its tools e ectively. Therefore, a process-centered SOFTMAN environment with process integration is expected to overcome, or mitigate, these diculties. The steps we took are as follows: 1) Identify basic concepts, functionalities, and tool invocation sequences of SOFTMAN. 2) Formally represent the information gathered in Step 1 in an SPM called the SOFTMAN process model. 3) Port the SOFTMAN process model into a process-centered CASEE and integrate the SOFTMAN object model and tool set. STEP 1: The SOFTMAN environment is an integrated CASEE supporting forward and reverse engineering of large scale software systems. Through extensive studies, the following concepts were identi ed as important to SOFTMAN: It supports an incremental life-cycle development methodology, a product model assuming the correctness of interrelated life cycle artifacts [CS89], and a set of structure-oriented tools[CS91]. Figure 7 shows an example of the SOFTMAN user interface where two activities take place: editing a design speci cation and viewing an operational requirements. Software development guided by SOFTMAN follows an incremental, yet sometimes iterative, tool-based life-cycle methodology, which creates and manipulates a tree-structured collection of requirement analyses, requirement speci cations, designs, implementations, testing and maintenance. These stages are decomposed until level of single tool invocation is idenOther CASEEs cited in the references might equally well serve as suitable alternatives to SOFTMAN in this experiment. 3
8
Figure 7: The SOFTMAN User Interface ti ed. The SOFTMAN product model consists of a collection of software life cycle objects and relations between them. More detailed information is also provided so that all software objects have attributes which characterize their interfaces and interconnections. SOFTMAN requires that a skeletal structure of a software object, called mod struct, be created before its content, called mod cont, can be created and maintained correctly. We call this a structure rst, content-second development method. For each development stage, SOFTMAN provides a set of structure-oriented and correctnesschecking tools, which are used to create, modify, and maintain both the structure and the content of software objects. These tools include language-directed editors to create content of software objects and graphical editors to manipulate object structures. In addition, these tools communicate with an object management repository that checks consistency, completeness, and traceability constraints on all objects so as to incrementally assure or track their overall (in)correctness. STEP 2: Based on our understanding of SOFTMAN, the SOFTMAN process model de nes development activities, their prescribed execution order, necessary tools for each development activity (multiple tool choices may exist), and associated software objects required and provided in each activity. Overall, it follows the SOFTMAN development methodology and the structure- rst, content-second constraint. In Figure 9, the top level activity hierarchy is partially displayed. Figure 8 gives speci cation of an action, des mod cont within the SOFTMAN process model with its speci cation of a developer, execution order, a required software object, a provided software object, and two development tools. 9
{{ des_mod_cont INSTANCE: ACTION TASK_ASSIGNED_TO_AGENT_ROLE: software_engineer TASK_COMPONENT_OF: softman_model TASK_HAS_PREDECESSOR: des_mod_struct TASK_HAS_SUCCESSOR: imp_mod_cont TASK_REQUIRE_RESOURCE: arch_spec.doc TASK_PROVIDE_RESOURCE: arch_spec.numil TASK_REQUIRE_TOOL: vi dsn.exe}}
Figure 8: An Action De nition: Edit a design document Porting the SOFTMAN process model into a process-centered CASEE is straightforward since the model is just an instance of a de ned SPM class. This step inputs the SOFTMAN process model into the process enactment driver and makes the SOFTMAN data model known to it. The SOFTMAN tool set is then integrated by re-attaching the SOFTMAN tool invocation menu items to the SOFTMAN developer's interface and establishing links between the tools and the data model. Figure 9 shows the developer's interface to the new process-centered SOFTMAN environment. The windows in the developer's interface display the SOFTMAN process model as well as an action window that executes des mod cont de ned in Figure 8. The new SOFTMAN environment uses the interfaces and supports the SOFTMAN process model as well as the original SOFTMAN data model and tool set. The process-centered SOFTMAN environment preserves the important SOFTMAN concepts and functionalities, while adding support for process guidance and project management. Under the process-centered SOFTMAN environment, users know what development stage they are currently performing, choices of available tools to use, software documents to be produced, and what is expected next. Our experiment in developing this process-centered CASEE led to the following observations: First, the process-centered SOFTMAN environment is exible to changes. In fact, we have de ned variations of the SOFTMAN process model so that these models support di erent development methodologies, but use the same product model and tool set. This would not be possible with the original SOFTMAN CASEE without a major reprogramming e ort or an o -line methodology to follow. Second, this strategy to process integration should be applicable to most CASEEs that provide basic tool and object integration mechanisms. Last, the diversity of interfaces in existing development tools requires high compatibility for the process-centered CASEE in order to integrate various kinds of development tools. Our current strategy is to enable each CASEE to de ne its own product and tool models and to have an open structure for process integration to incorporate them. The SOFTMAN experiment has shown the promise on this regard, but more study is needed. STEP 3:
10
Figure 9: The process-centered SOFTMAN Environment
8 Conclusion We have presented the concept of process integration as a strategy for creating processcentered CASE environments and its bene t to software development. Process integration consists of a few key components which form the backbone of a process-centered CASEE. These key components include software process models, a process enactment driver, a developer's interface and a process manager's interface. Process integration supports an open system structure which we believe can be added to other CASEEs with reasonable e ort. To exemplify our strategy to implement process integration, we have successfully migrated the SOFTMAN environment into a process-centered CASEE, which proves the feasibility of our process integration strategy.
References [AHM89] E.W. Adams, M. Honda, and T.C. Miller. Object Management in a CASE Environment. In Proc. of the 11th International Conference on Software Engineering, pages 154{165, Pittsburgh, PA, May 1989. [BGMT89] G. Boudier, F. Gallo, R. Minot, and I. Thomas. An Overview of PCTE and PCTE+. ACM SIGPLAN Notice, pages 226{227, Feb 1989. 11
[CS89] [CS91] [FO91] [GI90] [MS90] [MS91] [Tho89]
S.C. Choi and W. Scacchi. Assuring the Correctness of Con gured Software Descriptions. ACM Software Engineering Notes, 17(7):67{76, 1989. S.C. Choi and W. Scacchi. SOFTMAN: An Environment for Forward and Reverse CASE. Information and Software Technology, 33(9), Nov. 1991. C. Fernstrom and L. Ohlsson. Integration Needs in Process Enacted Environments. Proc. of the 1st International Conference on the Software Process, pages 142{158, Oct 1991. D. Garlan and E. Ilias. Low-cost, Adaptable Tool Integration Policies for Integrated Environments. In Proc. of the 4th ACM SIGSOFT Symposium on Software Development Environments, pages 1{10, Irvine, CA, Dec. 3-5 1990. P. Mi and W. Scacchi. A Knowledge-based Environment for Modeling and Simulating Software Engineering Processes. IEEE Trans. on Knowledge and Data Engineering, 2(3):283{294, Sept 1990. P. Mi and W. Scacchi. Modeling Articulation Work in Software Engineering Processes. Proc. of the 1st International Conference on the Software Process, pages 188{201, Oct 1991. I. Thomas. Tool Integration in the PACT Environment. In Proc. of the 11th International Conference on Software Engineering, pages 13{22, 1989.
12
