Scope
Containment is arguably one of the first candidates for representation pattern since its semantics can be applied both to objects and activities, and be shared across model layers, from requirements to design. If introduced upfront each time a set of elements has to be managed collectively, transparency, traceability, and reuse would be significantly improved.
And as far as structures and containers are concerned, requirements analysis can rely on the beacon provided by the GoF’s design patterns.
Archetypes
Again, architecture driven patterns must be defined by how actual objects and activity are to be coupled to their symbolic representation.
- Physical containers describe spatial locations within which physical objects can be addressed. Physical containers include geographic units, equipments or systems. Physical containers are usually business objects by themselves and therefore associated with persistent symbolic representations.
- Execution containers describe locations within which activities can be executed under a single control; in other words events can be managed under a single clock within the container, communication is meant to be instant i.e messages can be sent and received without delay. Execution containers do not necessarily coincide with physical locations, and may be represented by transient symbolic objects.
- Event containers is a special case of execution container embedded in actual context.
- Symbolic containers are used for symbolic descriptions of objects or activities and are usually associated with organizational units with authority upon domains or business processes. They should not be confused with containers for symbolic representations, which are actual objects, e.g data bases.
- Role containers is a special case of symbolic container describing roles hierarchies.
Collections, Structures, and Descriptions
Containment configurations can be neatly put into three categories, each with a well defined pattern:
- Non structured containers are sets of actual or symbolic elements (collections) or activities (iterations). For instance vehicles fleets, periodic verification, password registration..
- Composition of actual or symbolic elements (structures) or activities (sequences). For instance, actual vehicles, actual repairs, actual multimedia product.
- Constraints and rules governing the composition of actual or symbolic elements or activities. For instance, vehicles types, maintenance procedures, pricing of multimedia products.
The first configuration is usually consistently implemented at modelling and programing levels, the second and third ones can be neatly covered by composition patterns combined with connectors and structure patterns and power-types.
Embedded Execution Units
Since containment hierarchies can be defined both on structures and behaviors, it would be helpful to clarify upfront the way they could relate. In order to bring containers and state machines under the same modeling roof one can use stereotyped execution states:
Those stereotypes can then be combined with StateCharts (David Harel: “Modeling Reactive Systems with Statecharts”) to describe embedded execution units.
That may be illustrated by the Home Alarm System taken from J.Z.Lavi and J.Kudish: “Systems Modeling & Requirements Specification Using ECSAM”
- The system execution mode (control states) can be On or Off.
- When control is On, it affect the state of the alarm system and relies on the state of two external objects (external and battery power sources).
- When the house is unprotected, the system is characterized by two controlling states, one bound to user, and one associated to symbolic computing.
One step further, the same principles may be applied to events when state transitions are specified.