Content and scope

A framework is an abstract system or a collection of (large) system component with two parts:

The application part is normally rudimentary in the framework. To make a complete abstract system from a framework the application is redefined and the infrastructure is configurated.

In this chapter we shall describe:

Framework models are important because:

Once a framework is defined, application development may proceed as an independent activity concentrating on application issues.

What is a framework

The Free On-line Dictionary of Computing defines a "framework" as:

"In object-oriented systems, a set of classes that embodies an abstract design for solutions to a number of related problems."

A tutorial on designing frameworks says:

"Frameworks are reusable designs for an application or a subsystem expressed as a set of classes and the way that instances of these classes collaborate.

A framework describes not only how to partition the responsibilities of a system among its components, but also how to think about a problem. It is therefore not only a way to reuse code, but a way to reuse design and analysis information, as well.

Frameworks are difficult to design because they are abstract. Framework designers must look at many concrete applications to ensure that the abstractions that they are designing make sense. Frameworks are difficult to learn because the user of a framework must adopt the collaborative model of the framework. It is usually not possible to learn a framework one class at a time, but instead several classes have to be learned together.

Nevertheless, there is a great advantage to learning a well-designed framework, and mature frameworks (like some of the user interface frameworks) can provide order of magnitude increases in programmer productivity. "

The main property that distinguishes a library from a framework is that a framework embodies a design of a type of systems, while a library just is a collection of related classes. An elaboration of this distinction is given in Table 1 .

  1. Differences between libraries and frameworks



The application uses library classes, but the library knows nothing about the application

The framework knows about the application and uses application classes.

No predefined system structure. The system is entirely defined in the application.

Provides structure. The system is (partially) defined in the framework

No predefined interaction

Defines object interaction

No default behaviour

Provides default behaviour

Examples on these differences will be given below.

Classical examples of frameworks like window systems are defined as a set of related classes, and are normally implemented in C++. The structure of these frameworks results from dynamically created objects that are kept together by object references. The event loop that dispatches mouse and keyboard events to window objects will use a list of currently active window objects. This list will typically contain different window objects, with the common property that they react on these events. By calling virtual procedures, it is then up to the user of the framework to redefine these procedures to what is special for the application.

The notion of framework is not special for TIMe. What is special for TIMe, however, is that this idea is adapted to SDL. TIMe advocates the structuring of systems into frameworks and gives guidelines for how frameworks can be defined in SDL. TIMe puts a little more into frameworks than the definition above, and one reason is that SDL can specify the static structure of systems and not just a set of types.

In TIMe a framework is a system type/class or a collection of (large) component types/classes, with predefined structure so that a specific system only has to provide the specific "contents" of part of this structure. Frameworks often come about because an abstract (application specific) system has to be supplemented by a large infrastructure part in order to be executable on a given platform. Instead of making the infrastructure part again and again for each new system with the same infrastructure on the same platform, a framework that embodies both the application- and the infrastructure part is defined. In a framework the infrastructure is stable, while the application part may vary from system to system.

The structuring of a framework may have one or more of the following goals:

TIMe emphasises the second goal. How this may be done for designs made in SDL, is explained in How to define a framework using SDL .

One reason for designing frameworks is that this has turned out to be the most effective way of reuse. Another is that the framework helps to simplify application evolution and system instantiation.

Framework reference model

Application and infrastructure

In the Application reference model the "pure" application is in focus without considering how it will be implemented. When the system is implemented, the application system may be distributed over several physical nodes and needs to be supported by an infrastructure with functionality for:

Complete abstract system

This additional functionality may be modelled in a complete abstract system which can be seen as having two layers: an infrastructure layer and an application layer. In the complete abstract system the application has been distributed in the same way as in the concrete system. In the Infrastructure part we find objects that support distribution, system administration and other facilities not directly related to services provided by the application. The infrastructure part contains additional behaviour needed to fully understand, simulate and analyse what the system does (the complete system behaviour).


