Object Oriented Software Process Model Design in E3

Object Oriented Software Process Model Design in E3 Mario Baldi, Silvano Gai, Maria Letizia Jaccheri, Patricia Lago Dipartimento di Automatica e Informatica Politecnico di Torino 10129 Torino Italy November 28, 1993

Abstract The paper introduces a method to design software process models. The method is based on object oriented design extended with a kernel of PM specific classes and relations. A graphical notation to depict process model designs is given together with few structuring and presentation rules.

1 Introduction One of the aims of the E3 project is to devise a method to design process models before implementing them. Initially the object oriented (OO) Coad and Yourdon methodology has been investigated and used to design both the ISPW6 example problem and the software process of a local software organization. The latter software process was described by a textual document of more than one hundred pages. The resulting OO design is based on: 1. a set of kernel classes and relations with PM semantics. Classes identify the root for activity, data, tool, and role submodel; 2. a set of domain specific classes and relations. Once the kernel was identified, it was straighten to obtain the process model design. Thought, the OO design is large and not easily readable by no-specialists. These experiments have demonstrated the traditional OO benefits such as encapsulation, abstraction, and reuse. On the other hand, a PM specific view is needed. The work described in this paper is based on two simple ideas: first different icons are devoted to each kernel class and re-used for its subclasses. Second, four views for process models design organization and structuring are needed: (1) the Inheritance View shows the inheritance tree of each kernel class, (2) the Task View gives the associated data, role, and tool for each task, (3) the Task Decomposition View expands each task into its subtasks,

1

and (4) the User View enables the designer to organize the model by means of non-standard relations. The structure of this paper is as follows: Section 2 gives the background for this work. Section 3 explains the E3 design method by introducing kernel classes and relations, and the process models specific views. Section 4 provides an example. Some conclusions are given in section 5.

2 Motivations The PM community is realizing the need to specify and design process models before implementing them [CFFS92]. The formal mathematics-based methods, among other properties, give the possibility to perform various kinds of proofs. In this work an OO design method has been chosen to be investigated for the following reasons: 1. Process models are complex and difficult to understand, thus structuring mechanisms are essential. 2. OO design does not constrain to use a particular language to proof, simulate, or implement process models. 3. OO approaches [War89] [JC93] have been successfully applied to software process model programming. At the beginning, we started using Coad and Yourdon [CY91a] [CY91b] design methodology, also exploiting the DECdesign [DEC92] automatic design tool. The Coad and Yourdon methodology offers the concepts of Class, Class&Objects, Generalization-Specialization, Whole-Part, Subjects, Attributes, Instance Connections, Services, and Message Connections. The most serious problems we had when trying to apply Coad and Yourdon methodology to PM concern relations. First, relations connecting classes are needed. Coad and Yourdon methodology offers a limited set of relations between classes (e.g. inheritance) and does not allow the designer to define his own relations. Second, we have identified a limited set of relations for the PM domain with a well defined semantics; we found not easy to specify this semantics by the Coad and Yourdon methodology. Moreover, large Coad and Yourdon designs are difficult to understand because the same icons are used for each class. Therefore we have developed a graphical notation that provides four different icons (one for each kernel class) to render immediately recognizable the design semantics to both the process model designer and non-technical persons (e.g. a tool is represented by an hammer, a product component by a book). Kernel class subclasses are depicted as their respective ancestor. Analogously, relations are represented, when possible, by intuitive symbols, e.g. input relation is represented by an arrowed line from task to data. Last, a few presentation rules are given to structure models in a standard way.

2

3 The E3 design method Figure 1 shows the kernel classes and relations. Each class in the model is derived by inheritance from class Object. Task, Role, Data, and Tool, are the roots of the corresponding activity, role, product, and tool submodels. Kernel classes are abstract, as they will never be instantiated, but they are used to create more specialized subclasses. Classes Task, Role, Data, and Tool provide PM specific functionalities. The user-defined classes can acquire these functionalities by inheritance.

3.1 Kernel classes In this section the kernel classes are listed. For each class we give both interface and graphical representation. Class Object Object defines typical OO functionalities of objects. It is drawn as an oval. Classes that cannot be placed in the Task, Tool, Data, or Role submodel, can be declared as subclasses of Object. AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Object AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAA

inheritance

preorder feedback

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Task AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA

input output

Data

responsible

use Tool

subtask Role

Figure 1: Kernel classes and relations. Class Task

3

