Metadata modeling is a type of metamodeling used in software engineering and systems engineering for the analysis and construction of models applicable to and useful for some predefined class of problems.
Meta-modeling is the analysis, construction and development of the frames, rules, constraints, models and theories applicable and useful for the modeling in a predefined class of problems.
The meta-data side of the diagram consists of a concept diagram. This is basically an adjusted class diagram as described in Booch, Rumbaugh and Jacobson (1999). Important notions are concept, generalization, association, multiplicity and aggregation.
Metadatamodeling Concepts
First of all, a concept is a simple version of a Unified Modeling Language (UML) class. The class definition[1] 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. (Correction: An open concept is visualized with 2 white rectangles, 1 overlaid over the other, offset to the right, with 3 corners of the rectangle beneath visible. )
- 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 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 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.
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.
In Figure 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.
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 illustrated in Figure 5.
In Figure 6 (removed) 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”.
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 7 association with multiplicity is illustrated.
An example of multiplicity is represented in Figure 8. It is the same example as in Figure 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.
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 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 zero or more OPEN CONCEPT.
In Figure 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.
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 11.
In Figure 12 an example of a concept with properties is visualized. The concept FEATURE has four properties, respectively: priority, type, risk and status.
In Table 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 1: Concept definition list
Concept Definition CONCEPT A This is a definition of CONCEPT A CONCEPT B This is a definition of CONCEPT B
See also
References
- ↑ Booch, Rumbaugh and Jacobson (1999)
Further reading
- Grady Booch, James Rumbaugh and Ivar Jacobson (1999). The Unified Modeling Language User Guide. Redwood City, CA: Addison Wesley Longman Publishing Co., Inc.
- M. Saeki (2003). Embedding Metrics into Information Systems Development Methods: An Application of Method Engineering Technique. CAiSE 2003, 374–389.
- I. Weerd, J. van de, Souer, J. Versendaal and Sjaak Brinkkemper (2005). Situational Requirements Engineering of Web Content Management Implementations. SREP2005.