A reference model that takes these aspects into consideration is shown in

Figure 31 .

Figure 31: Application framework reference model


Here the Application reference model , described in Figure 21 [openfig] is distributed on top of an infrastructure.

It is normally the case that different systems within a family will have the same Infrastructure but slightly different application parts, and when making systems with different applications it is desirable not to change or even consider the Infrastructure part (besides what it offers). Adding or changing services should mainly be performed in the application, leaving other parts unchanged.

On the other hand it is sometimes desirable to change the implementation platform without needing to modify the application. It is desirable that an application may survive several platform generations and thereby provide better return of investment.

A framework defines the composition of the Infrastructure parts and application parts in such a way that they can be changed independently.

Framework infrastructure

The Infrastructure is structured similarly to the concrete system. If the concrete system is distributed, the infrastructure will be distributed too. If the concrete system is centralised, then the Infrastructure will be centralised too. (Therefore, the Infrastructure cannot be designed before the Architecture (of the concrete system) has been designed.) There are several reasons for this similarity:

In general an Infrastructure will contain abstractions of:

In an initial development the infrastructure aspect may not be obvious. Frameworks will often come as a result of a (successful) initial development, which is to be used as a basis for a new system.

For the Access Control system the fact that validation shall be performed by a central computer is an infrastructure issue, like the need to support remote communication, with additional protocols.

Framework application

The framework will contain redefinable application objects. In a framework instance these are redefined using application types that shall be defined in the Application models .

When the application is developed for the first time, the Infrastructure is normally not known, and therefore not taken into account. As soon as the infrastructure is known, application development shall take the infrastructure into account. This means that:

Framework models


The purposes of framework models are to:

Framework instances serve to:

Framework models serve to define complete behaviour when taking implementation specific features into account. Framework models are made once for a family, and applied many times (one for each different application).

Framework rule


Framework models contain different kinds of object type models:

The application part of the framework types will be virtual application components. All the application types are defined in the Application models .

Framework models, as other models, have a specification part and a design part, see Figure 32 .

Figure 32: Framework models

It may sometimes be difficult to express all the variability needed formally in one type model. It may also happen that some components are defined using SDL and other components are defined using OMT/UML. In such cases it may prove more practical to emphasise component types that are easy to compose rather than complete framework system types.

When necessary, rules for mapping applications to the framework shall also be defined.

Framework model content

Framework specification

The specification part shall concentrate on the context of the framework and the external framework properties, see Framework specification .

Framework design

The design part shall concentrate on the content of the framework, see Framework design .

Framework languages and notations

As illustrated in Figure 32 , the main languages to use are MSC for property models and OMT /UML combined with SDL for object models.

SDL is the main language for control behaviour, while OMT/UML will be used for other aspects (such as user interfaces and data-bases). Typically OMT/UML will be used in the specification part, and possibly for top level design structuring. SDL will take over where the main thing is to model reactive behaviour.

In some cases it will be possible to express the framework object models completely in SDL.

For description of interaction properties, we stick to MSC even if OMT/UML is used for the Object Model.

Framework property models will focus on the infrastructure properties. In addition to specifying the infrastructure services and interfaces using text, role diagrams and MSC, they will specify requirements to physical distribution, routing, configuration and similar issues that are better expressed in text and illustrative figures than in MSC and role diagrams.

Framework specification


A framework Specification serves to answer questions like:

    1. What infrastructure services are provided?

    2. How is the environment physically distributed?

    3. How is the content physically distributed?

    4. What is variable?

    5. How are instances defined.


Specifications are developed first for the framework system as a whole and later for each framework- and infrastructure component type.

For the framework as a whole the following issues shall be considered:

Framework specification content

Framework object model

The object model will describe:

    1. the system context detailing the environment and the interfaces using physical grouping and distribution as main structuring criteria.

    2. the parts of the content that are externally visible and relevant to the specification, also structured according to the physical world.

    3. component type specifications for component types that are identified.

Framework property model