Software production activities are modeled by Tasks. A Task can be broken down into subtasks (relation subtask). The execution order of sibling tasks is governed by relations feedback and preorder. Task class is graphically represented by a shaded box. Task life passes through a number of states identified by the value of the attribute state. Task class offers a set of operations; the most important ones are listed below. • handleCompletion is called by either a subtask, or a sibling task to notify a calling task state modification. • startExecution is a private method that may be called by handleCompletion to either begin or restart task execution. • restart is invoked by a failed task (connected by feedback relation) to enforce reexecution of the receiver. • readyToInteract notifies the task that the user is ready to interact; this operation is invoked by the object that models the person responsible for the task. Class Role Activities requiring human interaction must be modeled by tasks with an associated role. Binding between tasks and roles is specified at the model level, i.e. a task must be connected by relation responsible to the role that will be in charge of performing it. Role subclasses are depicted as hats. Abstract class Role is not characterized by the services it offers, but by the relations it participates to. Class Data The main objective of a software process is to produce software products. Each development activity may produce partial or final results starting from results of some previous activities. Products can be organized in configurations and can exist in many versions. A configuration management method has not been inserted in the kernel set, but a predefined class library for CM is offered as it will be shown later. Data subclasses are drawn as books. Method beOperated causes the tool connected by relation use to be activated on the data. Class Tool Some development activities are carried on by automatic tools, such as design tools, or compilers. Relation use connects tools to data on which they operate. The binding between tasks and tools is not explicit, but it is obtained through data that tasks take as input or as output. Tool subclasses are depicted as hammers. Class Tool offers operation run that causes execution of the tool.

3.2 Kernel relations

4

In this section semantics and graphical representation of the kernel relations are described. Some relations (e.g. preorder, input, and output) are graphically represented in the same way, because the connected classes are different in each case, e.g. input goes from Data to Task, and vice versa for output. All relations are given between classes as process model designs are built at class level. Nevertheless, when producing an enactable process model, it is necessary to be able to implement relations at both class (as connections between classes), and instance (as connection between objects) level. Each instance level relation must connect objects that belong to classes connected by the corresponding class level relation. Not all class level relations need to have a corresponding instance level relation; in the following relations relevant only at class level will be pointed out. Relation cardinality is not shown in our views because it is implicit in relation semantics. Relation inheritance This is the standard OO inheritance relation. It is also drawn in a standard way as an arrow with forked tail from each specialized class to the general class. inheritance is obviously significant only at class level. Relation subtask A task can be decomposed in subtasks connected to it by relation subtask. Relation subtask is depicted as a non-oriented edge between a task and each of its subtasks. No confusion is possible in distinguishing the supertask from its subtasks as a particular view is provided to show tasks decomposition (see section 3.3). In this view the supertask is drawn above its subtasks. Relations input and output Tasks may take as input, and produce as output, instances of class Data (or of one of its subclasses). In the model this can be specified using relations input and output respectively. Relation input is depicted as an oriented edge from Data subclass to Task subclass. Relation output is drawn as an oriented edge from Task subclass to Data subclass. Relation preorder Often execution order among tasks is implicit via data produced and taken as input by activities. Sometimes in designing process models it is important to impose explicit

5

execution order among tasks. Relation preorder is depicted as an oriented edge between two Tasks. The meaning is that the task connected at the arrow head side cannot begin its execution until the connected task has terminated. Relation feedback The execution of a task can cause another task to restart, e.g. a review phase can restart the related production phase. Relation feedback is drawn as a double arrowed oriented edge from a task to the task that can be restarted. Information about the feedback are contained in a document produced by the task that has caused the reexecution. Each restarted task must take as input the foregoing feedback document1 . Relation responsible Relation responsible is depicted as an edge between a Task subclass and a Role subclass. Relation use Relation use specifies which are the manipulating tools for a given Data. The relation is depicted as an edge between a Data subclass and a Tool subclass, but any of the tools modeled by the related class (or by one of its subclasses) can be used to manipulate the data. Other PM formalisms relate tools to tasks that use them [JC93], but some problems could rise following that approach. • To perform an activity, more than one tool is often needed, e.g. an editing task requires an editor to code a source file as well as a design tool to access design documents. If tools were related to tasks, it would be impossible to know which tool has to operate on each input or output data. • Whenever a new data is related to a task (as either input or output), also a tool suitable for manipulating this data should be related to the task. Not introducing such a relation, will lead to faulty process models. • Some tools store data in a format that is not readable by any other tool. Thus instances of Data subclass that model these data must be related to their creator tool.

1

Relations input and output that involve feedback documents, are not explicitly drawn in process model designs as their existence is implied by the presence of relation feedback.

6

The former two problems concern process modeling and are overcome by means of class level relation use. The latter concerns process model execution and is overcome by using relation use at instance level.

