O
We borrowed this pattern name from the binary opposition94 originated in Saussure’s structuralism95). It covers the following pairs of messages usually found in software traces and logs such as:
- open / close
- create / destroy
- allocate / free (deallocate)
- call / return
- enter / exit (leave)
- load / unload
- save / load
- lock / unlock
- map / unmap
The absence of an opposite may point to some problems such as synchronization and leaks, or Incomplete History (for example, wait chains). There can always be a possibility that a second term is missing due to Sparse Trace, but this is a poor implementation choice that leads to confusion during troubleshooting and debugging.
This pattern deals with software trace messages where a certain activity is repeated several times, but the only the first message occurrence, or specific message vocabulary has significance for analysis activity. A typical example from CDF / ETW tracing is module load events:
# Module PID TID Time Message
[...]
35835 ModuleA 11000 11640 17:27:28.720 LoadImageEvent: DeviceHarddiskVolume2WindowsSystem32userinit.exe PId 5208
[...]
37684 ModuleA 12332 9576 17:27:29.063 LoadImageEvent: WindowsSystem32userinit.exe PId 573C
[...]
37687 ModuleA 12332 9576 17:27:29.064 LoadImageEvent: WindowsSystem32userinit.exe PId 573C
[...]
What we are looking here is Message Invariant like “.exe,” but we are interested in the occurrence of specific path structures like DeviceHarddiskVolume because, in our troubleshooting context, they signify process launch sequence during terminal session initialization.
There are messages in traces and logs that alone do not have useful information. These are adornments or ornamentation messages that we initially called Delineator or Separator messages that structure message stream or Figural Events (where we borrowed the name figural from Lyotard96) such as formatting the next message with { }. Such messages only make meaning with other meaningful messages. We call this pattern Ornament. It helps in using trace analysis patterns and trace pattern identification.
Ornament can also be present in individual messages, for example, as a character prefix. It can be a part of Message Invariant or variable itself. Some ornamentation can play a rhetorical97 function.
Although ornament is present in non-software architecture, this concept has never been explored in pattern–oriented software architecture and construction. We propose a similar concept for source code (software construction) in addition to the ornamentation of its Declarative Trace. For software post-construction, we also add ornament part to software structure and behavior parts.