The framework property models will contain:

    1. service models for infrastructure services;

    2. interface models for infrastructure interfaces;

    3. textual specification of other properties:

    network requirements;

    protocol requirements;

    communication and routing requirements;

    configuration requirements;

    error handling requirements;

    the variability in the system family, and how system instances are to be configurated and built.

Framework design


To describe the design part of framework models that:


The context part is fully covered in the specification. The design part define the content structure and the types of framework component and infrastructure components that are specific to the framework.

Framework relationships

How the application is related to the domain and the framework is illustrated in Figure 33 .

Figure 33: External Framework relationships


Relationships framework - application

The application part of the framework should use types that are defined in the Application models .

Framework application relationship

Harmonising framework - application

The application will not be visible as a system in the framework, but its component types will be used. However, if the application types shall be applicable in the framework they must obey the rules of the infrastructure. This may require some adjustment compared to the types initially developed (before the infrastructure was known).

Framework application harmonisation

Relationships framework - architecture

Framework architecture relationship

Harmonising framework - architecture

Framework architecture harmonisation

Relationships framework specification - design

The considerations here are the same as for Relationships application specification - design .

Harmonising framework specification - design

The considerations here are the same as for Harmonisation application specification - design .

General framework guidelines

While the application models are structured primarily to achieve readability for the human, framework models are structured primarily to:

The General application guidelines hold also for framework models. But there are additional rules.

Framework system type

Dynamic change

Dynamic configuration

Distribution transparency

How to define a framework using SDL

The distinction between a library and a framework is in SDL directly reflected by the concepts of package and system type . In SDL terms a library can be expressed by a Package, while a framework must be defined by a System type. The essential difference is that a library only defines types and not instances (and this holds for a Package in SDL), while a System type can have both.

A System type defining a framework will typically have instances that cover parts of the structure, and it will assume that the actual application of the framework will provide application specific instances. A framework can be based upon libraries, and the system type will be part of a Package.

System types and Block types have so much in common that if the desired approach is to develop Block types and use these for composing systems, then many of the framework techniques explained below also apply to Block types.

A framework system type is defined by a system type or block type in SDL , see Figure 34 . This type will have virtual types for the application components, and these will be redefined when defining a complete abstract system .

Figure 34: Framework definition and use

Normally the framework system type will have framework components that are blocks with some framework specific structure. The block type BT1 may e.g. consist of an infrastructure part and a virtual type that represent the application specific part of BT1.

How then are application specific parts included in the framework? In general this is done by redefining virtual types, e.g. virtual block types, virtual process type and virtual procedures. There are two different ways to treat application specific instances:

Application specific instances are specified as part of the framework

In this case it is only necessary to redefine the virtual application types - the instances/set of instances and their position in the system structure is already part of the framework definition.

The framework system type in this case has the form illustrated in Figure 35 ,

Figure 35: Framework definition with predefined instances

and it is repeated for the block type BT1 ( Figure 36 ) in order to show predefined process (sets).

Figure 36: Virtual block type as part of framework, with application specific instance specificed


In this case the frameworks defines the structure of instances and instance sets with their connections in terms of channels and signal routes. In a complete application system the properties of the instances are provided by redefining the virtual types (using application types).

In order to define the structure of instances and their connections in the framework, some minimal interface definition for the instances must exist that cannot be redefined when redefining the virtual types. The rule of SDL is that redefinitions of the virtual types (here BT1, BT2 and PT1) must be subtypes of the constraints of the virtual types. The default is that the constraints of the virtual types are the type definitions themselves. This is, however, not enough to assure that the interfaces are the same, as it would then be possible to add new gates and new signals to the signal list of existing gates. Additional rules state that a redefinition of a virtual type must have exactly the same interface as the constraint of the virtual type. Before using this approach you should be sure that one can live with this rule.