3.3 Presentation rules The E3 process model design method uses kernel classes and relations as building blocks, and enables the user to define new classes as specialization of the kernel classes and new relations. The method is based on the following presentation rules. A process model is composed of four submodels, that are the activity, data, role and tool submodel. Each submodel is derived by inheritance from the corresponding kernel class. The process model designs graphical presentation is structured into four views, called Inheritance View, Task View, Task Decomposition View, and User View. The Inheritance View represents the inheritance hierarchy for a given model. Hence classes result connected by the standard OO inheritance relation, depicted by a plain arrow oriented from a class to its superclass (e.g., see figure 6). The Task View gives an immediate one-level view of the single task functionalities. The Task View represents a task with input and output Data, responsible Role and related Tools. Figure 8 shows Task View for class Design. Class Design is connected to class ReqDoc by relation input and to class DesDoc by relation output. Class ReqDoc is connected to its manipulating tool class that is AnalysisTool while class DesDoc is connected to DesTool. At last, Design is connected to Designer by relation responsible. The Task Decomposition View proposes a two-level view of a task decomposition into its subtasks by subtask relation, along with the feedback and preorder relations controlling subtasks interconnections. The position of the given task in the task breakdown is traced by means of the paths, starting from the root task, that models the whole process. In this way modularization is achieved without loosing in traceability. The User View captures user-defined classes and relations. No specific rules for depicting User Views are given, but they are left to the responsibility of the process model designer. Furthermore, some User Views can be used to specify respectively data, tool, or role oriented process models.

4 An example As an example we give the design for a simple process model whose informal specification is: The software process consists of design, review design, and program.

7

In the developers team there is one project manager, who must assign designers, reviewers and programmers to tasks. He also has to choose the design tool at enactment time. The editor has to be chosen by its user. The review and program phases may start in parallel, but the product cannot be delivered unless both previous phases have been terminated. ReqDoc

Config

AAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA DevProg AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

Editor

ConfEd ProjectManager

Figure 2: Task View of DevProg. The whole process is modeled by task DevProg that takes as input an instance of ReqDoc, produces as output a configuration, and is responsibility of a ProjectManager (figure 2). Figure 3 shows the Task Decomposition View of DevProg. Program in its turn is again decomposed into Edit, Compile, and Link, and AssPers as shown in figure 4. AssPers implements project management facilities. When activated, it interacts with the person responsible for the decomposing task to assign persons to subtasks. The role of the responsible for person allocation is decided at the model level and it can or cannot be the project manager himself. PATH: DevProg

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AssPers SelTool AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA

AAAA AAAAAAAAAAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAA DevProg AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAA

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Design AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAA

AAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA RevDes AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAA

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Program AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAA

Figure 3: Task Decomposition View of DevProg.

8

PATH: DevProg/Program

AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAA AAAAAssPers AAAA AAAA AAAAAAAA AAAAAAAAAAAA AAAAAAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAA AAAA AAAAAAAAAAAA

AAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAA Program AAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA

AAAAAAAA AAAA AAAAAAAAAAAA AAAAAAAA AAAA AAAAAAAAAAAA AAAAAAAA AAAAAAAA Edit AAAAAAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAAAAAAAAAA

AAAAAAAA AAAA AAAAAAAAAAAA AAAAAAAA AAAA AAAAAAAAAAAA AAAAAAAA AAAACompile AAAA AAAAAAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAAAAAAAAAA

AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAA Link AAAA AAAAAAAA AAAAAAAAAAAA AAAAAAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAA AAAA AAAAAAAAAAAA

Figure 4: Task Decomposition View of Program.

Figure 5 shows the Role Inheritance View of the modeled example, whereas figure 6 shows the Data Inheritance View.

Role

ProjectManager

Designer

Reviewer

Figure 5: The Role Inheritance View.

9

Programmer

Data

SWObj Config

ReqDoc

DesDoc

SourceFile

ComFile

ObjFile

ExeFile

Compilable Data

SWObj Config

ReqDoc

DesDoc

Source File

ComFile

ObjFile

Compilable

Figure 6: The Data Inheritance View.

10

ExeFile

Figure 7 shows a User View on Data subclasses: this view describes the product configuration schema. Config models product configurations whose components are Data. The relation component links a configuration to its components. Class level relation depend allow to specify dependencies in the configuration schema. Instance level relation depend connects a document to those documents that are derived from it. E.g., ReqDoc models requirement documents, whereas DesDoc models design documents; depend sets a dependency between these two kinds of documents. The dependency between ReqDoc and DesDoc can also be seen in figure 8 that shows Task View for Design. Task Design takes as input one or more instances of ReqDoc and produces as output an instance of DesDoc. Data

