Metadata modeling

From Wikipedia, the free encyclopedia

Metadata modeling is a type of metamodeling used in software engineering and systems engineering for the analysis and construction of models applicable and useful some predefined class of problems.

Contents

[edit] Overview

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.

[edit] Metadatamodeling Concepts

First of all, a concept is a simple version of a 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.
  • 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.

Figure 1: STANDARD, OPEN and CLOSED CONCEPTS
Figure 1: STANDARD, OPEN and CLOSED CONCEPTS
Figure 2: Example of STANDARD, OPEN and CLOSED CONCEPTS
Figure 2: Example of STANDARD, OPEN and CLOSED CONCEPTS

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.

[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.

Figure 3: Generalization
Figure 3: Generalization
Figure 4: Example generalization
Figure 4: Example generalization

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.

[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 5.

Figure 5: Association
Figure 5: Association


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”.

[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 7 association with multiplicity is visualized.

Figure 7: Multiplicity
Figure 7: Multiplicity
Figure 8: Example multiplicity
Figure 8: Example multiplicity

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.

[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.

Figure 9: Aggregation
Figure 9: Aggregation
Figure 10: Example aggregation
Figure 10: Example aggregation

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.

[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 11.

Figure 11: Aggregation
Figure 11: Aggregation
Figure 12: Example aggregation
Figure 12: Example aggregation

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

[edit] See also

[edit] References

  1. ^ Booch, Rumbaugh and Jacobson (1999)

[edit] Further reading

  • 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.