Content deleted Content added
No edit summary |
No edit summary |
||
Line 4:
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]]. All the languages presented below could be defined as MOF [[Meta-model|metamodels]].
== Examples of metamodeling approaches==
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 Modeling ===
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 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.
Line 20 ⟶ 21:
====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.
Line 29 ⟶ 30:
====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.
Line 39 ⟶ 40:
====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.
Line 47 ⟶ 48:
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 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.
====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.
Line 70 ⟶ 71:
====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.
Line 79 ⟶ 80:
====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.
Line 88 ⟶ 89:
====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.
Line 97 ⟶ 98:
====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.
Line 106 ⟶ 107:
====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.
Line 151 ⟶ 152:
|}
===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).
Line 214 ⟶ 215:
|}
===References===
* Booch, G., Rumbaugh, J., Jacobson, I. (1999). The Unified Modeling Language User Guide. Redwood City, CA: Addison Wesley Longman Publishing Co., Inc.
| |||