Content deleted Content added
Moved section from the metamodeling article |
→Meta-modeling technique: Some more structure |
||
Line 8:
== Meta-modeling technique ==
=== Sequential activities ===
{{main|Activity diagram}}
Sequential activities are activities that need to be carried out in a pre-defined order. The activities are connected with an arrow, implying that they have to be followed in that sequence. Both activities and sub-activities can be modeled in a sequential way. In Figure 1 an activity diagram is illustrated with one activity and two sequential sub-activities. A special kind of sequential activities are the start and stop states, which are also illustrated in Figure 1.
Line 15 ⟶ 16:
In Figure 2 an example from practice is illustrated. The example is taken from the requirements capturing workflow in UML-based Web Engineering. The main activity, user & ___domain modeling, consists of three activities that need to be carried out in a predefined order.
==== Unordered activities ====
Unordered activities are used when sub-activities of an activity do not have a pre-defined sequence in which they need to be carried out. Only sub-activities can be unordered. Unordered activities are represented as sub-activities without transitions within an activity, as is represented in Figure 3.
Line 23 ⟶ 24:
In some specific cases an activity exists of sequential and unordered activities. The solution to this modeling issue is to divide the main activity in different parts. In Figure 4 an example is illustrated, which clarifies the necessity to be able to model unordered activities. The example is taken from the requirements analysis workflow of the Unified Process. The main activity, “describe candidate requirements”, is divided into two parts. The first part is a sequential activity. The second part consists of four activities that do not need any sequence in order to be carried out correctly.
==== Concurrent activities ====
Activities can occur concurrently. This is handled with forking and joining. By drawing the activities parallel in the diagram, connected with a synchronization bar, one can fork several activities. Later on these concurrent activities can join again by using the same synchronization bar. Both activities and sub-activities can occur concurrently. In the example of Figure 5, Activity 2 and Activity 3 are concurrent activities.
Line 31 ⟶ 32:
In Figure 6, a fragment of a requirements capturing process is depicted. Two activities, defining the actors and defining the use cases, are carried out concurrently. The reason for carrying out these activities concurrently is that defining the actors and the use cases influences each other to a high extend.
==== Conditional activities ====
Conditional activities are activities that are only carried out if a pre-defined condition is met. This is graphically represented by using a branch. Branches are illustrated with a diamond and can have incoming and outgoing transitions. Every outgoing transition has a guard expression, the condition. This guard expression is actually a Boolean expression, used to make a choice which direction to go. Both activities and sub-activities can be modeled as conditional activities. In Figure 7 two conditional activities are illustrated.
Line 46 ⟶ 47:
In Table 1 a generic table is presented with the description of activities, sub-activities and their relations to the concepts. In section 5 examples are given of both process-data diagram and activity table.
:'''Table 1: Activity table'''
:{| class="wikitable"
|- bgcolor="#ccccff"
Line 59 ⟶ 60:
|}
==== Example of a process-data diagram ====
In Figure 10 an example of a process-data diagram is illustrated. It concerns an example from a the orientation phase of complex project in a WebEngineering method (Van de Weerd, Souer, Versendaal & Brinkkemper).
Line 68 ⟶ 69:
In Table 2 the activities and sub-activities, and relation to the concepts are described.
:'''Table 2: Activities and sub-activities in a complex orientation phase'''
:{| class="wikitable"
|- bgcolor="#ccccff"
| |||