A typical example on this kind of framework is the handling of protocols. The fw1 process will be the interface to the protocol, and it will present itself to the application specific PT1 process independently of the protocol. This scheme may be generalised: if e.g. both block type BT1 and BT2 will have the same protocol handling part, then this may be expressed in a common super block type of BT1 and BT2.

If the structure is so that the same virtual process type is used to make process sets in many parts of the system structure, then the virtual process type should be moved to the system type, see Figure 37 . In this way it can be redefined at one place as part of the system subtype and have implication on many parts of the system.

Figure 37: Application specific virtual type at system type level

An alternative structuring of the system is provided in Figure 37 .

A framework example for the Access Control system is given in Figure 50 and Figure 51 .

We know that AccessPoint is used both in LocalUnit and ClusterUnit (see Figure 51 ). By defining it at system type level, a redefinition in a system subtype will imply that (as desired) AccessPoint in both LocalUnit and ClusterUnit will get the same redefinition. With the AccessPoint as a virtual type at system level and Cluster as a non-virtual type we express that the AccessPoint of Cluster objects can be redefined, but not other parts of Cluster.

Application specific instances not specified as part of the framework

In this case the framework only consists of general types that may be used for the construction of the application part. The framework specific parts may either be instances or also just represented by types. Framework components will then need to create objects (in this case processes) according to application specific classes.

SDL is special in the sense that processes are part of process sets and that creation of processes is done by referring to the name of the set and not to the name of the process type. It is therefore not enough that the framework specific process types are defined in the same scope (e.g. a package or a system) as the application specific types for them to create instances application specific instances - they must have means for referring to the process sets to come.

This may be done in two different ways: by using context parameters or by using virtual procedures.

Context parameters

The general types of the framework that have to create process instances according to application specific types do this through process context parameters. This works in SDL because an actual process context parameter is a process set and not a process type.

The scheme is illustrated in Figure 38 , Figure 39 and Figure 40 .

Figure 38: Framework with no instances

Within the block types, there will be general process types ( framePT and applicationPT ) that are used as supertypes in specific systems inheriting from FrameWork2 . In addition the block types may specify instances of other process types, and these are the only predefined instances of this kind of framework.

Figure 39: Virtual block type

The framePT process type will have a process context parameter that is constrained by applicationPT, see Figure 40 . The idea is that a particular system will provide its specialisation of applicationPT and its process set, and by the context parameter the framePT processes will create instances of the specialisation of applicationPT.

Figure 40: Creation of application specific processes

The final system type will introduce the redefined block types with appropriate process sets, see Figure 41 (both for framePT and applicationPT processes) and provide these as the actual context parameters.

Figure 41: Redefined block type with process set and actual context parameter

The difference from the case with application specific instances as part of the framework is not so big: the process set must be foreseen (the context parameter must be defined - and that corresponds to a process set), but the name of it and its position in the application part is not determined. Its position will, however, be constrained by the fact that it shall be visible from the place where the actual context parameter is provided. This means that everything will take place with the virtual block types immediately enclosed by the system type.

Another constraint with this approach is that it is not possible to specify instance sets of the framePT. The reason is that this process type has context parameters. In total this means that the approach with context parameters works only partially: you cannot specify the actual instance sets before the last system subtype.

Process type as context parameter

This approach should only be used in cases where it is important that the framework specific and application specific process types can be defined within the same enclosing block type and where the framework specific types must specify the creation of application specific processes.

A final constraint with this approach is that it is not supported by tools (yet).

Virtual creation procedures

This approach is even more general in the sense that it does not have to be decided if there is one or several process sets in the final system type. In the general types where there is a need to create application specific processes, this is represented by corresponding virtual procedures. In the final system type these are redefined to create processes in the right process sets.

This approach is also constrained by the fact that all processes must be within the same block, so the framework will be defined by a system type with one or more block sets of virtual block types, the extreme case being just one block of one virtual block type.

This approach also has the property that instance sets of the application specific types are first introduced in the final system subtype.

In order to provide an example on this way of making frameworks, we have to change the structure of the Access Control System somewhat.

