Meta-modeling technique
From Wikipedia, the free encyclopedia
Contents |
[edit] Sequential activities
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 2-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 2-1.
In Figure 2 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.
[edit] 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 2-3.
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 2-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.
[edit] 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 van occur concurrently. In the example of Figure 2-5, Activity 2 and Activity 3 are concurrent activities.
In Figure 2-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.
[edit] 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 2-7 two conditional activities are illustrated.
In Figure 2-8 an example from practice is illustrated. A requirements analysis starts with studying the material. Based on this study, the decision is taken whether to do an extensive requirements elicitation session or not. The condition for not carrying out this requirements session is represented at the left of the branch, namely [requirements clear]. If this condition is not met, [else], the other arrow is followed.
[edit] MetaData modeling
The meta-data side of the diagram consists of a concept diagram. This is basically an adjusted class diagram as described Booch, Rumbaugh and Jacobson (1999). Important notions are concept, generalization, association, multiplicity and aggregation.
[edit] Concepts
First of all, a concept is a simple version of a UML class. The class definition of Booch, Rumbaugh and Jacobson (1999) is adopted to define a concept, namely: a set of objects that share the same attributes, operations, relations, and semantics.
The following concept types are specified:
- STANDARD CONCEPT: a concept that contains no further (sub) concepts. A standard concept is visualized with a rectangle.
- COMPLEX CONCEPT: a concept that consists of a collection of (sub) concepts. Complex concepts are divided into:
- OPEN CONCEPT: a complex concept whose (sub) concepts are expanded. An open concept is visualized with two white rectangles above each other.
- CLOSED CONCEPT: a complex concept whose (sub) concepts are not expanded since it is not relevant in the specific context. A closed concept is visualized by a white rectangle above a black rectangle.
In Figure 3-1 the three concept types that are used in the modeling technique are illustrated. Concepts are always capitalized, not only in the diagram, but also when referring to them outside the diagram.
In Figure 3-2 all three concept types are exemplified. Part of the process-data diagram of the requirements workflow in the Unified Process is illustrated. The USE CASE MODEL is an open concept and consists of one or more ACTORS and one or more USE CASES. ACTOR is a standard concept, it contains no further sub-concepts. USE CASE, however, is a closed concept. A USE CASE consists of a description, a flow of events, conditions, special requirements, etc. Because in this case it is unnecessary to reveal that information, the USE CASE is illustrated with a closed concept.
[edit] Generalization
Generalization is a way to express a relationship between a general concept and a more specific concept. Also, if necessary, one can indicate whether the groups of concepts that are identified are overlapping or disjoint, complete or incomplete. Generalization is visualized by a solid arrow with an open arrowhead, pointing to the parent, as is illustrated in Figure 3-3.
In Figure 3-4 generalization is exemplified by showing the relationships between the different concepts described in the preceding paragraph. STANDARD CONCEPT and COMPLEX CONCEPT are both a specific kind of CONCEPT. Subsequently, a COMPLEX CONCEPT can be specified into an OPEN CONCEPT and a CLOSED CONCEPT.
[edit] Association
An association is a structural relationship that specifies how concepts are connected to another. It can connect two concepts (binary association) or more than two concepts (n-ary association). An association is represented with an undirected solid line. To give a meaning to the association, a name and name direction can be provided. The name is in the form of an active verb and the name direction is represented by a triangle that points in the direction one needs to read. Association with a name and name direction is visualized in Figure 3-5.
In Figure 3-6 an example of association is illustrated. The example is a fragment of the process-data diagram of the requirements analysis in the Unified Process. Because both concepts are not expanded any further, although several sub concepts exist, the concepts are illustrated as closed concepts. The figure reads as “SURVEY DESCRIPTION describes USE CASE MODEL”.
[edit] Multiplicity
Except name and name direction, an association can have more characteristics. With multiplicity one can state how many objects of a certain concept can be connected across an instance of an association. Multiplicity is visualized by using the following expressions: (1) for exactly one, (0..1) for one or zero, (0..*) for zero or more, (1..*) for one or more, or for example (5) for an exact number. In Figure 3-7 association with multiplicity is visualized.
An example of multiplicity is represented in Figure 3-8. It is the same example as in Figure 3-6, only the multiplicity values are added. The figure reads as ‘exactly one SURVEY DESCRIPTION describes exactly one USE CASE MODEL’. This implies that a SURVEY DESCRIPTION cannot describe zero or more than one USE CASE MODEL and a USE CASE MODEL cannot be described by zero or more than one SURVEY DESCRIPTIONS.
[edit] Aggregation
A special type of association is aggregation. Aggregation represents the relation between a concept (as a whole) containing other concepts (as parts). It can also be described as a ‘has-a’ relationship. In Figure 3-9 an aggregation relationship between OPEN CONCEPT and STANDARD CONCEPT is illustrated. An OPEN CONCEPT consists of one or more STANDARD CONCEPTS and a STANDARD CONCEPT is part of one OPEN CONCEPT.
In Figure 3-10 aggregation is exemplified by a fragment of the requirements capture workflow in UML-Based Web Engineering. A USE CASE MODEL consists of one or more ACTORS and USE CASES.
[edit] Properties
Sometimes the needs exist to assign properties to concepts. Properties are written in lower case, under the concept name, as is illustrated in Figure 3-11.
In Figure 3-12 an example of a concept with properties is visualized. The concept FEATURE has four properties, respectively: priority, type, risk and status.
In Table 3-1 a list presented Each CONCEPT requires a proper definition which is preferably copied from a standard glossary. All CONCEPT names in the text are with capital characters.
Table 3-1: Concept definition list
| Concept | Definition |
| CONCEPT A | This is a definition of CONCEPT A |
| CONCEPT B | This is a definition of CONCEPT B |
[edit] Process-data diagram
The integration of both types of diagrams is quite straightforward. Each action or activity results in a concept. They are connected with a dotted arrow to the produced artifacts, as is demonstrated in Figure 4-1. The concepts and activities are abstract in this picture.
In Table 4-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 4-1: Activity table
| Activity | Sub-Activity | Description |
| Activity 2 | Sub-activity 4 | Sub-activity 4 results in a STANDARD CONCEPT |
[edit] Example of a process-data diagram
In Figure 4-2 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).
Notable is the use of open and closed concepts. Since project management is actually not within the scope of this research, the concept CONTROL MANAGEMENT has not been expanded. However, in a complex project is RISK MANAGEMENT of great importance. Therefore, the choice is made to expand the RISK MANAGEMENT concept.
In Table 5-1 the activities and sub-activities, and relation to the concepts are described.
Table 5-1: Activities and sub-activities in a complex orientation phase
| Activity | Sub-Activity | Description |
| Describe Project | Describing the project is done in terms of participants, targets, products, scope and assumptions. This information is derived from the proposal, but with more emphasis on the project management issues. The activity end in a project DESCRIPTION. | |
| Construct planning | Describe project phases | The PLANNING is divided into five PROJECT PHASES, which should be shortly described. |
| Construct planning | Describe activities | The project ACTIVITIES are described and grouped into PROJECT PHASES. |
| Construct planning | Describe deliverables | The DELIVERABLES that result from the project ACTIVITIES are described. |
| Construct planning | Set up schedule | For every DELIVERABLE a DATE is set and for each ACTIVITY a TIME SLOT is estimated. |
| Control project | Controlling the project results in a CONTROL MANAGEMENT artifact. This artifact is not further explained here, since it concerns regular project management issues, like communication management, progress management, change management and problem management that lie outside the scope of this research. | |
| Control risk | Identify risks | Identifying risks can be done by using standard checklists or organizing risk workshops. The RISKS are included in the PROJECT PLAN. |
| Control risk | Evaluate risks | Every RISK is provided with an EVALUATION; a description and estimation about the complexity or uncertainty of a project is given. |
| Control risk | Analyze impact | Analyzing the impact of a risk handles about the IMPACT, a risk has on the success of a project. The evaluation and risk values are indicated by selecting a value: low, moderate or high. |
| Control risk | Prioritize risks | Prioritizing the risks is done by combining IMPACT and EVALUATION in a table. High priority is then given to RISKS with the highest scores. |
| Define actions for risk strategy | Risk strategy actions can be obtained from experience or from relevant literature. The project manager adapts the actions to the project in the ACTION LIST FOR RISK STRATEGY. RISKS with the highest priority are on top of the list and need to be handled first. |
[edit] References
- Saeki M. (2003). Embedding Metrics into Information Systems Development Methods: An Application of Method Engineering Technique. CAiSE 2003, 374-389.
- Weerd, I. van de, Souer, J., Versendaal, J., Brinkkemper, S. (2005). Situational Requirements Engineering of Web Content Management Implementations. SREP2005.