component

ReqDoc

Config

comment

depend

depend Source File

depend

ExeFile

ComFile include DesDoc depend

ObjFile

Compilable

Figure 7: The Data User View. Class Compilable is subclass of SrcFile. It represents source files that may be compiled. A compilable file may include some source files connected by relation use (see fig. 7). A source file may be associated with a comment file represented by an instance of ComFile class connected by relation comment. Class ObjFile models object files obtained by compiling source files connected by relation depend. Compilation involves objects connected by relation include. Instances of ExeFile class represent executable files generated by linking together the object files connected by depend. Figure 9 shows the Tool Inheritance View.

11

ReqDoc

AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA Design AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA

AnalysisTool

DesDoc

DesTool Designer

Figure 8: The Design Task View.

Tool

AnalysisTool

DesTool

ConfEd

Editor

Compiler

Linker

Figure 9: The Tool Inheritance View.

5 Conclusions OO design methods have been extended by two simple ideas to be adapted to process model design. The first idea is to depict tasks, roles, tools, and data in a graphic way. The second one is to structure designs according to a few pre-defined rules. This is similar to what is done by Process Weaver [Fer93] that provides a good graphical notation to specify models structured in three levels (methods, cooperative procedures, and work contexts). The E3 method is general as it is not bound to a specific implementation language, although the models designed so far have been simulated in a simple environment based on the SmallTalk language. Classes used to design process models have been implemented as Smalltalk classes. Also a set of additional classes that provide system functionalities (e.g.

12

user interaction), have been implemented. The execution of the program obtained has led to process model simulation (not enaction) for two main reasons: (1) the execution has been localized on a single machine (with a single user), and (2) tools integration has not been provided. To move from simulation to enaction (still at prototypal level), some classes are now under modification to enhance the implementation with both user interfaces distribution (i.e. multi-user features), and tool integration. ACA Services [Dig92a] [Dig92b] are being exploited to both support communication with remote user interfaces, and integrate tools. The E3 method is suitable also for designing meta-process models. Meta-process specific entities can be modeled either as specialization of PM specific classes (e.g. metatasks can be modeled as specialization of Task), or as generic classes (e.g. meta-data can be direct specialization of Object). The E3 method is not complete because it describes static aspects of models, but it draws little attention on dynamic aspects (e.g. control and instantiation). The new developed E3 method is now been used in the context of a software engineering undergraduate course to specify and guide a reverse engineering process the students are following. This experiment is giving a lot of feedbacks that result in changes to the process model and the meta-model itself, i.e. the software processes design method. We are now also designing an automatic tool for supporting the E 3 design method.

References [CFFS92]

Reidar Conradi, Christer Fernstrom, Alfonso Fuggetta, and Robert Snowdon. Towards a Reference Framework for Process Concepts. In J.-C. Derniame (ed.): Proc. from EWSPT'92, Trondheim, Norway, Springer Verlag LNCS, September 1992.

[CY91a]

Peter Coad and Edward Yourdon. Object-Orineted Analysis. Prentice Hall, Englewood Cliffs, second edition, 1991.

[CY91a]

Peter Coad and Edward Yourdon. Object-Orineted Design. Prentice Hall, Englewood Cliffs, second edition, 1991.

[DEC92]

DEC. Guide to DECdesign. Digital Equipment Corporation, Maynard, Massachusetts. August 1992.

[Dig92a]

Digital Equipment Corporation, Maynard, Massachusetts. DEC ACA Services Reference Manual, April 1992.

[Dig92b]

Digital Equipment Corporation, Maynard, Massachusetts. DEC ACA Services System Integrator and Programmer Guide. April 1992.

13

[Fer93]

Christer Fernström. Process WEAVER: Adding Process Support to UNIX. In Leon Osterweil (ed.): Proc. from 2nd Int'l Conference on Software Process (ICSP'2), March 1993, Berlin. IEEE Press (forthcoming), 1993.

[JC93]

Maria Letizia Jaccheri and Reidar Conradi. Techniques for Process Model Evolution in EPOS. IEEE TSE special issue on Software Process Evolution, December 1993.

[MSW90]

N. Madhavji, W. Schaefer, and H Weber, editors. Proc. of the First International Conference on System Development Environments and Factories - SDEF'89, 9-11 May 1989, Berlin, London. Pitman Publishing, 241 p., March 1990.

[War89]

Brian Warboys. The IPSE 2.5 Project: Process Modelling as the basis for a Support Environment. In [MSW90], 26 p., May 1989.

14