As the structure of the system is specified above, the number of clusters and thereby of access points is fixed at the time of specification. With clusters defined as above, each cluster will have AccessPoints with the same properties (of the same type).

Suppose that it is a requirement that the system shall start by creating processes for each of the actual access points and that changes to the number of access points shall be reflected while the system is running. Still we would like to define the system as a framework in the sense that it will consist of a central unit and a number of clusters. We assume that the division of responsibility between the two are determined, the communication is fixed and that the functionality of both clusters and central unit is specified - the only thing that is not specified is the types and numbers of clusters. The configuration of the system is initiated by a new signal (setUp, with appropriate parameters) coming to the central unit.

For the purpose of this example we assume that it is possible to define both the CentralUnit and Cluster as processes.

The framework system type then is defined as in Figure 42 .

Figure 42: Framework with virtual creation procedures

The setUp signal is supposed to come to the CentralUnit and imply the creation of Cluster processes in the right process sets. Depending on the desired number and types of Cluster processes, the signal will carry enough parameters for the CentralUnit to create the right instances.

The Cluster and CentralUnit types can now be defined as before, the only difference being that CentralUnit will be virtual, that it will have a virtual procedure setUp and that it will communicate with possible Cluster processes via a gate that is constrained by Cluster - that is only process sets of Cluster or subtypes of Cluster can be connected to the gate, see Figure 43 .

Figure 43: Setup as a virtual procedure of CentralUnit

In addition to the normal behaviour and the creation of Cluster processes, the CentralUnit may have behaviour that contributes to the definition of the framework. As an example there may be a limit on the total number of Cluster processes, independent of type of Cluster. The behaviour that ensures this will either be part of the CentralUnit, e.g. some action executed each time setUp is executed, or it may be a constraint on setUp which all redefinitions will inherit.

An actual system consisting of two types of Cluster processes is specified as a subtype of the system type AccessControl, redefining the setUp procedure to cater for this and introduce the two process sets, see Figure 44 .

Figure 44: Actual Access Control System

The names of the process sets are used in the redefined setUp procedure for the specification of the creation of process instances. A fragment of the redefinition is illustrated in Figure "Fragment of redefined setUp" .

Figure 45: Fragment of redefined setUp


Developing framework


This activity develops the Framework models which consists of object models and property models organised as a Framework specification and a Framework design .

Figure 46: Developing Framework



The main sources of input information are:

Who to involve

This is primarily a task for abstract system designers, but they need to work closely with architectural designers and production people. Frameworks are developed primarily for the purpose of simplifying evolution and production after the initial development. It is therefore essential that people with such responsibility are engaged so that their requirements become clear. It is particularly important to clarify if dynamic changes to a running system shall be supported or not.

It is not always obvious what implementation dependent functionality to include in the framework and what to "hide" in the implementation. This must be agreed with the Architectural designers. It may also happen that framework considerations have an impact on the architecture.

When to do it

Framework design depends on the underlying architecture (implementation) design and is therefore made after the architecture.

This activity is only performed when the framework is undefined or needs to be changed. This occurs during the initial development of a system family and during maintenance when changes in the framework are needed e.g. because of changes to the infrastructure.

During normal application evolution the framework will stay the same. The idea is that new services of an existing system can be designed in terms of the application without considering details of the framework.

Interfaces are sometimes elaborated in this activity. The reason being that the interfaces depend on the architectural design decisions:

What to do

Making frameworks

The following strategy may be used when making the first framework model for a new system family:

Completing the abstract system model

This activity assumes that the architecture has been defined. The goal is to restructure the application and to add the necessary infrastructure functionality. This is a typical intermediate step on the way towards a framework. Once the framework has been designed, this model is replaced by a framework instance. However, if it is decided not to develop a framework the complete abstract system must be maintained.

