An example of process description in HFSP

• Authors: Takuya Katayama;Masato Suzuki
• Venue: ISPW '90 Proceedings of the 5th international software process workshop on Experience with software process models
• Year: 1990

HFSP considers software activities, in the first approximation, as mathematical functions which map their input objects to output objects and define them though hierarchical functional definition. Activity A with input x1, …, xn and output y1, …, ym is denoted by A(x1, …, xn | y1, …, ym). Execution of A is performed functionally and it does nothing other than computing y1, …, ym from x1, …, xn. We call x1, … xn, y1, … ym attributes of A. If the activity is complex and cannot be performed by simply invoking tools, we have to decompose it into subactivities. We continue this decomposition process until every activity resulted from decomposition becomes a primitive one which could be performed by invoking existing tools or performed by human mental activity such as thinking or decision making.Activity decomposition must specify how an activity, say A, is decomposed into subactivities A1, … Ak and what relationship E holds among attributes of the activities involved. It also has to specify the condition C when this decomposition can happen. A ⇏ A1, …, Ak when C where E. Figure 1 shows a HFSP description of a simplified version JSP process where every step can be completed successfully. It consists of type definition, object and tool definition and activity definition part. The activity definition part defines JSP process as a set of activity decompositions. It also specifies how attributes are bind to the values of objects in the objectbase and this is described in the with section using get and put. For the activities defined here, no decomposition condition is attached as every activity is decomposed uniquely.Explicit definitions for attributes are omitted in this example as we use the following convention: When an output attribute y of an activity Ai is given to another activity Aj as one of its input attribute x, we omit the attribute definition x = y. Instead, we put y for x in Aj. We also used the convention that the name of a type is used as the name of an attribute of the type. If there are several attributes of the same type, we distinguish them by attaching modifier of the form `.xxx` to the type, like in `dataTree.in` and `dataTree.out`.This process description is only valid for the case that we never make a mistake in performing activities and the specification given is simple enough. Redoing is introduced in HFSP to handle the cases when these conditions are not met[2,3]. Figure 2 is an example of a redoing decomposition applied to the case where (1) extracting data structure is mistaken in `MakeProgTree` step, (2) it is detected in `ComposeTree' and (3) `MakeProgTree` has to be redone. In Figure 3, redoing is used to cope with structure clash. `OrderCarsh` found in `ComposeTree` is handled by redoing `MakeProgTree`.