OLSEN: An Object-Oriented Formalism for Information and Decision System Design Ramzi Guetari, Frédéric Piard 1 , Bettina Schweyer2 LLP/CESALP 41 Avenue de la Plaine BP. 806 - 74016 Annecy Cedex - FRANCE Tel : (+33) 50.66.60.80 - Fax : (+33) 50.66.60.20 email : guetari|piard|schweyer@esia.univ-savoie.fr 1 CIFRE contract with ANRT and Pôle Productique Rhône-Alpes 2 CIFRE contract with ANRT and ARM Conseil - an industrial information database, where products, 1.ּIntroduction resources, machines,… are described. The Object oriented model has spread widely within - Consumer-Supplier Information Systems (CSIS). A programming languages during the last years. The CSIS stands for an “atom” of organisation. It is a principles of this model have had a great influence on generalisation of the customer-supplier exchange analysis and design techniques. However no existing relationship to every couple of actors in the method is able to manage the whole analysis- enterprise (men, machines, software). Every CSIS specification-design-implementation cycle, preserving is associated to an objective, transforms resources the homogeneity of the model used in different stages and emits a satisfaction level. and the coherence by passing from one stage to the - an Objective Management System (OMS), whose following. role is to create a graph from expressed objectives, We think that the global management of the life cycle where every node is an objective associated to a cannot be solved, with the existing state of knowledge, CSIS. by one unique miraculous method, which could adapt - a Resource Management System (RMS), in charge to every kind of application. We think on the contrary of the product and resource management and that the problem should be treated by a panel of sharing. methods dedicated to a particular domain. - an activation system (AS), producing actions plans For this reason we have developed the OLYMPIOS to organise processes, taking into account the model at the LLP-CESALP laboratory. This model application, temporal constraints, and covers the life cycle of every application in the field of communications/synchronisation between CSIS. Information and Decision Systems for Manufacturing Firms. OLYMPIOS uses algebraic techniques, 3.ּThe IDS Life Cycle transformation rules and a predefined entity The OLYMPIOS model covers the different stages of organisation to propose an original approach for object the IDS life-cycle (Fig.ּ1). We use an algebraic oriented design of information and decision system. approach for the four facets of industrial information so as to obtain a coherent (i.e. sufficiently complete and 2.ּOLYMPIOS Model Concepts. consistent) specification. The design stage enables us to The information processed in an enterprise, which we design the information system from specification and call industrial information, is a complex datum. An by analysing the "existing" system of the enterprise and information and decision system (IDS) must take this its objectives. The result of this stage is a representation complexity into account. We propose to represent of the IDS using structured entities. The OLYMPIOS industrial information through four main facets : model introduces the uniformity of the model used from specification up to design. It uses tools proving - data, describing the different entities handled by the the coherence of the system in the specification step IDS and the actions that they can perform or can be and maintaining this coherence by automating the subjected to ; translation from one stage to another. - temporal properties of the different kinds of processes (including traceability of information) ; 3.1.ּAnalysis Stage - organisation, considered through information flows; In the analysis stage, the relevant information for the - economic facet, which describes the means of data, the temporal, the organisational and the economic performance evaluation in relation to enterprise facets is collected. environment and objectives. The result of the data facet analysis consists in the The OLYMPIOS model [Beauchêneּ93] [BHPּ93] description of the data handled (resources etc.) in the [BHSּ93] covers the different stages of such a system system to design and, for each datum, the set of life cycle and proposes original solutions for its operations that can be realised (data dictionary). This analysis, specification, design and realisation. static description can be translated into a finite state OLYMPIOS describes activities, taking into account automaton in which every node represents a state of the the assigned objectives and the resources availability. datum in question and every edge an operation which The basic modelling elements areּ: produces a new state. The analysis of the organisational aspects of the stage. This automatic construction is realised by the manufacturing firm results in a set of interactions algorithms [Nkongoּ90] developed in our laboratory. between the different agents of the enterprise in the form of exchange relationships. By interviewing each 3.2.2.ּOrganization Specification of these agents we enumerate, on the one hand, the It starts from the analysis of the "existing system", exchange relationships in which he is consumer, i.e. which results (inter alia) in the identification of actors follows a certain objective by asking for satisfaction of and their functions and objectives. Specifying the respective needs, and on the other hand, we identify organisation consists in formally expressing identified the relationships in which he is supplier and performs a objectives (in the "triple" form), and in constructing certain function. For each of these functions (which we their associated CSIS from standard parametrized would like to call basic operation) he enumerates the ASAT of organisation [Beauchêneּ93]. Simultaneously, resources necessary for realising this operation and the one must elaborate the different graphs of objectives. algorithm he follows to obtain the wanted resource. Thus, this interview gives us information about 3.2.3.ּTemporal Specification - objectives and their decomposition, The specification of the industrial information temporal - identification of the possible suppliers for the facet uses a synchronous process algebra, directly realisation of a given objective, derived from the SCCS calculus of R. Milner - the basic operations that can be performed and [Piardּ93]. We specify four kinds of processes with this knowledge about how to execute the operations and language : which resources are needed. 1- chronological and event-based clocks, essential to Starting from this information, we can establish a specify synchronisation and to measure temporal knowledge base of the different ways to decompose intervals; objectives and a knowledge base for the needed 2- behaviours of data facet entities, which are not resources for each basic operation. These knowledge completely determined by ASAT axioms; bases will help us, in addition to the predefined 3- behaviours of CSIS; structure of such an exchange relationship, to define the 4- activation plans, elaborated by the activation system enterprise organisation. from graphs of objectives and resources to schedule the CSIS. The analysis of the temporal facet provides a dynamic description of the system. It enables us to describe the Existing System Analysis temporal behaviour of different agents and resources of the system and their interactions. For this part of the Objectives Description ASAT Temporal analysis, a method close to natural language is being Base of Entities Analysis developed which will allow a user-friendly way of by automata Rules for describing temporal rules. Objectives Behaviours From this analysis we also obtain a description which management ASAT Generator we call realization programs. These programs contain the description of the CSIS functionning and of the Generator AS CSIS SCCS Description of operations which are not formally describable. Entities temporal generator Generated ASAT behaviour As far as the economic facet is concerned, we are actually working on an interview structure including OMS RMS Class fuzzy logic in order to acquire the information Generator necessary for evaluating the system's performance. 3.2.ּSpecification Stage Standard Classes 3.2.1.ּData Specification The data facet corresponds to the IDS functional and structural aspects, and aims at representing the OLSEN technical and technological data. We use Algebraic Resources Generator Specifications of Abstract data Types (ASAT) Affectation [Guttagּ78] [Jacquenetּ86] [Liskovּ87] so as to have CSIS OLSEN Realization efficient and simple proof techniques at our disposal. program Resources An ASAT enables us to express an entity behaviour in a CSIS A CSIS B CSIS C Closing Down high level formalism. For a given entity, an ASAT is a triple <Ω,Σ,A>, where Ω is a set of domains containing the domain of the entity values, Σ is a set of operations on the entity, and A is a set of equations (axioms and Users Application Data preconditions) on these operations, which determines Procedures Interfaces Programs Bases the entities behaviour and the relationships between them. ASAT are automatically constructed from the entities automata, which are the result of the analysis Fig. 1. The Analysis - Specification - Design Cycle in the OLYMPIOS Model The construction of left parts of axioms : 3.2.4.ּEconomic Specification The construction of axioms left parts consists of This facet cannot be specified independently of data building the following sets : and organisation. Indeed it is shared between them, and - CT = {c(y*), c @ C} the most important part is included in the organisation - OT = {o(x, y*), o @ O, x @ CT} facet. Works are still going on to sharpen the economic - ST = {s(x, y*), s @ S, x @ CT} view of OLYMPIOS on the information system (with OT and ST contain the left parts of specification the help of performance indicators, fuzzy logic and axioms. Axioms which define the semantic of the project-based management approach). abstract data type have their left parts in the OT set and axioms which shows the simplification of terms of 3.3.ּDesign Stage T(Ω,Σ) have their left parts in the ST set. The OLYMPIOS model, in its design stage, is based on the class model. This model was extended in order to The construction of right parts of axioms : allow to take all industrial information features into The graph of states, whose every node is a state of account, in particular real time ones. The result of the entities of TI type, and whose every transition is an design stage is an organisation of entities independent operation, providesּ: of possible target programming languagesּ: OLSEN (OLympios Structured ENtity). 1- Ω = {TI, STATES}, STATES = {E1,E2,E3,...} An OLSEN [Guetariּ94] is composed of a “class” part 2- Σ = {state, σ1, σ2, σ3, ..., σn} = O+C+S, T = S + C and another part called “scenario” which indicates the = {σ1, σ2, σ3, ..., σn} is the set of operations which interactions with its environment. The difference create or transform the values of TI (represented in between an OLSEN and a classical object is the the automata by transitions), O={state} contains a scenario which describes the temporal behaviour single observer. generally missing in the standard class model. The 3- Left parts of axioms by the building of AC,AO,AT OLSEN model is a “design object”. from O,C et T. In this paper, we present only the specification and 4- Right parts (y) of axioms in the form state(c(x*)) = design of Activation System (AS part) and Resource y, where c@ C, and y is the expression of the name Management System (RMS). The Objective of the node extremity of the path represented by Management System is the subject of a publication to c(x*) from the starting state. If there are many of come. these paths then the y term will be expressed in the form if...then...else ... 4.ּThe Transition from the Analysis to the 5- Right parts (y) of axioms in the form s(c(x*)) = y, where s @ S is a convertible operation and y Specification Stage corresponds to the canonical form of the state This stage consists in describing data types using finite extremity of the path c(x*), i.e. the expression of state automata. We must first insist on the fact that the shortest path between the starting state and the every entity cannot be described by an automaton. Only state extremity of the path represented by the if it has successive states and if it is concerned by expression c(x*). In other terms, these axioms are actions passing from one state to another can it be represented in the automata by simple circular described by an automaton. We do not use the automata paths. If there are many of these paths then the y as a specification tool but as a tool allowing us to shape term will be expressed in the form if...then...else ... the evolution of some kind of data type over a set of 6- Preconditions related to the state of arguments states. In this kind of automata, each transition (membership of TI) of each operation, which are represents an operation changing the entity's state and expressed by the restrictions on the domain of this each node represents one state of the entity. The operation before its execution. These restrictions automata may have many transitions corresponding to are issued from the state origin of the arc the same operation, however, each state is unique. A representing the operation. particular state called “starting state” must always exist. It corresponds to the extremity of the transition which stands for the operation creating the type of 5.ּThe Transition from the Specification to interestּ(TI). the Design Stage The entities described by automata are distinguishable The transition from the specification stage (ASAT and by the successive states that they can have. The order in SCCS) to the design stage is done automatically in two which different states are occupied is well defined. The steps. The first step consists in taking the ASAT one by graph of state changing is oriented and has a starting one and translating each one into a standard class. The state from which we can observe the evolution of the second step is a global one and permits the organization entity. This graph allows us to distinguish the of the communication between the obtained classes. constructor operations using a single method. The The benefit of this automation is the preservation of the transitions corresponding to these operations have coherence obtained in the specification stage. extremity nodes which can be reached from the starting state by only one path of the graph. The construction of 5.1.ּThe Standard Class Generation axioms is done in two stepsּ: the construction of left The class attributes and methods are generated from the é parts of axioms and the construction of right parts of ASAT operations. This is done using the following axioms, as it is shown belowּ: rules. We note an operation : σ : Ω 1 Ω2. Ω1 is the set of domains and Ω 2 is the set of codomains. “TI” is The OLSEN formalism helps us to generate data bases the data type that we specify. We distinguish three on the realization stage. The application programs are kinds of operations : obtained through the OLSEN, the realization programs and the CSIS organization. - Case 1 : σ : Ω 1 é Ω 2 / TI # Ω 1 and Ω 2 = {TI}. If we target object-oriented data bases in the realization This kind of operation corresponds to a particular stage, we have to use the OLSEN and the realization constructor. For each constructor, we generate a programs. In this case, each class part of an OLSEN is method “New” with parameters of type Ω1. directly translated into a data base object and the - Case 2 : σ : Ω1 é Ω2 / Ω1 = {TI} and Ω2 = {ω ≠ scenario part is used for the data access in the TI}. This kind of operation corresponds to application programs. The realization programs allow observers. The class structure is obtained from these us to implement the methods of the data base objects. observers. For each observer we generate an If the data bases are not object-oriented, only the attribute of type Ω2 and a method to access it. structure of the OLSEN interferes for the realization of - Case 3 : σ : Ω1 é Ω 2 / TI @ Ω 1 and TI @ Ω2. This these data bases. In a relational data base, for example, case corresponds to a general one. For each the OLSEN structure is used for the table creation. The operation of this kind we generate a method with in inheritance relationship is eliminated in these data parameters of type ω @ Ω1 / ω ≠ TI and out of bases and replaced by the result of merging the parameters of type ω @ Ω2 / ω ≠ TI. structures of a super-class and the sub-classes. The scenario of an OLSEN is issued from SCCS In the realization stage we can obtain three different formulae. An SCCS formula contains several types of CSIS translations: automatic CSIS where the deterministic parts. Each part provides one script in the actors perform totally automated processes, semi- OLSEN scenario. The scenario generation is done in automatic CSIS where one of the two actors performs three steps : the first two provide the declarative part of an automated task or the manual CSIS where both a scenario, the third one provides the dynamic part. For actors perform manual tasks. each OLSEN, we determine the determinist parts of the corresponding BEHAVIOUR (separated by a “sum” The first type of CSIS with the realization programs operator). For each part, we execute the following three and the scenarii allow us to obtain the application stepsּ: programs. These programs will act upon the data bases with the classical operations like add, modify and • Event Detection. This step permits the detection delete. These interactions with the data base are and declaration of the different kinds of events. The performed through message sending between the data type of each event is deduced from the SCCS base objects in the case of an object-oriented data base syntax. A communicational event appears in at least or through primitives which are the result of the two BEHAVIOURs, once preceded by the delay OLSEN behaviour in the case of non object-oriented operator δ, and once without this operator. An data bases. environmental event is identified by the existence The semi-automatic CSIS form the interactions of a clock emitting this event. An event is between a user and a process. These CSIS lead towards conditional if its complementary event appears at the implementation of user interfaces and external least once in a BEHAVIOUR. When all events are views which restrict the data base access according to declared, we proceed to the unification of the the user's rights. communicational events. This unification is based The manual CSIS finally, allow us to realize the manual on the observational equivalence [Austryּ84] and procedure for which the automation would be too consists of giving the same name to two expensive. synchronously successive events in a SCCS formula. 7.ּConclusion • Identification of the Set of Suppliers. For each The OLYMPIOS model provides the means to analyse communicational event, we define its receiving and specify coherently an industrial information and OLSENs whose BEHAVIOURs contain this event, decision system. It allows then to design the specified preceded by the delay operator δ. Any OLSEN IDS by preserving the coherence obtained in the responding to this event by applying one of its specification stage by using algebraic techniques. The methods must be added to the suppliers list of the continuity and uniformity claimed by the Olympios treated OLSEN. model is the result of two factorsּ: • Script Generation. A script is generated for each - the use of algebraic tools to specify all the compo- determinist part. Each event described in the formula is replaced by one or several simultaneous nents of an IDS like the data facet, the organization dispatches of messages. The receivers of these facet or the temporal facet, messages are the suppliers defined in step 2. - the use of ASAT to specify data and Objects to design them. 6.ּThe Transition from the Design to the This care of continuity and uniformity has lead us to Realization Stage develop algorithms (and parts of a future CASE-Tool) This transition is based on the realization programs to automatically generate a coherent OLSEN which we have obtained in the analysis stage. organisation from the analysis. Our objective is to generate a maximum of code for applications. References [Austryּ84] AUSTRY D., BOUDOL G., Algèbres de processus et synchronisation, TCS 30(1) 1984 [Beauchêne 93] D. Beauchêne. L'information industrielle : définition et spécification. PhD thesis, University of Savoie. December 1993. [BHP 93] D.Beauchêne, A.Haurat, F.Piard. Une méthode de spécification de l'information industrielle par types abstraits algébriques. Proceedings of ICO'93, 4-7 May 1993, Montreal Canada. [BHS 93] D.Beauchêne, A.Haurat, B.Schweyer. Designing an information system for a manufacturing enterprise under the aspect of a CIM approach : the model OLYMPIOS. Proceedings of APMS'93, 28-30 September. 1993, Athens Greece. [Guetari 94] R. Guetari. and F. Piard. From the Specification to the Design of an Industrial Information System: the Olympios Model. Accepted in the 1994 IEEE Conference on Systems Man and Cybernetics. San Antonio - Texas October 2 - 5 1994. [Guttag 78] J.V. Guttag and J.J. Horning. The algebraic specification of Abstract Data Type. Acta Informatica. 1978 Vol 10. P 27-52. [Jacquenet 86] J.P. Jacquenet, P.Lescanne. La réécriture. Techniques et Sciences Informatiques 1986. Vol 5 N° 6. p. 433-452. [Liskov 87] B. Liskov. Data Abstraction and hierarchy. OOPSLA'87 Addendum to the proceedings. 1987. [Nkongo 90] T. Nkongo. Spécification algébrique de types abstraits pour le modèle Olympios. DEA report Ingénierie Informatique of INSA Lyon. September 1990. [Piard 93] F. Piard, C. Braesch - Application du calcul SCCS de Milner à la spécification de processus informationnels par types abstraits algébriques dans une entreprise manufacturière. Real Time Systems Conference, Paris 1993.