Content deleted Content added
No edit summary |
m WP house style |
||
Line 1:
{{mergeto|Meta-modeling}}
The following discussion can be viewed as a detailed application of [[Meta-modeling|metamodeling]] techniques, related to [[Model Driven Engineering]]. In software engineering, data engineering and software engineering, the use of [[Model|models]] is more and more recommended. this should be contrasted with the classical code-based development techniques. A [[Model|model]] always conform to a unique [[Meta-model|metamodel]]. One of the currently most active branch of [[Model Driven Engineering]] is the approach named [[Model Driven Architecture]] proposed by [[OMG]]. This approach is based on the utilization of a language to write metamodels called the [[Meta-Object Facility|Meta Object Facility or MOF]]. Typical metamodels proposed by [[OMG]] are [[UML]], SysML, SPEM or CWM. All the languages presented below could be defined as MOF [[Meta-model|metamodels]].
Line 9 ⟶ 8:
A '''metamodeling technique''' is an approach used to model activities and artifacts in a development process, using process-data diagrams. Saeki (2003) proposed the use of such a metamodeling technique for the purpose of attaching semantic information to the artifacts and for measuring their quality using this information. The modeling technique is adopted to reveal the relations between activities (the process) and artifacts (the data produced in the process). A process-data diagram consists of two integrated diagrams. The left-hand side of the diagram is based on a UML activity diagram, and the right-hand side of the diagram is based on a UML class diagram.
=== MetaProcess
Metaprocess modeling is done by adapting the UML activity diagram. According to Booch, Rumbaugh and Jacobson (1999), an activity diagram is “a diagram that shows the flow from activity to activity; activity diagrams address the dynamic view of a system”. This diagram consists of activities and transitions. If necessary, activities can be divided into sub-activities. Transitions can be used to show the path from one activity to the next. A simple arrow depicts this. Four types of activities exist: unordered, sequential, concurrent and conditional activities.
====Sequential
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.
Line 23 ⟶ 22:
====Unordered
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.
Line 32 ⟶ 31:
====Concurrent
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.
Line 42 ⟶ 41:
====Conditional
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.
Line 50 ⟶ 49:
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.
===MetaData
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.
Line 133 ⟶ 132:
|}
===Process-
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.
Line 154 ⟶ 153:
|}
====Example of a
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).
Line 217 ⟶ 216:
|}
==
* Booch, G., Rumbaugh, J., Jacobson, I. (1999). The Unified Modeling Language User Guide. Redwood City, CA: Addison Wesley Longman Publishing Co., Inc.▼
* 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.▼
* [[Model Driven Engineering]] (MDE)
* [[Model Driven Architecture]](MDA)
Line 233 ⟶ 226:
* [[QVT|MOF Queries/Views/Transformations]] (MOF QVT)
* [[Transformation language]]
==References==
▲* Booch, G., Rumbaugh, J., Jacobson, I. (1999). The Unified Modeling Language User Guide. Redwood City, CA: Addison Wesley Longman Publishing Co., Inc.
▲* 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.
| |||