Domain

A Domain is an autonomous, real, hypothetical, or other abstract world inhabited by a set of conceptual entities that behave according to characteristic rules and policies. [MB]

A Domain is represented on a miUML domain chart as a UML package which contains a complete executable system. This may be a miUML model set, handwritten code, legacy code or any other executable software specification.

Each Domain is a black box with respect to any other Domain. This means that no component in one Domain should know about the structure of a component in another Domain. Furthermore, each Class* should appear only once in a system and in only one Domain. In the Elevator Application, the Cabin class appears only in the Elevator Management Domain. Both the UI Domain and the Transport Domains appear to need the cabin concept, but this is not really the case. The UI provides an animated icon which can be configured to represent Cabin instances. The Transport Domain provides a Load which can be configured to represent a Cabin. Each class:Cabin, Load and Animated Icon has a distinct definition and set of rules and constraints within each Domain. Mappings are provided on each Bridge to knit the concepts together during implementation.

All Domains and interconnecting Bridges used to construct a single software system or project are typically drawn on a miUML domain chart. The same Domain may be reused in multiple systems / projects. In fact, this is an intended by product of domain based system partitioning.

* A Realized Domain won’t specify any Shlaer-Mellor Classes, but the general notion of structures or entities still applies. A realized GUI package, for example, probably won’t supply an elevator cabin entity unless it is extraordinarily application specific.