![](bg6.png)
4.2 MDRE Workflow Definition Language
The workflow definition language we used contains only a small subset of modeling
elements of traditional process modeling languages (such as SLANG, SPADE in
[Armenise 93]). In this small language, process, task, role are three basic modeling
elements:
Role: an abstract user assigned with some tasks.
Task: the atomic unit of the process. Task must be associated with some role(s). To
indicate the status of the task, it can carry a return value of Boolean or Integer type.
We define 4 temporal relations between tasks: Begin-Begin (BB), Begin-End (BE),
End-Begin (EB), and End-End (EE). For example, if Task
1
and Task
2
have BB
relation, then the start point of task
2
must be later than the start point of task
1
.
Process: the network of tasks and their relations.
The language ignores the input/output of both tasks and processes in order to ease
the access of documents and work products among users. A potential shortcoming of
this choice is users have to take the responsibilities of maintaining the consistency
between documents and work products. Luckily, it won’t be a tough problem if using
some configuration tools. In the workflow definition language, role is abstract user.
Specific user must be filled in during instantiation. For example in a subordinate
relation, there are only two roles: superior and junior. In workflow enactment, these
abstract roles must be binding to some concrete users.
4.3 Implementation Techniques for Personalized Requirements Reuse
The personalized requirements reuse support is based on three contextual factors: 1)
user-specific behaviors, 2) user stereotype, and 3) user’s task at hand. The techniques
engaged in implementing context-based personalization are: stereotype-based
collaborative filtering, ontology-based semantic search, rule-based user preference
revision. The implementation framework using this technique is illustrated in Fig. 5.
Context is in the left box, containing user behaviors, task description stereotype and
corresponding user preference. As we can see in Fig. 5, user can get two kinds of
knowledge support, task-specific knowledge and preference knowledge. Task-specific
knowledge is derived from task description, while preference knowledge comes from
user stereotype and user behavior.
The process of generating preference knowledge:
1. Retrieve all preference records of past users with the same stereotype;
perform collaborative filtering [herlocker 99] to predict the user’s domain
preference based on those history records and the user’s initial profile.
2. With the user preference, perform ontology-based semantic search on
domain model to retrieve most relevant items.
3. In the RE activities, user behaviors are recorded, with which we can use
rule-based revision to dynamically adjust the user’s preference to count in
user-specific behavior contextual factor.
179