As an example the complete abstract system model for the Access Control system is presented in Figure 47 , Figure 48 and Figure 48 .


    1. Consider the structure of computational nodes in the architecture, and make a corresponding abstract system structure.

    2. Localise all the application components (instances of structure types and behaviour types (objects)) in this structure.

    3. Add infrastructure components needed to support communication within the application.

    4. Add additional infrastructure components needed to support services stated in the framework specification (Use the same approach as for application design synthesis here):

    support for distribution transparency, object relocation , dynamic configuration and change;

    support for error handling.

    5. Check that the complete application functionality can be provided in the new structure.

    6. Define the infrastructure component types that have been identified.

Define the method for instantiating frameworks with an application.

This is a textual description telling how to instantiate the framework both statically and dynamically.

Evolving frameworks

Use the following strategy when evolving a framework:

Specifying frameworks


Inputs to this activity are the same as for Developing framework models as a whole, see Figure 32 . However, the initial specification is made before there any architecture.

Making framework specification

The initial framework specification is normally developed before the architecture during requirements specification. What can be said at that stage is often limited, and therefore the initial framework specification is usually quite open. Typical items are:


Specify framework context

Specify framework content

Evolving framework specification

Framework evolution is not due to application services, but to changes in the architecture or the infrastructure services. It may also be due to a better understanding of how the framework should be. Finally the specification is influenced by the framework design since it should always be harmonised with that.

Infrastructure services are evolved in the same general way as application services:

    1. Specify the new services using property models.

    2. Analyse the impact on existing services and object models.

    3. Specify new objects required in (the various parts of) the environment (if any).

    4. Change existing services and object models as required.

Changes in the architecture are more likely structural changes that will affect the object model.

Designing framework structure

Making framework design

It is an advantage to make a complete abstract system model before starting to make a framework, because then we have something tangible to start from. Our goal is to transform the complete model into:

    1. a framework design that is easy to use with different applications;

    2. an instantiation of the framework that replaces the original complete abstract system model.

As an example we consider the Access Control system again. The system description of Figure 47 is turned into a framework simply by defining it as a system type and defining the application specific types as virtual types (in this case AccessPoint), see Figure 50 .


The Cluster block is almost as before: it uses the virtual block type Access Point (but it does not contain its definition), and it embodies the infrastructure parts needed for distribution (ClusterUnit, LocalUnit and Protocol), see Figure 50 .

An actual system based upon a framework definition is described by defining a subtype of the framework system type and redefining the virtual, application specific types, see Figure 52 . The rules for redefinitions of virtual types in SDL ensures that the redefined AccessPoint will have the same interface as specified in the virtual definition (as a constraint) and thereby assumed by the rest of the system type.


In the complete abstract system we need not worry too much about variability. The goal is to understand the overall structure and to identify the infrastructure components. In the Framework design, however, we must seriously consider the requirements to dynamic configuration and change. Is each system Instance to be statically configured for its lifetime, or shall it be possible to make dynamic changes? If the answer is yes, then we must design the framework so it contains suitable dynamic change units.

Is the configuration support we get by using system types with context parameters in SDL sufficient or do we need more flexibility? If the answer to the latter is yes, then we must turn to what can be supported by SDL behaviour, i.e. dynamic process creation and value assignments. If we need even more flexibility, for instance to create blocks dynamically, then this must be handled outside SDL. In such cases, it will not be very useful to cover the entire system formally as a single SDL system type - or block type (except for simulation purposes). In stead we should develop framework components that can be used to compose and configurate systems more freely, possibly using means that we provide outside SDL. In the Access Control example, it will be difficult to achieve full flexibility using the system type defined in Figure 50 as each LocalUnit and ClusterUnit may need to be configurated differently. What is possible, however, is to use these components to compose many different SDL systems. Therefore framework components will sometimes be more useful than complete framework systems.

There are some trends in system development that should be considered:

These trends point towards:

    1. that much infrastructure functionality will be standardised;

    2. that the system structures will change dynamically so that components are more stable than systems.


Designing framework behaviour

This is carried out in the same general way as Designing application behaviour .