Patterns for Extending an OO Model with Temporal Features

Patterns for Extending an OO Model with Temporal Features Rébecca Deneckère, Carine Souveyet Université Paris 1 Panthéon-Sorbonne, Centre de recherche en informatique 90 rue de Tolbiac 75013 PARIS, France, tel : + 33 (0) 1 40 77 46 34, fax : + 33 (0) 1 40 77 19 54, email : {denecker, souveyet}@univ-paris1.fr

Abstract We identify a set of generic patterns which can be used to introduce temporal features in existing OO models. Patterns are generic in the sense that they are applicable to any OO model having the basic features of class, attribute, domain and class association. The paper shows the application of these patterns to the O* model. keywords : method engineering, patterns and frameworks, object-oriented method, temporal database.

1. Introduction Several method engineering approaches [1] have been developed for adapting existing methods to the project at hand [2][3][4][5]. Assembling components from various methods for constructing a method « on the fly » [4] is the approach we are exploring in the CREWS Esprit project1. This assembly process relies on two types of components : those that can be used directly and those that have to be generated from generic patterns. In this paper, we focus only on the second type of components called « generic patterns ». The concept of pattern has been widely used in the software development community during the last 20 years in particular by those practising ObjectOriented (OO) approaches. It has been more recently introduced in the Method Engineering community. All these efforts aim to reuse the best practices of a method in another one. Therefore, this concept is usually used in the context of reuse. In the OO community, the focus has been put on patterns useful during the design of software and independent of any particular domain [6][7][8][9][10][11][12][13] In the Method Engineering community, generic patterns aim at proposing a means for constructing situation specific methods. Such patterns encapsulate knowledge

1

Basic Research Action CREWS (ESPRIT N°21.903). CREWS stands for Cooperative Requirements Engineering With scenarios.

about processes that can be reused and applied in different settings. They allow to guide method engineers in the construction of methods. Much of the contemporary work on patterns has been inspired by the work of C. Alexander on the use of patterns within the domain of architecture [14]. In [15] a pattern is described as “a problem which occurs over an over again in our environment and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing the same twice”. Here, the emphasis is put on the fact that a pattern describes a recurrent problem and is defined with its associate core solution. The paper aims at proposing a set of generic patterns which can be used to introduce temporal features in existing OO models having the basic features of class, attribute, domain and class association. These patterns have been developed and used in the TOOBIS esprit project2 for defining the TOOBIS method [16] which has been used to develop two real temporal applications, of general scope : one in the management of treatment protocols for health applications and the other one in the management and distribution implementation of Fresh Milk products. The paper is organised as follows. The « pattern » notion is discussed in section 2. An overview of specific requirements of temporal database applications is given in Section 3. Then, section 4 presents the set of generic patterns extending any OO model with temporal features and their appliance to the O* model [17][18]. Finally, we conclude in Section 5.

2. The notion of a pattern The key idea concerning patterns is the fact that a pattern relates a problem to its solution. Therefore, a set of desirable properties for a pattern must include the problem for which the pattern proposes a reusable knowledge, the solution describing this knowledge and its context of use. A context refers to a recurring set of situations in which the pattern applies. The solution proposed by a pattern is a process chunk to apply on a particular product. Therefore, the body of a pattern encapsulated the process description as well as the definition of the product under modification. The guideline part (see figure 1) represents the process description whereas the product part (see figure 1) corresponds to the product definition. The body contains the guidelines to be followed when the pattern is applied. The body can have either a formal or an informal expression. Formal bodies are expressed using the NATURE process modelling formalism [19], [20]. Detailed examples of such descriptions can be found in [3], [5]. Informal bodies are expressed in natural language.

2

TOOBIS (ESPRIT N° 20671) stands for Temporal Object Oriented dataBases & Information Systems. This project aims to define a temporal OO DBMS on the DBMS O2 with a specific conceptual method.

The application of the guidelines embedded in the body leads in our case to update the OO model of the method to be extended. Therefore, the product part represents the set of concepts of a OO model to extend. The aim of our generic patterns is to extend this set of concepts in order to handle specific temporal features at the modelling level. Pattern has Body Guideline

Product

Figure 1 : The Body part of a pattern.

The interface of a pattern explains in which situation and for which intention the pattern is applicable. Therefore, it is a triplet associated to a body. The interface is the visible part of the pattern. The situation is a part of the OO model to be extended. The intention refers to the extension. The interface is an example. The result of the application will be the OO model including the calendar class. The body explains how to proceed to fulfil the intention in that particular situation. Intention

