META PROCESS MODEL

In this section we demonstrate a task sequence to constitute a process model, in other words the process model of process modelling. We show that it is very useful to structure a process model as a task sequence, which we present in a tabular form as shown in table 6.2. The following description uses perform(dynamicModel) as an example to show the order of task modelling. This illustration includes tasks 1.2.1 to 1.2.5 of the OMT analysis phase sequence. There are five main steps in process modelling:

• identifying tasks with the associated operations • determining event triggers amongst the tasks

• identifying concept tokens required in current abstraction • determining inflows and outflows of concept tokens

• identifying tasks requiring decomposition and repeating the previous four steps

Identifying tasks with the associated operations: In those methods that provide design steps or sequences, the top level tasks are normally carefully defined. Most tasks can be formulated into the first six task functions (or operations) given in section 6.5. Then for each operation appropriate context parameters are associated, these conceptTokens can be interchanged with the concepts in product model. Table 6.3 demonstrates how to identify tasks and operations in OMT’s dynamicModel:

No Task Context Parameter Original Description

1.2.1 insert scenario prepare scenarios of typical interaction sequences

1.2.2 insert event identify events between objects

1.2.3 insert eventTrace prepare an event trace for each scenario

1.2.4 draw stateDiagram build a state diagram

1.2.5 refine event, object match events between objects to verify consistency

Determining event triggers amongst the tasks: Each task in a sequence is an iterative process. In this step event triggers amongst tasks are identified. These triggers may appear in different forms, such as cascade tasks, parallel tasks or recursive tasks. Guard conditions are not implemented at this stage, so the triggers present just the order of task execution. In our

dynamicModel example the task sequence is in a linear form as shown in figure 6.15. Table 6.3 Step 1: OMT dynamicModel Tasks and Operations

draw stateDiagrarr determ ine

scenario determineevent eventTracedetermine refineevent Figure 6.15 Step 2: OMT dynamicModel Task Sequence

Identifying concept tokens required in current abstraction: In this step the precondition and postcondition of each task is considered. The concepts required for the task are shown as precondition tokens. The concepts formed after the task are shown as postcondition tokens. These tokens relate the tasks in the sequence. It is important to keep these tokens as concise as possible so that the tasks can remain in the same level of abstraction. Table 6.4 illustrates the concept tokens of OMT dynamicModel. Notice that the context parameters are not necessarily equivalent to the tokens in either the task precondition or the postcondition. However, if the function is insert, draw or specify, the consequence of the function is most likely to be the context parameters described, as shown in task 1.21 to task 1.2.4.

No Task Context Parameter Precondition Postcondition

1.2.1 insert scenario requirement scenario

1.2.2 insert event scenario event

1.2.3 insert eventTrace scenario, event eventTrace

1.2.4 draw stateDiagram event stateDiagram

1.2.5 refine event, object stateDiagram, object -

Table 6.4 Step 3: OMT dynamicModel Concept Tokens

Determining inflows and outflows of concept tokens: After identifying the concept tokens, determining the input/output concept flows is simply a matter of mapping from the precondition and postcondition columns of the task sequence table to the task diagram. An input concept flows to a condition box shows the precondition, whereas an output flows from an operation box depicts the postcondition. Figure 6.11 shows the complete top level task diagram of OMT dynamicModel.

Identifying tasks requiring decomposition and repeating the previous four steps: Task decomposition (section 6.7.4) is an important notion in process modelling. A decomposed task diagram gives a low level of abstraction about the task, so the detail concept tokens of the task are displayed. Figure 6.12 illustrates the decomposed draw(stateDiagram) task.

6.9 META META MODEL

It would prove useful to show the meta model of both the product model and the process model, which is the meta meta model. The product model discussed in the previous chapter can be described graphically by concept diagram. However, the process model discussed in this chapter can be tabulated in the task sequence as well as depicted in the task diagram. In order to reduce unnecessary confusion, table 6.5 shows a map for this meta meta model. It reads as ‘the concept diagram of product model is shown in figure 5.32\ which is the shaded area in the table. This figure is shown in chapter five and others are displayed in this section.

