Modeled Domain - modelint/shlaer-mellor-metamodel GitHub Wiki

There are many excellent (and not so excellent) modeling languages one can use to define all or part of a Domain. We define a modeled domain as one that can be populated into a Shlaer-Mellor metamodel and, hence, a Shlaer-Mellor domain. From our metamodel's perspective, anything else is opaque and, hence, a Realized Domain instead. So whether you've built up a domain using C++ or Simulink, it's all the same from our metamodel's perspective.

images/domain-subsystem/modeled-domain-10.png

The important thing to understand about a Modeled Domain is that it constitutes a cohesive collection of Classes and Relationships. This represents an object-oriented analysis of a system without regard to the implementation platform. A Domain may be implemented in its own task, or in fifty tasks, or possibly in one task with all of the other Domains in the system. A separate marking model may show how a given set of Modeled Domains are deployed onto physical execution units. This same flexibility is not usually applicable to Realized Domains.

The complete absence of deployment consideration on a domain chart (a collection of Domains and Bridges for a particular system) is platform independent. This means that the organization of a domain chart should survive ongoing changes in the underlying platform technology. This, in turn, means that productive model development may begin within Domains independent of changes in the platform such as operating system selection, choice of network protocols, memory management schemes, GUI technology and so forth. Naturally, any Domain centered around a particular platform technology (memory management, for example) may in fact be affected, but at least the changes will be restricted to that one subject matter.

Identifiers

1. Name

Attributes

No non-referential attributes