Define a calendar class description

Situation Product definition : M [class] (input)

Pattern body

Target Product definition M [class, calendar class] (output)

Figure 2: The interface part of a pattern

Figure 3 shows the structure of a pattern as counting of three aspects: the reusability, applicability and the reusable knowledge. The reusability aspects are managed by the descriptor part whereas the applicability aspects are handled by the interface part. The reusable knowledge is described in the body. The descriptor part of a pattern identifies the context in which it will be useful to reuse it. A descriptor is a couple . The pattern supporting the intention « Define a calendar class description », is described by the following situation : (application requirements : « Need for time referential » ; current model situation : « The model doesn’t include specific concept for describing user defined time referential »). Descriptor Interface Knowledge to reuse

Pattern body

Reusability aspects Applicability aspects

Figure 3: The pattern-structure

The pattern notion explained in this section is used to define solutions to the problems identified in the following section.

3. Temporal database applications domain The importance of time in the database area has been realised since 1975. Applications require to deal with past, present and future data. Conventional databases are designed to store and retrieve current data. During update operations, data are erased and replaced by their new values. This means that past data are no longer available in the database and only current data are kept. This justifies the addition of mechanisms dedicated to model, retrieve, store and modify time dependent data. This has led to the introduction of SQL/T (temporal extension of SQL) in SQL3. This new generation of temporal DBMS integrates time into the data model in order to facilitate the management of temporal aspects at the application layer. Such DBMS have simplified the storage and the retrieval of temporal data. But, they don’t solve design problems such as the definition of the data schema, specification of the activities of the application, verification of the consistency of the temporal database and provide no guideline to administer a database. The introduction of temporal features into OO models is still under investigation [21]. We have identified the six following temporal requirements which are required for designing temporal database applications, of general scope : Time referential problem The concept usually used to measure time is the one of a calendar. It is a metric system to apply on the time line. Most of the basic OO models use the time of the system clock which is the Gregorian calendar. But in the reality, an organisation needs to manage different calendars or different granularities at the same time for synchronising different kinds of activity. For instance, an hospital organises the salary management with the Gregorian Calendar whereas observation of patients is managed with a specific Observation Calendar (a turn is every 6 hours) for instance. Meanwhile the accounting activities of this hospital follow a specific accounting calendar (a year begins in September). Because applications may need specific calendar (one or several) and may need also to manage time at different level (week, second, hour etc.), OO models should provide specific concepts for modelling the use of different calendars and granularities. Temporal domains problem In classical OO models, the only way for an attribute to have a time domain is to select one of the following types : Date, Time and Timezone. However, these collection of types may not be sufficient for applications. For instance, a period of time (which is often modelled with two Date attributes begin and end) or a quantity

of time called interval (which is designed as a numeric type) are abstractions useful to use with their associated operators. For instance, when you want to add 20 days to a period of time or when you want to add 10 months to an interval etc.. Besides absolute time, there is a need for managing relative time in applications of general scope. For example, the attribute starting_date of a task may be expressed relatively (20 days after) to the end of a previous one which is not yet finished. In addition to the time referential problem (explained above), OO models should provide rich temporal domains allowing to manipulate absolute and relative time but also help in the management of periods of time and quantities of time. Object time stamping problem The application engineer may want to time stamp data with different time semantics. For instance, the attribute order-date represents the ordering date of the client : the true date of the reality, whereas the attribute last-modification represents the time when the order is registered is known in the database. The former is called valid time and the latter is called transaction time. Time stamping with valid and/or transaction time of data is often used and managed by at the application. However, OO models should provide specific concepts for supporting the time semantic definition and its management during the database operations such as insertion, update and deletion. External event time stamping problem Happening of external stimuli recognised by the application needs to be situated in the time line according to their valid time. It is required for organisations which are led to perform sensitive activities in advance or with a certain delay. For example, “increase the salary of an employee” induces different treatments according to its valid date. If the treatment is done in advance, the salary change must be taken into account only when its valid date becomes the current date whereas a delayed salary change requires a corrective payment. Therefore, OO models should provide specific concepts to differentiate these three different happenings of the same external stimuli. Object historisation problem Histories are sometimes required by applications. For instance, some may need to look at the evolution of the salary of an employee, and it is impossible if the application only keeps one state for this attribute. In addition, Replay function is more and more required for tracking decisional process of an organisation. Therefore, the information system should provide for each state of an object when it is/was true but also when it is/was exploitable. From this point of view, OO models should provide specific concepts to manage the object historisation with valid or/and transaction time. Time constraint problem

