Semantic Requirements Engineering - Intentional Perspectives on Information Systems Engineering - page 71

would be included in the meta model of sequence diagrams. And she or he tries to
map “causes” relationship between the messages “up” and “open” into the associa-
tion of type “next” of the ontology. However, no events but Stop can be executed just
after Move is executed because the ontology of Fig. 3 specifies that Move has only
one outgoing “next” relationship to Stop. Thus the inference rule on the ontology
suggests that there are no “next” relationships between Move and Open and some
events should be added to keep semantic consistency of execution order “next” rela-
tionship. Obviously, in this case the analyst should add the message Stop between
“up” and “open”, which a Lift object sends to a Door object. The used inference
rule is “If there is a next relationship between the concepts A and B in the ontology,
then the elements mapped to A and B in the model, if any, should have the associ-
ation mapped to next among themselves”. Thus, we can solve the problems related
to semantic incorrectness, illustrated in Sect. 1, using an ontology as a semantic
domain.
We will show another example in a different subject domain below. In the above
example, we used the ontology of lift control domain, i.e. a problem domain where
the system to be developed operates. On the other hand, this second example needs
the ontology of meta models to provide semantics of meta models to help a method
engineer (engineer for developing meta models) in constructing a meta model of
semantically higher quality. A meta model defines an IS development method,
and the quality of the meta model is a significant factor to get a useful devel-
opment method [ 1, 12] . In usual cases, a method engineer usually selects pieces
of meta models called method chunks or method fragments, and assembles them
into a development method suitable for an IS development project [ 2, 10] . In this
process, the method engineer should avoid constructing meaningless methods or
semantically inconsistent ones.
Consider a simple example of a meta model of Sequence Diagram of UML. The
left part of Fig. 4 depicts the meta model of Sequence Diagram, and it consists
of several method concepts such as Data, Message and Object, and relationships
among them, e.g. send, receive and carry. Note that, for simplicity, we used Class
Diagram to represent this meta model. We will check the semantic consistency of
the meta model using the ontology as mentioned above. We design an ontology for
meta models, called meta model ontology , and the right part of Fig. 4 depicts a part
of a meta model ontology, which is a simplified version of [ 4] . The meta model
ontology can give the meaning of the elements of a meta model in the same way as
the technique mentioned above. Therefore, a subject domain of the ontology is the
domain of meta models. While developing a meta model, a method engineer maps
its elements into a part of the meta model ontology. In the example of the figure,
she or he maps Data and Message in the meta model into the ontological concepts
Data and Event respectively. The relationship “carry” between Data and Message
can be mapped into “associate”, because “associate” is a relationship between Data
and Event in the meta model ontology. The relation among these three elements
Data, Message and “carry” is consistent. However, there are no self-relationships on
Message, while the meta model ontology has a self-relationship “next” on Event,
which Message is mapped into. This can be semantically inconsistent and the