Part 3. Runtime Resources Layer
This chapter describes common patterns for representing the operating environment of existing software systems.
The following are the common properties of the Resource Layer packages Data, UI, Platform, and Event:
- They provide modeling elements to represent “resources” (something managed by the runtime platform)
- They provide abstract “resource actions” to manage these resources
- These actions are implemented by the program elements as one or more API calls to some external platform-specific packages
- There is a binding involved between the actions and the resources
- Resource may involve some “inverted” control in the form of callbacks and event handlers, allowing applications to be programmed in event-driven style
- The content of the information flow involving the resource is associated with some data organization
- Resource often has a certain state, and tracking the changes of the state over time may be an important concern in understanding the logic of the existing system
Since Resource Layer packages capture high-value knowledge about the existing system and its operating environment, which may involve advance analysis and some manual expertise KDM is design is such a way that the Resource level analysis can use KDM models from the Platform Elements Layer as input and produce Resource Layer models as output. There should be no references from lower KDM layers to higher layers; therefore new Resource Layer models can be built on top of existing Program Element layer models.
Resource layer package systematically use the following few KDM patterns:
- Each Resource Layer package defines entities and containers to represent specific “resources”. Each package may define additional elements to represent additional concerns. For example, the Data package involves less resource definitions, and focuses on the representation of various data organization capabilities. The Event package provides the meta-model elements for representing state, state transitions caused by events. States, transitions and events can be considered as runtime platform resources. The UI package provides the meta-model elements for representing user interfaces. User interfaces can also be considered runtime platform resources. The Platform package deal with conventional runtime platform resources, such as inter-process communication, the use of registries, management of data, etc.
- Each Resource Layer package defines specific structural relations between “resources”. For example, the Platform package defines relationship BindsTo which represents a logical association between two resources.
- Each Resource Layer package defines specific resource actions to represent manipulation of resource through API calls. Resource actions use the following KDM pattern. Each resource action is an entity of the base abstract class for the corresponding package. This class is named AbstractXXXElement, where “XXX” is the name of the package. So, the resource action is not a subclass of ActionElement, and this promotes modularity between Resource Layer packages, each of which defines as independent KDM compliance point. However, each resource action owns one or more ActionElement through property called “abstraction”. Each resource action also has the property called “implementation” which uses the KDM grouping mechanism to associate the resource action with one or more ActionElement owned by the Code model. The “implementation” group of the resource action represents the original API calls as they were represented in the Program Elements layer input model. The “abstraction” property uses KDM container mechanism to add the behavior counterparts to the API calls that represent the true logic of the resource operation, including the flow of data and control. The “abstracted” ActionElements are owned directly by the corresponding resource action, and are not part of any Code model.
- The nature of the resource-specific operation performed by a particular resource action is represented by the “kind” attribute of the resource actions. The resource action owns resource action relations through the “abstraction” action container. It is the owned “abstracted” action that is the direct owner of the resource action relationship.
- “abstraction” action container property is in fact systematically added to all elements of Resource Layer packages. This way each resource can use the meta-model elements defined in the Program Elements layer to specify behavior specific to that resource
- The “abstraction” action container pattern is used to systematically represent the forms of “inverted” control provided by runtime platforms. This pattern can be separately referred to as the KDM Event pattern. Each Resource Layer package defines own meta-model element for representing events. For example, the UI package defines the class UIEvent. The “abstraction” action container mechanism allow ActionElements to be added to event elements. Calls relation originating from such abstracted action element represents the “callback” mechanism, provided by several runtime platforms.
Resource Layer packages are independent, however they can offer additional capabilities, when more than one is implemented. In order not to enforce any particular order in which these packages should be implemented, KDM involves the following approach: resource action relationships are subclasses of the AbstractActionRelationship class from the Action Package. In the full KDM implementation that uses all packages, all resource actions are available for any ActionElement. Code models should not use the extended relationships. The extended resource action relationships can only be used by the actions in “abstraction” action containers in Resource Layer models. A notable example of this mechanism are the actions “HasState” defined in the Event package, which makes it possible to associate an element of an event model with any resource. Another example is the “HasContent” relation defined in the Data package which allows associating an element of a data model with any resource.
- The “abstraction” action containers, available for each resource also allow arbitrary Flow relations between “resource actions” and between resources to provide abstractions of the flow between “resource actions”
- The Resource Layer patterns are aligned the micro KDM, which allow precise modeling of behavior related to resources as the foundation for holistic high-fidelity analysis of existing software systems. Is can be achieved by associating sets of precise micro KDM actions with “abstraction” action containers.
Additional Runtime concerns involve dynamic structures (instances of some logical entities and their relationships) that emerge at the so-called “run time” of the software system. For example, dynamic entities include processes and threads. Instances of processes and threads can be created dynamically and in many cases relations between the dynamically created instances of processes and threads are essential part of the knowledge of existing system. Pure logical perspective in that case may be insufficient.
When separation of concerns between application code and Runtime platform is considered, it is important to be clear about the so-called bindings and various mechanisms to achieve a binding or delay it.
A binding is a common way of referring to a certain irrevocable implementation decision. Too much binding is often referred to as “hardcoding”. This often results in systems that are difficult to maintain and reuse. They are often also difficult to understand. Too little binding leads to dynamic systems, where everything is resolved at run time (as late as possible). This often results in systems that are difficult to understand and error-prone. Modern platforms excel in managing binding time. Usually binding is managed at deployment time.
Large number of software development practices is about efficient management of binding time, including portable adaptors, code generation, model-driven architecture. Efficient management of binding time is often called platform independence.
- Generation time binding
- Language & platform design binding
- Versioning time
- Compile time binding, including
- macro expansion
- Templates
- Product line variants defined by conditional compilation
- Link time binding
- Deployment time binding
- Initialization time binding
- Run time