Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Preliminaries

Terminology

The patterns catalog introduces specialized terms to discuss patterns. These are:

  • Asset: The DynaMAL term for the representation of a physical or logical entity.
  • Association: The DynaMAL term for the representation of a physical or logical relationship between assets.
  • Authentication object: A type of configuration object that represents material used during identification and authentication procedures, such as accounts, access keys, and passwords.
  • Configuration object: An object that represents some form of setting or other passive control logic that directs the execution logic of other objects. Configuration objects contain little to no executable logic.
    • Colloquially: Objects that control other things.
  • Container object: An object that is a tangible and manipulable representation of data or information. Container objects contain little to no executable logic.
    • Colloquially: Objects that are used and moved by other objects.
  • Execution object: An object that represents active entities in the represented domain, i.e., entities that act and interact with other objects. Execution objects contain the bulk of the total executable logic.
    • Colloquially: Objects that do things.
  • Simple object: An object without elaborate relationships or attributes. For instance, a single asset with a single association.
  • Object: A physical or logical entity in the domain, typically represented via assets.

The pattern format

The pattern format used in this catalog was inspired by the format in Design Patterns [1] and consists of seven standard components:

  • Diagram: a visual representation of the pattern.
  • Intent: a brief statement about what the pattern represents.
  • Motivation: a longer description of the pattern and the context in which it arose.
  • Possible use cases: examples where applying the pattern may be motivated.
  • Code example: an illustrative DynaMAL implementation of the pattern.
  • Possible synonyms: alternative terms that may correspond to the pattern.
  • Occurrences: the sources and evidence for the pattern.

Pattern entries may not omit any of the standard entries. Candidate patterns may omit one or more of the standard entries.

Visual syntax

Diagram elements

The pattern entries in the catalog must begin with a visual representation. These representations should diagrams that depict the graph operations prescribed by the pattern. To ensure a consistent visual syntax, the graph visualizations must be constructed from the standard elements depicted above.

The standard elements are as follows:

  • Object: A vertex that represents some entity.
  • Collected object: A vertex that has been retrieved with a collect operation.
  • Potential object: An ephemeral vertex, used to signal the intended result of an addition.
  • Relationship: An edge that represents some relationship between two entities.
  • Collection: An edge with a gradient that represents a collect operation and its direction. Collect directions are light to dark, e.g., left to right in the standard elements illustrated above.
  • Potential relationship: An ephemeral edge, used to signal the intended result of an addition.

The color palette is as follows:

  • White is defined as 0xFFFFFF.
  • Black is defined as 0x000000.
  • The pattern background is white.
  • Vertex centers are white. Vertex lines are black.
  • Relationships are black.
  • Potential objects and relationships are dashed black lines.
  • Collections are depicted with white–black linear gradients.

The rules for patterns sequences are as follows:

  • A pattern sequence is one or more rows of panels that depicts a series of graph operations.
  • A row is a sequence of panels that reads left–right.
  • A row typically consists of three to five panels.
  • A panel is a single diagram that depicts some graph operations, e.g., a step
  • The first and last panels of a sequence should depict the initial and end states, respectively.
  • Intermediate steps should depict one graph operation, but more may be shown.
  • Pattern diagrams may depict multiple alternative pattern sequences, where the beginning and the end of a sequence should be indicated by a single black horizontal line.
  • Extraneous visual elements, such as text labels and extra arrows, are to be avoided.

An annotated example

Annotated example

The diagram above shows an annotated pattern sequence for the Transfer pattern. The sequence is to be read as:

  1. The initial state shows the first objects and relationships.
  2. The first operation (1.) collects the top right object from the top left object.
  3. Retain the previous collection (1.), collect the bottom object from the top left object (2.). The potential relationship (3.) between the top right object and the bottom object is depicted.
  4. Link the top right and the bottom objects (3.). Collect the bottom elements from the top left object (4.).
  5. Unlink the top left object and the bottom object (4.). The end state has been reached.

References

[1] E. Gamma, R. Helm, R, Johnson, J. Vlissides, Design patterns : elements of reusable object-oriented software. Reading, Mass: Addison-Wesley, 1995.