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 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).
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.
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").
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.
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.
TIMe is a development of the Norwegian SISU I methodology described in Engineering Real Time Systems (Bræk and Haugen 1993, ). 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.
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.
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.
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:
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 , 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 , .
OMT  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.
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:
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.
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:
In some literature on state machine based specification of behaviour, Statecharts  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:
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  - this eases the transition from one tool vendor to another.
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 .
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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".
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.
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.
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.
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 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.