Concepts for Automating Systems Integration
· the method, which specifies the detailed behavior (the actual implementation) of that operation on a particular
object
By definition, a class supports a common set of messages. One class may be described as a
subclass of another, and
it is said to inherit all operations from the base class, that is, every object in the subclass supports all operations of
the base class, and typically has additional operations as well. But object modeling methodologies disagree on
whether a class and its subclasses must also support a common set of methods.
it is said to inherit all operations from the base class, that is, every object in the subclass supports all operations of
the base class, and typically has additional operations as well. But object modeling methodologies disagree on
whether a class and its subclasses must also support a common set of methods.
Object modeling methods also disagree as to whether a class can be modeled as a subclass of more than one base
class. This concept is referred to as multiple inheritance. The underlying issue is whether a model implies that
classes not described as having a common inheritance relationship must be disjoint. Such a rule is convenient for
implementations, but requires unnatural models of some real-world situations.
class. This concept is referred to as multiple inheritance. The underlying issue is whether a model implies that
classes not described as having a common inheritance relationship must be disjoint. Such a rule is convenient for
implementations, but requires unnatural models of some real-world situations.
The properties and relationships of a class can be deduced from the set of operations the class must support. In
many cases, the requirement to have a particular property is made evident by an operation that returns the value of
that property. The representations of properties and relationships in an implementation are chosen to optimize the
methods that use them. They are said to be encapsulated in the object implementation, and are of little interest to
the model.
many cases, the requirement to have a particular property is made evident by an operation that returns the value of
that property. The representations of properties and relationships in an implementation are chosen to optimize the
methods that use them. They are said to be encapsulated in the object implementation, and are of little interest to
the model.
Many object modeling methods distinguish between
primitive types (the types of machine-representable information
units), and abstract types (the types for which operations are modeled). This distinction gives rise to rules about
what is encapsulated and what is not, and what types can appear where in messages.
units), and abstract types (the types for which operations are modeled). This distinction gives rise to rules about
what is encapsulated and what is not, and what types can appear where in messages.
The principal object-oriented modeling methodologies are named after the authors of the books in which they were
introduced -- Rumbaugh [92], Booch [93], Schlaer-Mellor [94], Jacobsen [95]. In the late 1990s, however, a group
of the prominent authors and tool vendors came together to create a standard object-modeling language, called the
Unified Modeling Language (UML) [80], which is now in common use. The UML "static structure diagram" is a
conventional object-oriented modeling language, with a few minor additions. But UML also includes a number of
other graphics languages that borrow from each other's concepts, including languages for process and activity
models, information flows, use cases (scenarios), and a number of implementation-oriented modeling concerns.
introduced -- Rumbaugh [92], Booch [93], Schlaer-Mellor [94], Jacobsen [95]. In the late 1990s, however, a group
of the prominent authors and tool vendors came together to create a standard object-modeling language, called the
Unified Modeling Language (UML) [80], which is now in common use. The UML "static structure diagram" is a
conventional object-oriented modeling language, with a few minor additions. But UML also includes a number of
other graphics languages that borrow from each other's concepts, including languages for process and activity
models, information flows, use cases (scenarios), and a number of implementation-oriented modeling concerns.
UML models, which have a standard semantic foundation and a standard exchange form (XMI
[81]) are likely to be
the primary form of formal specification of the interfaces to components, and they may also be used in defining
information sets and specifying some behaviors.
the primary form of formal specification of the interfaces to components, and they may also be used in defining
information sets and specifying some behaviors.
6.3.4 Meta-models and model integration
As modeling languages have become a significant element in software systems design, both software engineers and
their tools are expected to use the models as prescriptions for the corresponding software elements. This creates
significant pressure to formalize the semantics of the modeling languages, which are captured in the text
descriptions in the language manual, in order to ensure that the model is consistently interpreted. A related objective
of this effort is to permit a translation, or a partial translation, of the information from one model into another, which
may be represented in a different language. This makes it necessary to have a formal model of the semantic
concepts of the modeling language. Such a model is said to be a meta-model for the modeling language.
their tools are expected to use the models as prescriptions for the corresponding software elements. This creates
significant pressure to formalize the semantics of the modeling languages, which are captured in the text
descriptions in the language manual, in order to ensure that the model is consistently interpreted. A related objective
of this effort is to permit a translation, or a partial translation, of the information from one model into another, which
may be represented in a different language. This makes it necessary to have a formal model of the semantic
concepts of the modeling language. Such a model is said to be a meta-model for the modeling language.
We examine meta-models here, because they may provide a formal basis for interpreting a modeling language, and
therefore a means for interpreting the models specified in it.
therefore a means for interpreting the models specified in it.
There are two common approaches to the construction of meta-models: use of the modeling language to model its
own concepts, and use of a language specifically intended for meta-models.
own concepts, and use of a language specifically intended for meta-models.
Use of the language to model itself
For information modeling languages (and other modeling languages of which information is a part), it is possible to
capture the concepts and many of the conceptual rules of the modeling language in the language itself. A model is
itself a set of information; and that information can be modeled in the information modeling language. This
approach has been used for the Object Role Model [99] and for EXPRESS [20].
capture the concepts and many of the conceptual rules of the modeling language in the language itself. A model is
itself a set of information; and that information can be modeled in the information modeling language. This
approach has been used for the Object Role Model [99] and for EXPRESS [20].
60