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:

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:

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.

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.

Binding time

 

Binding Time
What is being bound
Result

Generation time

Syntax, variant, pattern, mapping, etc.

Generated code

Language & platform design

Syntax, entities and relations, including platform resource types

Source code

Versioning

Module source files

Module version

Compile time

Intra-module relations (def-use)

Module

-- Macro

Syntax, macro to expanded code

Expanded macro (source code)

-- Template

Template parameters

Template instance

-- Product line variant defined by conditional compilation and includes

Conditional compilation, macro, includes, symbolic links

Component Variant

(static) Link time

Intra-component relations within deployable component

Deployed Component

Deployment time

Resource names to resources (using platform-specific configuration files)

Deployed System

Initialization time

Component implementation to component interface; major processes and threads; dynamic linking, dynamic load (using platform-specific configuration files)

System

Run time

User input, object factory, virtual function, function pointer, reflection, instances of processes, instances of objects, instances of data, etc.

Particular Execution Path