Subsystem - modelint/shlaer-mellor-metamodel GitHub Wiki

Many domains can be quite large with dozens or even hundreds of classes. Subsystems provide a way to partition a large domain so that people and groups can work with manageable chunks of the problem. A subsystem is a part of a domain containing classes, relationships, state machines, and their procedures [activities]. [MB]

images/domain-subsystem/subsystem-10.png

The same UML package symbol that represents Domains can be used to represent Subsystems. And both Domains and Subsystems contain Shlaer-Mellor model Elements. Beyond that, Domains and Subsystems are completely different.

A Domain is a coherent, complete subject matter. It is as big as it needs to be to cover the subject matter. A Subsystem is sized arbitrarily as a unit of management. One Subsystem grouping guideline could be ‘whatever fits on a D-size (A2) sheet’, for example. Each Domain is a black box with respect to any other. So a Class, Attribute, State or any other modeled component in one Domain is invisible to external Domains. Within a Domain, Subsystems are white boxes. For example, an Attribute in one Subsystem may be read directly by an Element in another Subsystem (even though this might not be a good general practice). An Instance in one Subsystem may receive and respond to Events from another Subsystem.

Ideally, these interactions are minimized by carving up Subsystems in such a way that as few Relationships and collaboration paths are divided as possible.

Identifiers

  1. Name + Domain
  2. Alias + Domain
  3. First element number + Domain

Attributes

Name

A descriptive name such as ‘Stores and Retrieval’.

Type: Subsystem Name

Alias

A short name used for labeling purposes. Originally defined in Shlaer-Mellor, as the keyletter, SAR, for example.

Type: Subsystem Alias