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.
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 .
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.
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 .
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:
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).
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.
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:
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 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).
System types. These are structure types defining the overall framework structure. They are formalised whenever it is possible and practical to do so and will contain both infrastructure and application parts.
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 .
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.
The specification part shall concentrate on the context of the framework and the external framework properties, see Framework specification .
The design part shall concentrate on the content of the framework, see Framework design .
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.
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.
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.
How the application is related to the domain and the framework is illustrated in Figure 33 .
The application part of the framework should use types that are defined in the Application models .
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).
The considerations here are the same as for Relationships application specification - design .
The considerations here are the same as for Harmonisation application specification - design .
The General application guidelines hold also for framework models. But there are additional rules.
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 .
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:
The framework system type in this case has the form illustrated in Figure 35 ,
and it is repeated for the block type BT1 ( Figure 36 ) in order to show predefined process (sets).
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.
An alternative structuring of the system is provided in Figure 37 .
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The framework system type then is defined as in Figure 42 .
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 .
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 .
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" .
Other families and especially their frameworks may provide valuable input. It may even happen that the infrastructure and the overall framework structure may be reused from another family even if the application is different.
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.
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.
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.
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.
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:
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.
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:
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.
This is carried out in the same general way as Designing application behaviour .