Meta Model Product Model Process Model Concept Diagram Figute 5.32 Figure 6.17

Task Sequence Table 6.6 Table 6.7

Task Diagram Figure 6.16 Figure 6.18

Table 6.5 A Map for Meta Meta Model

The formation of a product model is demonstrated in section 5.5. It is a seven step task sequence. Table 6.6 shows that the tasks in the product model are fairly independent. Apart from the incremental sequence, the only requirement is the concept token. The task diagram of the product model is shown in figure 6.16. It is worth noting that the precondition to start the product modelling is the knowledge acquisition of method engineering, which is discussed in chapter ten.

Task Context Parameter Precondition Postcondition

insert fragment - concept

insert entity concept subtyping, composition

insert linking concept subtyping, linking

insert property concept subtyping, composition

insert grouping concept grouping

insert referencing concept referencing

specify constraintRule concept constraintRule

Table 6.6 Task Sequence of Product Model

subtyping

(Referencing^) (^constraintRule^ grouping

linking

determine

fragment determineentity determinelinking determineproperty determinegrouping referencingdetermine _{constraintRule}specify

concept

Figure 6.16 Task Diagram of Product Model

Figure 6.17 shows the concept diagram of a process model. The following points are made about this product model:

• Each task has an operation, which is one of the nine task functions. These functions are denoted as subtypes of the taskFunction.

• There are two constrainedConcepts in the process model. The contextParameter is constrained since it depends on the type of task function, whereas conceptFlow is a dataflow from task to conceptToken or vice versa.

• A trigger is a link connecting an event to a taskFunction. If the taskFunction is conditional, the event will trigger the condition instead.

• The taskDiagram and conceptDiagram are the two main fragments of the meta model. The taskDiagram relates to the conceptDiagram through the conceptToken, which itself refers to a concept in a conceptDiagram.

taskDiagram 7\ taskDecomposition

I

T

event

7TC

task

1

concept conceptToken ^ eventState eventPrestate eventPoststate 7\ A A V s t \ l / s t V V contextParam eter c conceptFlow

I

s V V t v t

taskFunction[perform] do draw [specify] insert ] delete) modify) [adjust retype trigger « condition <4

Figure 6.17 Concept Diagram of Process Model

Task Context Parameter Precondition Postcondition

insert task - task, operation, condition

insert trigger task, condition trigger, event

insert conceptToken task, condition conceptToken

insert conceptFlow task, conceptToken conceptFlow

insert taskDecomposition task taskDecomposition

Table 6.7 Task Sequence of Process Model

taskDecomposition conceptToken

trigger conceptFlow

insert

task triggerinsert _conceptTokeninsert _conceptFlowinsert taskDecompositioninsert

event operation

Section 6.8 demonstrates the formation of a process model, which can be described by a five step task sequence as shown in table 6.7. Figure 6.18 depicts the process model in a task diagram.

6.10 CONCLUSION

This chapter presented a generic process model of SDMs. Unlike the product model, the process model is loosely defined in order to provide flexibility and freedom for developer creativity. This is needed because most SDMs have only a coarse grain description on method processes, and some of them are described implicitly. The structure of a task and different types of task functions are identified. Task sequence is also introduced to document the process model in a tabular form, which maps easily to a task diagram. This diagram is based on the Ptech event schema notion, with extensions to model conceptToken and conceptFlow.

We have tried out this process model with five methods. The result is encouraging, since the generic representation has sufficient capability to capture method processes as well as allowing the customisation of fine grain processes.

Chapter five and this chapter describe the structural and behavioural aspects of method models in graphical form. The textual form is presented by a unique method specification language. In the next chapter, we look at the heuristic model that accompanies the product and the process models.

In document A generic model for representing software development methods (Page 159-164)