TIMe at a glance
Introduction
The Integrated Method (TIMe) supports design oriented development, an approach to system development where systems are understood and maintained mainly in terms of abstract design descriptions. It even goes one step towards making the vision of property oriented development come true.
TIMe for what?
TIMe is designed for systems that are
TIMe is centered around a set of models and descriptions capable of expressing domain knowledge, system specifications in terms of external properties, system designs in terms of structure and behaviour, implementation mappings and system instantiation.
Like most other similar methods, TIMe distinguishes between Analysis, Design, Implementation and Instantiation (see Figure 1).
How TIMe is different
The distinction between Domain and System Design is not particular for TIMe. What is special, however, is that:
- design is split between
- the complementary object models and property models are used both for domain and system analysis, and for design.
application design, where the functionality of the system is design,
architecture design, where the non-functional properties are taken care of, and
framework design, that defines types of systems with the same infrastructure (e.g. supporting distribution) where the application specific parts are singled out to be redefinable in specific systems.
- a set of system development activities that covers most of the system development process, with emphasis on the activities leading to implementation,
- guidelines on object and property modeling in general, and particularly how to do it in UML [147] / SDL [102] - [104], [108] and MSC [105], [110] respectively, and
- tutorials in UML, SDL and MSC.
Object oriented
TIMe is truly object oriented in its approach. It defines its own underlying object and property models, and contains detailed guidelines on:
Abstract models
- Emphasis on abstract models and descriptions: Abstract descriptions leave out implementation specific details and let the developers focus on functionality.
Property models
- Focus on (external) properties: Objects are the building material from which systems and components are constructed. Property descriptions are used at an early stage of development to express the properties required from a system or an object. At a later stage they are used to express the properties actually provided by a system or component.
Roles
- Strong object-property relationships: Roles are used to describe properties, and are related to object designs by projection. Roles are used to link properties and objects. Projections are used for synthesis of new objects and for documenting existing objects.
Design for reuse
- Planned variability and reuse: TIMe seeks to make generic system families that may be adapted as easily and safely as possible to the needs of particular systems. Components for reuse across families come from general domain descriptions. TIMe describes a cost-effective way to define instantiation of particular systems by defining the general parts by reference to the family description, detailing only what is special for that particular occurrence, i.e. its configuration.
Synthesis
- Design synthesis: Property oriented design involves:
Decomposing required service and interface properties into object properties.
Synthesizing object designs from required object properties, by transformation and by composition, taking reuse into account.
Comparing properties: required against provided (validation).
Goal of this document
This document provides the TIMe Essentials, intended for readers that would like to know why they should use TIMe, get a feeling for what TIMe is, if it applies to their needs, how it differs from other similar methods, etc.
Focus
The focus in this document is the core of TIMe, that is system development activities with the combined use of UML, MSC and SDL for making models, based on a common approach to object modeling and property modeling, with emphasis on the early stages of system development. As indicated in Figure 2, TIMe is more than this.
This introduction can be read as a stand-alone document, but when read in electronic form, and integrated with the full method book, it also works as an introduction, with hyperlinks to the whole method.
The section "The Why, What and How of TIMe", together with the last part of "TIMe Essentials" will tell you why you should use TIMe and what is special about it. "Object and Property Models - and the Languages for describing them" introduces UML, MSC and SDL for those that are not familiar with them. "TIMe Essentials" provides an overview. The rest of the document is organized mainly according to the development activities of the method (see "System Development Activities").
Supplementing elements of TIMe
As mentioned above, the full method book of TIMe contains important elements that for reasons of space are not covered in this introduction:
- Verification and validation deals with "validation", meaning to determine "whether we are making the right system" and "verification", meaning to determine "whether we are making the system right". TIMe presents several different approaches to verification and validation that correspond to different maturity levels of the companies (or projects):
test orientation: performed on the implementation of the system.
inspection orientation: involves human readers who control the quality of the descriptions.
animation orientation: executions of the system based on descriptions on higher abstraction levels than implementation.
formal analysis orientation: used in order to prove statements about the system, or to disclose hidden aspects of a system.
synthesis orientation: the implementation can be synthesised from a description of the requirements.
TIMe presents techniques on all these levels. TIMe considers constructive rules to be superior to corrective measures.
We talk about achieving improved productivity and quality by setting goals and following one of several improvement methods, like "Mean & Lean", the Capability Maturity Model (CMM) or the Risk Management Approach.
It also discusses Risk Assessment and Control, as well as Change Cost Analysis and measuring the effect of introducing new tools and methods.
- Software configuration management covers how to control a product (in terms of descriptions) as it evolves. It describes levels of control and management, and describes means to cope with the complexity of product management.
It presents our view on Configuration Management, which should help in defining plans for projects and companies.
We identify 3 levels of control and management that can be useful: to achieve Configuration Management we need a platform for Configuration Control. To achieve Configuration Control we need a platform for Version Control.
We give an indication of what can be obtained by state-of-the-art tools at each level.
- Metrics is about measurement in software development, a field that is known as metrics or software metrics. TIMe gives the answers to the questions
Why are we collecting measurement data?
A method that focuses on this, GQM - The Goal Question Metrics, is presented. It also discusses how to define useful metrics, and presents a few individual metrics.
TIMe is a development of the Norwegian SISU I methodology described in Engineering Real Time Systems (Bræk and Haugen 1993, [24]). TIMe has been continually developed since its inception in the SISU I project (1988 - 1991) (1992-1996), see http://www.sintef.no/sisu - and has its name from the fact that it consists of an integration of method elements from different parts of the project. For people with no relation to the project, TIMe could as well have been an acronym for The Interesting Method, The Important Method, etc.
TIMe saves time first time
Experience from the SISU project has show that TIMe can give you:
- 50% reduction in errors in delivered systems
- reduced development costs equalling or surpassing the cost of introduction on the first project
- 20% or more reduction of development costs on subsequent projects
- better control over the development process
- more flexible staffing, with less dependency on individuals
- smoother cooperation between professionals
when TIMe is carefully introduced into an development organisation, compared to a non-TIMe development paradigm. Some of these claims are proven by metrics programs in the SISU project, while others are based on interviews with managers.
TIMe is fun
Systems and software designers using TIMe typically experience
- more focus on designing functionality
- more precise communication with peers on design issues
- the pleasure of simulating (executing) designs at an early stage
- modern, state-of-the-art development tools
- less dependence on detailed development environment know-how, more focus on domain knowledge, making for easier shifts to new projects
- easier maintenance, simpler error correction
- the initial burden of learning a new development paradigm being outweighed by a better working environment and more job possibilities
The Why, What and How of TIMe
For the development of complex telecom, real-time or reactive systems in general, a promising combination is to use:
- Object Orientation as a common approach to analysis, design and implementation, with concurrent processes as objects;
- Interaction Scenarios for the specification of communication between users and systems (use cases) and between objects of systems;
- State/Transition based specification of behaviour of individual objects.
Object orientation helps to master complexity by structuring in terms of objects and by factoring out common properties in general classes. Objects do not live on their own but communicate with other objects. Interaction Scenarios help to describe and understand even the most complex interaction cases. Describing the behaviour of each object in terms of states and transitions that are triggered by incoming signals from other objects has proven to be of great value for this kind of system.
The combined use of UML, MSC and SDL
TIMe supports this combination by the integrated use of
- UML for object model analysis,
- MSC for interaction scenarios, and
- SDL for specification and design of behaviour.
UML and SDL both support object orientation, there are tools integrating them, and the same tools also support MSC. UML is an OMG standard, while SDL and MSC are standards from ITU.
Why not just UML?
UML is accepted by the Object Management Group (OMG) as a Visual Modeling Language, and has received much attention from the software engineering community. The establishment of the UML Revision Task Force gives the potential methods user confidence that this will become the new industry language for systems design. However, UML is not mature enough to be adopted in its present form as a design language in an industrial context:
- The language is not yet stable, with considerable changes between 1.0 [21], 1.1 [146] and 1.2 [147], and more.
- Support for real time concepts is only partial
- The language is not formally defined, with a self-referential meta-model and a semantics written in prose.
- The interchange format is not yet stable.
- Several textbooks exist [22], [51], [60], [112], [166], but many include features that do not adhere to the approved standard [146].
- No tools fully support UML, although many promise they will [149], [155], [156], [157].
For these reasons UML is not yet the ultimate, all-compassing language that its founders aim it to be. TIMe recognizes UML as a substantial improvement over predecessors like OMT [165], and currently recommends that parts of UML be used, along with industrial description languages like MSC and SDL, especially for illustrative sketches in early phases. If UML turns out to be what its founders aim at, while MSC and SDL do not evolve, TIMe may in the future become a UML methodology.
Presently we believe the combination of UML along with SDL and MSC following the formal rules to be defined by the ITU in the forthcoming Z.109 standard "SDL with UML" is the most promising. This is the strategy taken by the major SDL tool vendors [153], [154].
What about OMT?
OMT [165] is in widespread use, and many tools are available. TIMe sees OMT as an informal notation (not a language), and recommends that OMT be used in the same way as UML, so that the transition from OMT to UML has little risk involved. Version 3.1 of TIMe included an extension to OMT called OMT+-, which has now been discontinued.
Why UML and not just SDL?
Some companies have an established use of MSC/SDL, but for early analysis they normally use informal drawings. In order to become a little more precise, it could be argued that SDL can be used for this purpose. It has benefits in that it will ease the shift to design in SDL, but we advocate the use of UML for the following reasons:
- UML models do not require the same degree of formalization as SDL models do,
- UML supports relations (associations) between objects,
- UML supports fragments of object models, e.g. specifying relations in one fragment and attributes/operations in another.
However, TIMe also advocates that SDL is used for object modelling in case this is most appropriate. As an example, if it is important during analysis to specify some main states (modes) the system may be in, then this may directly be specified in SDL, as opposed to Statecharts in UML.
Why MSC and not Sequence Diagrams or Event Traces?
Some companies have chosen to go Object Oriented by means of UML or OMT. Tools for UML support Sequence Diagrams (and OMT tools supported Event Traces) for the formulation of properties of interactions, and to some degree these are integrated with the object modelling. The reasons for choosing MSC are still:
- MSC is more precise and richer in expression than Sequence Diagrams or Event Traces. HMSC, MSC references, conditions and in-line expressions are some of the distinguishing features of MSC.
- The instances in a Sequence Diagrams or in an Event Trace are objects from the object model, but often they should rather just be roles played by objects. Instances in MSC diagrams can represent both objects and roles.
Why SDL and not Statecharts?
In some literature on state machine based specification of behaviour, Statecharts [76] as used in UML is the preferred notation. The reason for this is that the notion of nested states is appealing and that it produces compact specifications1. Statecharts alone is, however, not a complete language. It does not define communicating objects with data having the behaviour specified, so other notations and/or tools often add this. The main reason for using SDL is exactly that:
- SDL is a complete language that defines communicating objects (processes) with data attributes, operations and behaviour in terms of states and transitions;
- it also defines a structure of subsystems (blocks), and
- because it is a complete language, tools can (and do) support code generation from SDL specifications, and the integration with MSC allows for some degree of formal verification and validation.
In addition, inheritance from the object model can be directly mapped onto inheritance for SDL process types, including inheritance of attributes, operations and behaviour (that is inheritance of states and transitions). This means that, if desired, it is possible to inherit "functionality" and not just "interfaces".
Another line of reasoning is that an interchange format for SDL descriptions between different tools is standardised [109] - this eases the transition from one tool vendor to another.
Are MSC and SDL perfect?
The above discussions are not meant to promote MSC and SDL as "the perfect languages". They are not. There are thing we miss in MSC, such as guard conditions, transitions names and the possibility to express constrains. There are things missing from SDL, not only the obvious lack of relations (which we recommend be expressed in UML), but also a number of niceties such as substates (i.e. the compact description they give, which SDL Procedures lack), for/while loops, expressions of algorithms and a dozen other issues.2
Neither MSC nor SDL are capable of formally defining execution time constraints, or expressing exact real-time behaviour in terms of process interleaving. Hence TIMe does not address mission-critical, "hard real-time" systems. Certain vendor-dependent solutions to this are provided by tool vendors [153].
We nevertheless recommend that MSC and SDL be used for the types of systems target by TIMe for detailed design and systems generation in an industrial context. MSC and SDL have proved themselves in many real-life projects, and are mature, albeit not perfect. UML is still promiseware.
Why a separate method on the combined use?
In conclusion, the combined use of UML, SDL and MSC seems a good idea. But there are still some issues to consider when using two slightly different object oriented approaches as represented by UML and SDL:
- uncritical use of relations (associations) will lead to problems when turning to design in SDL;
- aggregation was a special association in OMT, while UML and SDL support "real aggregation" (called composition in UML);
- UML (and OMT) supports multiple inheritance (the semantics of which will first become clear during design), while SDL supports single inheritance only - careful use of inheritance is therefore an issue.
In addition comes the object orientation you may have to use when considering distribution, e.g. CORBA, and this is yet another approach. TIMe has the answer on how to isolate the application specific aspects from the distribution aspects.
Why use TIMe?
There are already a number of methods supporting the combined use of UML, MSC and SDL, two of these are supported by tool vendors [174], [180]. Still there are some valid reasons for using TIMe:
- Most methods have a bias towards object modeling - "just find the objects and you are done". TIMe comes with a system reference model and emphasises property modeling as equally important as object modeling. Property modeling includes use case modeling as a special case.
- TIMe has an answer to where the design objects come from and does not just provide technical guidelines for how to go from UML to SDL.
- As a mechanism not supported by other methods, TIMe tells you how to make frameworks in SDL. Frameworks produce the most effective reuse.
- TIMe represents many years of experience with system development and object orientation.
- TIMe bridges the gap between the user's world of needs and the designer's world of objects.
TIMe can be used as a supplement to other methods. Tool vendor specific methods will always be useful, as their elements most probably will be supported by the tools.
How to use TIMe?
TIMe is available both as printed material and as an "electronic book". The electronic version allows you to follow links in order to read what you want, e.g. at a specific stage in the development process. The electronic version allows for company specific extensions, with links into and out of those parts of TIMe that are used.
TIMe Essentials
This section gives a description of the essential elements of TIMe and what makes it different from other methods.
We differentiate between Systems and system descriptions, and show that Systems consist of objects. Objects and systems have properties.
We talk about Properties and Roles of objects, and distinguish between Interface and application given aspects and Domain, interface and system given aspects of objects. These views are important when designing for reuse.
There are Abstract and concrete descriptions, of which Application and Infrastructure are examples of the former.
Important TIMe notions are Families of systems, and Frameworks as a mechanism for defining them.
Below you will also find a glance at the Languages and notations of TIMe, including UML for analysis and design object modelling, MSC for specifying interaction scenarios and SDL for design and for specifying behaviour.
Systems and system descriptions
TIMe is a system development method. A system is a part of the world that a person or group of persons during some time interval and for some purpose choose to regard as a whole, consisting of interrelated components, each component characterised by properties that are selected as being relevant to the purpose. A system is not a description on a piece of paper, but something actually existing as a phenomenon in the real world. This puts the system apart from the description of the system. The system actually exhibits behaviour, while its description is a dead pile of paper.
Systems made by means of TIMe (and by means of many other methods) are produced by making descriptions in a variety of languages and notations. These descriptions prescribe how systems should be generated by having computers and similar equipment ( platforms) execute these descriptions.
Systems consist of objects. In order to describe them, classes of objects are defined and described. In short, methods consist of approaches, guidelines and techniques for identifying and describing classes of objects.
Properties and objects
TIMe has the two dimensions properties and objects as integral parts of the method.
Systems consist of objects. Objects and systems have properties
A system consists of a set of objects. Objects are described by:
- Object models, that model how a system or a set of related classes are composed from objects, connections and relationships.
Systems and objects have properties (both provided and required). Properties are described by:
- property models, that model the properties of a system or object without prescribing a particular content or implementation.
Object models are constructive in the sense that they describe how an object is composed from parts, and is the perspective of designers. Property models are not constructive, but are used to characterise an object from the outside: behaviour properties, performance properties, maintenance properties, etc. This is the perspective preferred by users and sales persons. It is also the main perspective in specifications.
TIMe provides some of the answers to the challenge of system development: to identify objects and give them properties so that they contribute to the properties required of the whole system, see Figure 5.
Properties
A central idea in TIMe is that every object (and system) is characterised by provided properties that can be matched against required properties (see Figure 6).
Of special interest are interaction properties, where a property involves the interaction between the system and one or more users of the system or other systems in the environment, or between objects in the system. The "accept/reject user" property in
Figure 5 is an example of this: it involves the user entering the card and code to the system, and the system answering back with either OK or not OK to enter. In Figure 7, part of this is specified in MSC.
Figure 5 only indicates that access point objects are involved, but during the design we shall see that both panels and a central unit will be involved.
Roles
TIMe makes it possible to express property models without referring to specific objects. Sometimes we need to specify properties without knowing the objects they shall be associated with, and we may want several different objects to share the same properties (e.g. a common interface). TIMe also makes it possible to compose the properties of an object from parts described in different property models.
The notion of role makes this possible. Roles are used to represent objects in property models, and we may compose the properties of an object from roles described in different property models.
One of the instances in the MSC in Figure 7 is "AccessGranting". This is not an object of the object model, but a functional role. Behind this name cab be hidden any structure of interacting objects. At some point in the development it is necessary to associate the functional role with an object of the object model. We call this synthesis.
TIMe uses three main categories of roles:
- service roles, which are the observable behaviour of an object in a given service;
- interface roles, which are the observable behaviour at given interfaces;
- association roles, which are the conceptual constraints on objects that participate in associations (relationships).
Interface and application given aspects
TIMe makes a distinction between the (user) interface given aspects of objects, and application given aspects of objects, see Figure 8.
In some cases these are two different sets of objects, in other cases they are just two different aspects of objects - this is indicated by the jagged line in Figure 8. The important thing is to make the distinction and be able to maintain it. The interface may change e.g. with new technology, while the application objects providing the service properties of the system will typically have a longer life.
We shall later see that the application given aspects can be decomposed into system given and domain given aspects.
Systems belong to domains and are used in environments
TIMe makes a distinction between a domain, the systems within the domain, and the environments in which the systems are used. While systems belong to a domain, in that they handle the same types of phenomena, they exist and are used in an actual environment, see Figure 9. Accounting systems are different from access control systems in that they belong to different domains. The example system in this introduction to TIMe belongs to the access control domain, and that includes phenomena and concepts like access point (where users get access or not), access zones (to which users would like to get access), PIN codes, etc.
The domain models a part of the real world having similar needs and terminology where a system instance may be a solution to some need. The domain is not specific to a particular system or system family, but rather to a market segment. It covers common phenomena, concepts and processes that need to be supported irrespective of particular system solutions.
Required properties derived from an actual use situation may come in addition to the properties stemming from a domain. Properties required by the actual environment and by its realization are very specific, while domain-given properties are often more general and express idealized needs.
Domain, interface and system given aspects
Domain objects and their properties are not enough to provide the required properties of the whole system. Many general properties can be provided by the domain given objects, but some properties will often be required in addition. For instance properties related to the operation and maintenance of a specific system.
This is reflected in the system reference model of TIMe: In addition to the domain and interface given (aspects of) objects, the application given objects may have some aspects that are special for this specific system, in addition to the general properties of domain given objects.
The object model of a system is therefore divided into three aspects:
These aspects may be whole objects or just aspects of objects.
Domain given aspects come from an analysis of the domain, interface given aspects have to do with user interface, interface to other systems or to controlled equipment, while system given aspects are those aspects that arise because there is a system, and that are specific for the system.
Domain given aspects have a larger potential for being reused in other systems in the same domain than the system given aspects, and interface aspects may have to be modified when the interface technology changes.
The interface given aspects of the access control system are illustrated in Table 1.
Abstract and concrete descriptions
Descriptions suitable for execution by existing platforms contain a lot of detailed, concrete description elements (implementation details, platform specific details, etc.). Descriptions suitable for system developers in their strive to match required properties expressed by users, owners o.a. are preferably more abstract in the sense that they describe systems in terms that reflect established concepts within a given domain.
TIMe achieves abstraction by supporting UML and MSC for analysis models and SDL for design models. UML is a notation that enables informal, abstract object models, MSC describes use cases and interaction between objects, and SDL supports abstract descriptions that (by including concrete description elements) automatically may be transformed to concrete implementations. The use of abstract descriptions is one of the main ingredients in property oriented development.
Infrastructure
- an infrastructure part that describes additional behaviour and supporting functionality that needs consideration, e.g. in order to fully simulate its behaviour. This may e.g. include support for distribution, exception handling etc.
The reason for this distinction is that systems within the same domain and in the same family (see below) often will have the same infrastructure part, but different application parts. Reuse of infrastructure is eased by keeping them separate, and application evolution is simplified.
Concrete models describe the implementation architecture. This is a high level description of the physical implementation. The purpose is to give a unified overview over the implementation and to document the major implementation design decisions.
Each object has attributes and behaviour, is related to other objects, and is structured for two different reasons:
Content
2. so that the object is completely defined with respect to its realization on the executing platform. We will talk about the contents of the objects in contrast to its context, see Figure 10.
Analysis will produce
specifications of objects, while design and implementation activities will produce
designs of objects. In specifications the object context and external properties are defined. Some limited parts of the content may also be specified, see Figure 10. In the design the remaining content is defined. The specification of an object includes what is needed to use the object - and that may be more than just an interface specification.
When deciding upon what belongs to the domain and what is more system specific, the main distinction is between the domain and single systems within the domain. During development we often think in terms of making one specific system. We talk about the "system" and the "domain", and about e.g. "system specification" and "system design".
Families
It is, however, fruitful to think in terms of families of systems and really make "system family specifications" and "system family designs". The idea is to focus development and maintenance effort mainly on the families, in order to reduce the cost and time needed to produce each particular instance, and to reduce the cost and time needed to maintain and evolve the product base.
A system family is a generalised system or set of component types (classes) that can be configured and instantiated to fit into a suitable range of user environments. They represent the product base from which a company can make a business out of producing and selling instances.
TIMe provides guidelines on how to make system families in addition to single systems. Where practical, system types and classes will be defined from which complete system instances may be generated.
Frameworks
The notion of framework is one important mechanism for defining families of systems. A family comprises more than just a type of system from which several system instances can be generated. In addition a family includes e.g. the necessary documentation, manuals, etc. that make up a complete product.
At the heart of a system family lies the parts that are generated from an SDL design. This may either be a complete SDL system, a set of SDL systems, or a set of general block types and process types that can be (re)used for making systems.
Application and infrastructure
The SDL descriptions will be organised according to the distinction between application and 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 different systems it is desirable not to change or even consider the infrastructure part (besides what it offers). A framework defines the composition of the infrastructure parts and application parts in such a way that different systems can be made by only changing the application parts.
The notion of framework is not special for TIMe. Within the field of object orientation, a framework is well-known ( "In object oriented systems, a set of classes that embodies an abstract design for solutions to a number of related problems." - Free On-line Dictionary of Computing ), and there are good examples of frameworks, e.g. window systems. The use of frameworks supports the (re)use of whole designs and not only single classes.
What is special for TIMe, however, is that this idea is adapted to SDL. A framework can be defined as an SDL system type, and the different systems as instances of subtypes of this system type. TIMe provides detailed guidelines for how to do this.
Languages and notations of TIMe
The main languages and notations of TIMe are UML, MSC and SDL. For readers not familiar with these, please consult "Object and Property Models - and the Languages for describing them". The following is a very short introduction.
TIMe uses a UML for object modeling in terms of
- classes (with attributes and operations) representing application specific concepts, with relations (associations) and communication links;
- inheritance between classes in order to express specialization of application concepts;
- aggregation, that is objects defined by means of part objects.
TIMe defines its own approach to object orientation, and UML is used as a notation for expressing this. UML matches the TIMe object orientation better than OMT.
MSC
for specifying interaction scenarios
TIMe uses MSC as its basic notation for property modeling. MSC highlights interaction between instances based on messages. Instances may represent objects from some object model or just roles played by some objects. A message is asynchronous, the output must come before the corresponding input. The events on the timeline of an instance are strictly ordered, and the distance between events is not significant.
An MSC document consists of a set of MSCs. Different MSCs within the same MSC document are related by conditions. A condition is a label which signifies a global or local state. Conditions can be used to mark situations where there are different alternative continuations, and they may describe looping.
Instances may be decomposed, in order to see the details of this in terms of further MSC diagrams.
SDL
for design and for specifying behaviour
SDL is the main language for design, and the only language for specifying behaviour.
An SDL system consists of a number of blocks, connected by channels. Each block may either consist of a substructure of blocks, or of a set of processes connected by signal routes.
Processes execute concurrently, communicate by sending signals (non-synchronized), and have their behaviour described in Finite State Machines extended with variables, procedures and transitions.
SDL may define types and subtypes of systems, blocks and processes.