The application engineer may want to constrain the evolution of the data present in the database. Most of the OO models contain constraints on the objects. However, if the application engineer wants to handle time, the problem will be to constrain data evolution. For instance, the application may need to constrain the attribute Salary in order to forbid more than three increasing of its amount in one year. Therefore, OO models must include concepts helping the application engineer to define his constraints which are related to time or not. From each of these temporal problems, we have defined a generic solution that we have embedded in a pattern. Each of these patterns guides a method engineer in the adaptation process of his OO model for managing the temporal features associated to the pattern. The following section describes the six generic patterns dedicated to temporal features.

4. The temporal patterns This section presents six patterns dealing with the temporal features introduced in the previous section. Each pattern is presented as follows : the objective of the pattern, a table containing the pattern descriptor (situation and intention) and the pattern interface (the intention), a textual explanation of the body and an example of the use of the pattern. The examples take as the baseline the O* model.

4.1 Time referential pattern • Objective The pattern aims at generating the description of calendars. Descriptor : Situation Descriptor : Intention Interface : Application Current model situation Intention requirements Need for time The model doesn’t include specific Extend OO model by Define a calendar referential concept for describing user defined defining a calendar class class description time referential description Figure 4: time referential pattern

• Explanation The result of the pattern enactment is one calendar class description. The body of the pattern guides the generation of the calendar class description using a calendar template. As shown in Figure 4 the calendar class description has three parts : name, property and operation. The property comprises the origin of the calendar which is an instant and an ordered list of granules of different granularity constructed out of a basic granule. The operation part corresponds to the set of operations to perform conversion between granules of different granularities and also to perform conversion from this calendar to the Gregorian one.

Class

calendar class

origin property

operation

name

granule

Figure 5: meta-model obtained following the application of the time referential pattern

This pattern provides a calendar class which can be instantiated several times to get several calendars. In addition, the pattern provides also a default calendar which is the Gregorian calendar (instance of the Calendar class, defined in Figure 6). If the OO model doesn’t take this necessity into account, the pattern will adapt it for this use. For instance, an enterprise may use the Gregorian calendar in all its departments and working-days as the calendar in the staff department. As a result, it is necessary to define two calendars in the application (and also the mapping functions that will make the conversion between the two calendars). Calendar class Gregorian origin "01/01/0001:00:00:00" basic unit = chronon granules second : {1 basic unit, basic unit=1second} minute : {irregular} hour : {60 minutes, minute=1/60hour} day : {24 hours, hour=1/24day} month : {irregular} year : {12 months, mois=1/12 year} operations instant operator+ (instant, interval) instant operator+ (interval, instant) interval operator- (instant, instant) EndCalendarClass Figure 6: Definition of the Gregorian calendar

The minute and the month are irregular granules because their time quantity is not fixed. The minute represent usually 60 seconds (except when we add an intermediate second). On the same way, the number of days in a month is not fixed (28,29,30 or 31). • O* example The O* model matches the descriptor situation of the calendar class pattern. Indeed the model has the concept of calendar class in order to attach temporal events to it. At the object level, the calendar class has only one instance : the clock of the Gregorian calendar (which is not explicitly defined). Assume now that the application to be developed requires a specific calendar called « observation » calendar. Then, the pattern can be instantiated to generate « observation» calendar as shown in Figure 7. However, as this calendar requires a precise definition of the Gregorian calendar to which it refers, the pattern suggests

in its body to formally define the Gregorian calendar too and guides the generation of the Gregorian calendar according to the template. The result is shown in Figure 6. This extension proposes to describe, in an extensive way, the calendars used in the application by the way of a name, an origin (instant), a basic unit (granule), an ordered list of granules with their finer and coarser conversions, an operation of translation from an instant to a period, an operation of conversion between granules of the same calendar. If there is more than one calendar in the application, two conversion operations, one to the Predefined calendar and the other one coming from it (these two operations allow the conversions between calendars) are added to their definition. Calendar class ObservationCalendar origin ="1/01/01/0000" basic unit = hour of Gregorian calendar granules turn : { 6 basic unit, basic unit = 6 turns} day : { 4 turns, turn=1/4 day} month : { irregular} year : {12 months, month=1/12 year} operations instant operator + (instant, interval) interval operator + (instant, instant) instant operator - (instant, instant) instant conversion (