Specifying Information System Dynamics in TROLLz Peter Hartel Thorsten Hartmann Jan Kusch Gunter Saakey
Extended Abstract 1
1 Introduction Information Systems are becoming more and more complex. They span over many di erent application domains, have to integrate several heterogeneous resources, and to cooperate with existing systems [SJH93]. Therefore it is important to model such systems on an abstract level without having to refer to implementation aspects. The following list states requirements towards a conceptual modeling approach:
The approach should be independent of implementation technologies. In the analysis
and early design phase one is concerned with a logical view on the system and not with its implementation. It has to support the modeling and design of structural as well as behavioral aspects of the system. The structural speci cation denotes the static properties of the system, i.e. the system entities, their attributes and static relationships. The behavioral part describes the allowed evolution of the system, i.e. the permitted and maybe mandatory state transitions. The approach should support declarative concepts to describe a system. In the phase of conceptual modeling we concentrate on what the system does and not how. Even so some operational concepts can be useful. Descriptive language feature are important in the analysis phase while operational concepts become more important in the early design. There should be a formal basis underlying the approach. The formality allows us to reason about properties of a model. We can proof the existence or absence of
1
Abt. Datenbanken, TU Braunschweig, Postfach 3329, D{38023 Braunschweig, Germany. Email:
[email protected]
Inst. f. Technische Informationssysteme, Univ. Magdeburg, Postfach 4120, D{39016 Magdeburg, Germany. Email:
[email protected] z Partially supported by ESPRIT BRA WG 6071 IS-CORE, DFG under Sa 465/1-3, and OBLOG Software S.A., Lisboa. 1 in Proceedings of workshop 'Formal Methods for Information System Dynamics', Techn. Report Univ. of Twente, p.53-64, 1994 2
certain facts. Besides the system veri cation we can validate the system if the speci cation is executable. Well de ned semantics are prerequisite to make speci cations executable. Since user are typically not familiar with formalisms the validation of a model might be even more important than its veri cation. Often, modeling has taken a structure-oriented way in that the structure of the system has been represented by a semantic data model [Che76]. These models do have a sound formal basis. However, the system dynamics in terms of the behavior of the components and the interactions between them have been neglected. On the other hand we do nd a set of formal languages which address the modeling of dynamics [Hoa85, Mil89, Rei85]. The process concept is central to many of these approaches They allow the modeling of concurrent systems in a descriptive way. Since they do not support the modeling of system structure they are not suited to be the solely formalism for conceptual modeling. Hybrid approaches [ISO84] were proposed to overcome this problem. These approaches combine several models to express the di erent aspects of a system. Usually the di erent models do not t together very well, they are rather unrelated. The evolution of the system structure due to the system behavior cannot be expressed easily. Since no common logical framework is underlying most hybrid approaches it is rather dicult to reason about the speci cation properties. Object-oriented approaches [RBP+91, Jac92] gained a lot of attraction in the past. They claim to be suited for the analysis and design of complex systems. The integration of static and dynamic aspects is part of the object-oriented paradigm. System modeling is centered around the object notion. Therefore object-orientation promises to overcome the limitation of the above mentioned approaches. Even so the currently very popular approaches [RBP+91, Jac92] lack formality. Even newer ones [CAB+ 94] which claim to have a more rigorous semantics are still very informal. The integration of behavior speci cation with the speci cation of structural aspects has been driving the investigation and development of the formal and object-oriented speci cation language TROLL [HSJ+94]. TROLL allows for a descriptive system speci cation which is independent of implementation aspects. Even so the language supports also more operational concepts. Like this TROLL can be used in early development phases where we try to capture requirements as well as in the early design phases. The object model underlying TROLL was rstly presented in [SSE87] where the object-oriented language OBLOG (object logic) was presented. This work was in uenced by algebraic speci cation techniques as well as temporal logic employed to behavior speci cation. The approach has evolved since then. OBLOG became a graphical approach for the design of information systems and a (commercial) CASE environment [ESD93], the OBLOG workbench, has been developed. OBLOG focuses on the design phase and supports a more operational dialect of the originally proposed language. In parallel TROLL was proposed to be a highlevel logical language for conceptual object modeling. TROLL and OBLOG take a particular perspective towards the modeling of Information Systems:
The system is regarded to be a collection of interacting, concurrent objects. Each object has a local state that evolves due to the occurrence of events in a discrete manner.
The behavior of components may depend on interactions with its environment, i.e. in general we are dealing with reactive systems.
In this paper, we want to show the di erent ways to specify object behavior in the TROLL language. We will explain the integration of the behavior speci cation with the structure speci cation. The next chapter gives a brief introduction to the basic TROLL concepts. Chapter 3 explains how to de ne behavior by constraints on the object evolution. We present in chapter 4 the means of TROLL for operational behavior speci cation. In the last chapter we wind up the paper with a brief comparison of TROLL and OBLOG and some conclusions.
2 Basic Concepts of TROLL
TROLL [HSJ+ 94] is a formal language for the speci cation of information systems. The basic ideas and concepts of TROLL can be characterized as follows:
Objects are sequential processes which can synchronize their lives through event
interactions. The life of an object starts with a birth event and may end with a death event. Objects encapsulate an internal state that can only be modi ed by means of events. Even though part of the object state is observable through attributes. Objects are classi ed in classes and have a unique identity. An object is described through a set of attributes and events. The object evolution is speci ed by a possible sequence of event occurrences and communications with other objects.
Di erent formalisms are integrated into an object-oriented framework to explain TROLL speci cations. Sorted rst order logic is the basis for state speci cation in TROLL. We use a dialect of linear rst order temporal logic and a CSP [Hoa85] based language to describe the object behavior. These formalisms build the sub-languages of TROLL. The temporal logic allows for dynamic constraints on the object evolution. The dialect used in TROLL embodies PDTL (past directed temporal logic) and FDTL (future directed temporal logic). The predicate logic is well embedded into this temporal logic. Formulae in FDTL state that some condition must be satis ed in the future. This condition may depend on the current state. PDTL refers to the history of the object. It states that some condition must have been satis ed in the past with respect to the present state. We will see examples for the use of temporal logic in the examples of the following sections. The past temporal logic contains operators like always , sometime , previous , always sincelast , and sometime sincelast , the latter two called bounded temporal quanti ers that state properties for a particular period of (abstract) time. Without giving a formal de nition here we provide only an intuitive description for two frequently used operators.
always p holds at position i p holds at position and all preceding positions. sometime p sincelast q holds at position i q held in state and p held in some state j
j
j
i
between states and (exclusively , inclusively ). The state is de ned as the maximum state where q held in the past, or as = ?1 if q did not hold in the past. i
j
i
j
i
i
For example we may use a formula always Balance>=0 in an account object speci cation to describe that a balance attribute has never had a negative value. Additionally TROLL provides a predicate after . after (evt) is true in all states reached by occurrence of the event denoted by event term evt. The future temporal logic contains operators like alwaysf , sometimef , next , until , and before , again the latter two state properties for a particular period of (abstract) time. The future tense operators are dual to the past tense operators. For a detailed discussion on the sub-languages of TROLL see [HSJ+94, JSHS91]. A formal de nition of TROLL based on the Object Speci cation Logic [SSC92] can be found in [Jun93]. The mathematical model behind a TROLL object is that of an object being an observable sequential process. The behavior of an object is de ned as a linear process consisting of the set of possible traces of event occurrences. More particular we regard sets of concurrent events (snapshots). We need snapshots for the modeling of communication. In terms of this process de nition the internal state of an object is de ned as a nite pre x of a possible snapshot trace, whereas an observation is de ned as a mapping from such traces to a set of attribute-value pairs. In this sense, objects are observable processes [SSE87, SE91]. An example event trace can be expressed pictorially as follows: event snapshot #
birth #
* e1 +
b
:::
h i ?!
|
en
death #
?! ?! h k i ?! h i e
{z
Life cycle pre x
d
}
Objects are related in various ways. A role describes a temporal specialization of an object having additional properties and/or restricted behavior. A specialization is considered to be a permanent role. Objects may be components of other objects which itself are called composite objects. In TROLL, the composition may change dynamically. Separately de ned objects may be connected through global interactions. Over objects, we may de ne views that contain only derived information over the current states of objects. We illustrate here the TROLL language on an example coming from the banking world. We will use other examples from this domain in the following chapters to illustrate and discuss the language. The rst speci cation describes account objects. Accounts may either be savings or checking accounts. object class Account identi cation ByNo:(No) attributes
Type:fsavings, checkingg. No:nat. Holder:|Customer|. balance:money initialized 0.00.
events
open(InitNo:nat, InitHolder:|Customer|, type:fsavings, checkingg)
birth changing
Type := type; No := InitNo; Holder := InitHolder.
withdraw(amount:money)
changing
balance := balance-amount.
deposit(amount:money)
changing
balance := balance+amount.
close
death. end object class
Account
Objects do have an internal identity which is independent of the current object state. Even so we may specify identi cation mechanisms for objects. Only objects which can be identi ed through their attribute values can be accessed by the system users. Accounts are identi ed by their numbers, i.e. the value of the No attribute. The data type |Customer| is the type of the internal identi ers for objects of class Customer. These internal identi ers allow to access the properties of the associated object. Since they are non-printable values they can be used inside the system, only. Attributes are typed and may be further characterized|here the initial value of the attribute balance is 0. The attributes de ne the observable object state. This state may be manipulated through events. Accounts allow for withdraw and deposit events. The open event creates a new account instance and close ceases the existence of an account. In order to describe the evolution of objects we have to state how event occurrences a ect the attributes, i.e. the current object state. In TROLL an attribute update is described in the changing section by stating the value of the attribute after the occurrence of an action. For an account, the balance increases if a deposit is made: deposit(amount:money)
changing
balance := balance+amount.
The meaning of the sentence is that the value of the attribute balance after the occurrence of deposit(amount) is given by the term on the right-hand side which is evaluated in the state before the event occurrence. The implicit frame assumption is that an attribute keeps its value if it is not changed by an event occurrence. This example showed very little of the behavior speci cation capabilities of TROLL. The state is speci ed through attributes and events allow for state manipulation. The life cycle of an account starts with an open event is followed by an arbitrary number of deposit and withdraw events and maybe nishes with a close event. Specifying objects like this does not go beyond typical object-oriented programming languages. The following sections will explain the language features of TROLL to describe more aspects of object behavior.
3 Constraining Object Evolution The philosophy behind behavior speci cation in TROLL is to constrain the admissible lifecycles of objects. There are di erent ways to constrain the allowed object evolution. 3.1
Local State Constraints
We may restrict the allowed values for object attributes, i.e. giving state constraints. These constraints are part of the attribute speci cation. We will consider again our account example. The following speci cation describes checking accounts. object class Checking-Account identi cation ByNo:(No) attributes
No:nat; Holder:|Customer|; balance:money initialized 0.00; creditLimit:money restricted creditLimit >= 0.00; red:boolean derived red = balance < 0.00.
constraints
(Balance >= - creditLimit); Red => eventually (not Red); initially (eventually Balance > 100.00
events
before
Red);
...
end object class
Checking-Account
We may constrain the range of an attribute by de ning a predicate over the attribute itself and constant values of its domain type. This predicate may not refer to any other attribute of the object. The formula after the keyword restricted must hold in every object state. In our example we de ned the creditLimit attribute to be greater or equal than 0.00. The constraints section allows for the speci cation of static and dynamic state invariants. Static constraints are formulae of rst order predicate logic while dynamic constraints are formulae of PDTL and FDTL. Constraints restrict the admissible behavior of objects. State transitions are only permitted if they do not violate any speci ed constraint. The di erence between constraints and restrictions is not only that we may use temporal logic, but also that we may relate several attributes of the same object. We de ned three constraints in our account example. The balance of a checking account may never be below the de ned credit-limit. This is expressed by: (Balance >= - creditLimit);
The other two constraints use temporal logic. Red =>
eventually (not
Red);
states that an account that is overdrawn must have a positive balance sometime in the future. The last constraint in our example is preceded by the keyword initially . Initial constraints have to be ful lled relatively to the initial state only. All the other constraints have to valid in all object states. The constraint
initially (eventually
Balance > 100.0
before
Red);
de nes that a checking account must have at least once a balance of 100.0 before it may be overdrawn. Derivation rules like we introduced for the attribute red are in fact a special form of constraint. They de ne the value of an attribute based on other attributes. We could also de ne this dependency in the constraints section. The di erence between derived and non-derived attributes is, that derived ones are not directly changeable through events. Local state constraints de ne the allowed values of object attributes. They have to be ful lled in all situations of the life of an object. This implies, that an event may only occur if the situation reached through its occurrence does respect all de ned constraints. If we interpret an event as a state transition, then the local state constraints de ne postconditions for the all events. They have to be satis ed by any event occurence. 3.2
Local Event Constraints
So far we restricted the object behavior through the de nition of attribute constraints, i.e. post-conditions for events. TROLL allows for the explicit de nition of pre-conditions for events, they are called enabling conditions. They specify under which condition an event may occur (but does not have to). Enabling conditions can be formulated in predicate logic and PDTL. The speci cation fragment of checking accounts illustrates some enabling conditions. object class
Checking Account
...
events
... withdraw(amount:money) enabled sometime after (deposit(m))
changing
and
amount A.withdraw(amount) relationship ATMwithdraw
and
A.OID = ByNo(accNo)
The ATMwithdraw relationship de nes that the dispense event of the ATM M causes the withdraw event of the account which is identi ed by the given accNr. In TROLL this
causality between events is called interaction. An interaction de nes a constraint on the communicating objects. The two objects must synchronize their life cycles, i.e. the event of the callee is only enabled if the event of the called is enabled, too. In our example the ATM may only dispense money if the withdraw event on the related account may occur. Interactions are asymmetric, a withdraw event may occur without the occurrence of a dispense event. The interactions specify also the event parameters. In our example the amount to be dispensed is the amount to be withdrawn. Like this we may model data- ow. However, notice that this may also de ne additional constraints on the callee, if the called event restricts the allowed parameter values, these restrictions have to be obeyed by the callee, too. We explained in this section how to specify global behavior constraints which relate di erent objects of maybe di erent classes. All mechanisms introduced until now allow for a descriptive behavior speci cation. They describe the allowed states and state transitions of an Information System.
4 Operational Behavior Speci cation Sometimes it is more convenient to specify the object behavior in a more operational way. This is especially true if we want to de ne a very deterministic order over the possible event occurrences. In this case we explicitly want to write down life cycle patterns, i.e. sequences of events which have to be followed by the object. For this purpose we introduced a process language into TROLL. This language is some dialect of CSP [Hoa85] and very similar to the process language of [CGH92]. The following example shows some process speci cation for special account objects. object class
Special Account
...
process declaration
AccountLife = ( fBalance0.00g (deposit(m) | withdraw(m)) ) -> AccountLife end object class Special Account
A special account allows for withdraw and deposit events as long as the balance is greater than 0.00. If the balance is below zero we may deposit money only. It is possible to express this behavior constraint using temporal logic. The only restriction the process de nition gives is over the withdraw event. The equivalent enabling condition would look as follows: events
withdraw(amount:money)
enabled ((sometime after (deposit(m)) sincelast
(BalanceBalance .
It is not that obvious what this enabling condition means. Therefore a more operational way to express behavior is useful. There are various ways to specify processes in TROLL. Processes may be combined with several operators. In our example we used the choice and sequencing operator. Further
open * idle ?c setCreditLimit
?a deposit
withdraw
?b close +
a: balance - witdraw.amount = 0
Figure 1: Account Behavior Diagram on we de ned a recursive process. Processes may be build in a hierarchical way, by the de nition of subprocesses which are used to de ne more complex processes. It is possible to specify the interleaving of di erent processes with di erent degrees of liberalism. The process language is embedded into the PDTL. The speci ed process fragments can be translated into enabling conditions in PDTL [Saa93].
5 Conclusions TROLL and the OBLOG language are siblings. The are based on the same semantic foundations. Anyway OBLOG took a much more operational way than TROLL and focusses more on system design than analysis. We want to nish this paper by giving a brief summary on the means of OBLOG to specify behavior. OBLOG allows in the same way as TROLL for the speci cation of attributes and events. Even so the syntax is quite di erent. The OBLOG language is graphical. There is no possibility of de ne in a declarative way local state or event constraints. The object behavior is fully de ned in a situation transition graph which is similar to state charts of [Har87]. A state transition graph is composed of situations and transitions. Situations do have no meaning besides de ning an implicit state attribute. A transition is de ned by two situations, an event and a possible enabling condition. A transition departs from a situation and leads to a situation. The only exceptions of this rule are birth and death transitions. During its life an object is always in a well de ned situation. Those events which are part of a transition departing from the current object situation are allowed to occur, of course only if an associated enabling condition is satis ed. The global behavior constraints of OBLOG are restricted to interactions, i.e. the de nition of global causality relationships between events. Figure 1 illustrates a simple OBLOG behavior diagram for account objects.
We have argued in this paper for a strong support of formal speci cations of object behavior. These speci cations must be fully integrated with the speci cation of other aspects of objects, in particular the evolution of states and interactions between objects. We showed in this paper the various ways to specify behavior in the formal, objectoriented speci cation language TROLL. TROLL emphasizes on a declarative speci cation style. A speci cation de nes the admissible object states and state transitions. Like this a restriction on allowed life cycles, i.e. sequences of event occurrences (or sets of concurrent events) are de ned. The following list summarizes the features of TROLL to model system dynamics.
Local state constraints are expressed in rst order predicate logic, future, and past
tense logic. They allow for the de nition of state invariants local to one object. These invariants have to be valid in all object states. They de ne implicit postconditions to be satisi ed by all events of an object. Local event constraints are formulae in rst order predicate logic and past tense logic. They de ne enabling conditions for events. An event may only occur if its precondition is satis ed. The condition is local to the object. It may refer to the current object state and its history. Global behavior constraints relate the state of di erent objects. They may also be used to de ne a causality between events of di erent objects. The process de nition allows for an operational behavior speci cation. A process de nes explicitly an order (maybe partial) over the events.
The combination of declarative and operational means for behavior speci cation should be o ered. Only then the natural speci cation of various sorts of behavior is possible. For objects that have much freedom in behavior (i.e. there are many admissible life cycles), a declarative way is preferable, whereas for objects with a very deterministic behavior (i.e. a small number of admissible life cycles) a process-oriented way should be employed. The importance of integrating the behavior speci cation with state evolution and interactions must be emphasized again. Currently, work is underway to combine declarative ways of behavior speci cation with graphical speci cation formalisms as o ered by OBLOG and proposed by [Har87]. A rst result of this attempt is the modeling language omTroll [JWH+ 94].
Acknowledgements We are grateful to Prof. H.-D. Ehrich and Prof. A. Sernadas who developed the original ideas and foundations of OBLOG and TROLL. The work of Dr. R. Jungclaus in the TROLL group has been fundamental to the development of the language. Thanks are due to Prof. C. Sernadas for her participation in the de nition of TROLL and all our colleagues in Braunschweig and Lisbon.
References
[CAB+ 94] D. Coleman, P. Arnold, S. Bodo , S. Dollin, H. Gilchrist, F. Hayes, and P. Jeremes. Object-oriented Development - The Fusion Method. Prentice-Hall, 1994. [CGH92] S. Conrad, M. Gogolla, and R. Herzig. TROLL light : A Core Language for Specifying Objects. Informatik-Bericht 92{02, TU Braunschweig, 1992. [Che76] P. Chen. The Entity-Relationship Model{Toward a Uni ed View of Data. ACM Transactions on Database Systems, 1(1):9{36, 1976. [ESD93] ESDI. OBLOG CASE V1.0 - The User's Guide. Espirito Santo Data Informatica S.A. Lisbon, 1993. [Har87] D. Harel. Statecharts: a visual formalism for complex systems. Science of Computer Programming, 8:231{274, 1987. [Hoa85] C. A. R. Hoare. Communicating Sequential Processes. Prentice-Hall, Englewood Cli s, NJ, 1985. [HSJ+ 94] T. Hartmann, G. Saake, R. Jungclaus, P. Hartel, and J. Kusch. Revised Version of the Modelling Language Troll (Version 2.0). Informatik-Bericht 94{03, Technische Universitat Braunschweig, 1994. [ISO84] ISO. Information Processing Systems, De nition of the Temporal ordering Speci cation Language LOTOS. REPORT N1987, ISO/TC97/16, 1984. [Jac92] I. Jacobson. Object-Oriented Software Engineering. Addison-Wesley, Reading, MA, 1992. [JSHS91] R. Jungclaus, G. Saake, T. Hartmann, and C. Sernadas. Object-Oriented Speci cation of Information Systems: The TROLL Language. InformatikBericht 91-04, TU Braunschweig, 1991. [Jun93] R. Jungclaus. Modeling of Dynamic Object Systems|A Logic-Based Approach. Advanced Studies in Computer Science. Vieweg Verlag, Braunschweig/Wiesbaden, 1993. [JWH+ 94] R. Jungclaus, R.J. Wieringa, P. Hartel, G. Saake, and T. Hartmann. Combining Troll with the Object Modeling Technique. In B. Wol nger, editor, Innovationen bei Rechen- und Kommunikationssystemen. GI-Fachgesprach FG 1: Integration von semi-formalen und formalen Methoden fur die Spezi kation von Software, pages 35{42. Springer, Informatik aktuell, 1994. [Mil89] R. Millner. Communication and Concurrency. Prentice-Hall, 1989. [RBP+91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. ObjectOriented Modeling and Design. Prentice-Hall, Englewood Cli s, NJ, 1991. [Rei85] W. Reisig. Petri-Nets. An Introduction. Springer-Verlag, Berlin, 1985.
[Saa93] [SE91]
[SJH93] [SSC92] [SSE87]
G. Saake. Objektorientierte Spezi kation von Informationssystemen. Teubner, Stuttgart/Leipzig, 1993. Habilitationsschrift. A. Sernadas and H.-D. Ehrich. What Is an Object, After All? In R. Meersman, W. Kent, and S. Khosla, editors, Object-Oriented Databases: Analysis, Design and Construction (Proc. 4th IFIP WG 2.6 Working Conference DS-4, Windermere (UK)), pages 39{70, Amsterdam, 1991. North-Holland. G. Saake, R. Jungclaus, and T. Hartmann. Application Modelling in Heterogeneous Environments using an Object Speci cation Language. Int. Journal of Intelligent and Cooperative Information Systems, 2(4):425{449, 1993. A. Sernadas, C. Sernadas, and J. F. Costa. Object Speci cation Logic. Research Report, INESC/DMIST, Lisbon, 1992. To appear in Journal of Logic and Computation. A. Sernadas, C. Sernadas, and H.-D. Ehrich. Object-Oriented Speci cation of Databases: An Algebraic Approach. In P.M. Stoecker and W. Kent, editors, Proc. 13th Int. Conf. on Very Large Databases VLDB'87, pages 107{116. VLDB Endowment Press, Saratoga (CA), 1987.
