Object-oriented modelling and specification using SHE

Computer Languages 27 (2001) 19–38 www.elsevier.com/locate/complang

Object-oriented modelling and speci$cation using SHE M.C.W. Geilen ∗ , J.P.M. Voeten, P.H.A. van der Putten, L.J. van Bokhoven, M.P.J. Stevens

Section of Information and Communication Systems, Faculty of Electrical Engineering, Eindhoven University of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands Accepted 27 April 2001

Abstract Industry is facing a crisis in the design of complex hardware=software systems. Due to the increasing complexity, the gap between the generation of a product idea and the realisation of a working system is expanding rapidly. To manage complexity and to shorten design cycles, industry is forced to look at system-level languages towards speci$cation and design. The (formal) system-level modelling language called POOSL is very expressive and is able to model dynamic hard real-time behaviour and to (visually) capture static (architecture and topology) structure in an object-oriented fashion. The language integrates a process part, based on the process algebra CCS, with a data part, based on the concepts of traditional object-oriented programming languages and it is equipped with a formal semantics. Currently, a number of automated software tools (model editing, simulator and compiler tools) are available in an environment called SHESim. These tools allow visual entry of structure and topology of the system, whereas dynamic behaviour of individual processes is expressed in an expressive imperative language. The formal semantics of POOSL provides a solid basis for the application of veri$cation and performance analysis techniques and establishing a rigorous connection to c 2001 Elsevier Science Ltd. All rights reserved. existing analysis tools.
Keywords: Object-orientation; Hardware=software systems; System-level languages; Modelling and speci$cation

1. Introduction Industry struggles with mastering the development process of complex hardware=software systems. Examples of these systems are data=telecommunication systems, multimedia systems, medical ∗

Corresponding author. Tel.: +31-40-247-4741; fax: +31-40-243-3066. E-mail address: [email protected] (M.C.W. Geilen). c 2001 Elsevier Science Ltd. All rights reserved. 0096-0551/01/$ - see front matter  PII: S 0 0 9 6 - 0 5 5 1 ( 0 1 ) 0 0 0 1 4 - 5

20

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

systems, industrial control systems and consumer electronics. Hardware=software systems are typically implemented using several types of hardware components and complex application software running on real-time operating systems. These systems perform very complex behaviour and have to satisfy architectural constraints that impose physical distribution and hardware=software partitioning. Currently, industry is facing a crisis in the design of these complex systems [1]. Due to their combination of requirements, modern hardware=software systems are inherently complex to design, implement, verify, validate, test and debug. Today’s systems integrate more and more functionality that has to satisfy stringent requirements of quality, Eexibility, reliability and reusability. Deciding on an appropriate implementation has become increasingly diFcult due to the diversity of available technology components (microprocessors, digital signal processors, application speci$c instruction processors, application speci$c integrated circuits, $eld programmable gate arrays, real-time operating systems, etc.). Industry is struggling with tight bounds on time-to-market, -quality and -volume, high innovation speed and high costs for failure. Existing speci$cation and design approaches are no longer keeping pace with the growth of system complexity. For hardware, traditional design approaches are well established for the lower levels (transistor, logic, register and algorithmic level) of the design trajectory. However, as systems become more complex, the descriptions on these abstraction levels grow so huge that they become incomprehensible for designers and unmanageable for design tools [1,2]. For the development of software, methods supporting the higher levels of the design trajectory are available. These methods, however, are often unsuitable for system design, and they do not help in making design decisions regarding architecture structure, hardware=software partitioning and the technology components to be applied. Due to the increasing system complexity, the gap between the generation of a product idea and the realisation of a working system is expanding rapidly. To manage complexity and to shorten design cycles, industry is forced to look at system-level approaches towards speci$cation and design [1,2]. System-level speci$cation and design methods allow the creation of formal, executable models describing a system in the earliest stages of the design process. These models are expressed in powerful languages such that complex systems can be described with relatively few language constructs. System-level models allow the properties of a system to be analysed, simulated, validated and veri$ed before the system is actually being realised in terms of hardware and software components [2]. In this way, design errors can be detected in a very early phase, thereby preventing expensive and time-consuming design iterations. The models further allow the systematic and rapid evaluation of diHerent hardware=software architectures on a high level of abstraction, without having to spend a lot of time on creating low-level implementations. This is an important advantage since it is at the higher levels of abstractions where the largest gains in designing ‘optimal’ hardware=software systems can be obtained [2]. In this paper, we discuss the methodology SHE and particularly, the formal modelling and speci$cation language parallel object-oriented speci$cation language (POOSL) that is used at the heart of the methodology as well as the graphical environment with its supporting tools. In Section 2, we will discuss system-level modelling and language requirements to support it. Section 3 introduces the system-level modelling language POOSL, explains its basic concepts and formal semantics and compares POOSL to other high-level description language such as SDL, Estelle, LOTOS and ROOM. In Section 4, we will describe how the language can be used to model a switching network for ATM network traFc. The graphical tools that support the construction and analysis of POOSL models are

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

21

the topic of Section 5, and $nally in Section 6, we present our conclusions and directions for future research. 2. System-level modelling In the early phases of design, where a system is being analysed and speci$ed and where the system-level architecture is being decided upon, there is a need for expressive formal languages that allow one to describe the system at a high level of abstraction. Such languages are often called system-level languages. In this phase, design decisions have a very large impact on the quality of the $nal design. These languages should help to bridge the gap between requirements capture and synthesis. Therefore, they should be intuitive, applicable within multidisciplinary design, and easy to understand. For this reason, a system-level language should have an imperative nature, should be simple and built on a small collection of blending language primitives [3] and it should be supported by easy-to-use graphical tools. During the architecture exploration phase, the implementation technologies to be applied are decided upon. To make architecture exploration feasible, a system-level speci$cation should not be biased towards a particular choice of implementation and should be described in a language that abstracts from technology. To help designers bridge the gap between requirements capture and synthesis, adequate tool support is indispensable. Tools are required to edit, validate, verify, simulate and transform speci$cations, but are also needed for parameter estimation, automatic test-suite generation and system-level synthesis to compile speci$cations to technology-speci$c languages such as VHDL and C. To support the development of such tools, a system-level language should be equipped with a formal mathematical semantics [3]. 2.1. Language requirements From the characteristics of complex hardware=software systems, a number of other language requirements can be deduced. The communication and functional behaviour of a hardware=software system is often so complicated that it is quite impossible to understand it or to model it in its entirety. Therefore, behaviour should be distributed over modules whose behaviour can be understood without having to understand the environment they are placed in. This requires modules to be self-contained, autonomous, relatively independent, and weakly coupled entities. We will call these entities process objects, or processes for short. Processes exist in their own right, have their own responsibilities, and they have their own activities to perform. A very important characteristic of hardware=software systems is structure. Physical or spatial distribution, physical topology, hardware=software partitioning and software layering are all examples of phenomena that impose structure. The modelling of topology requires processes to be structured in a network of channels. The other forms of structure require the possibility to group processes into higher-order entities called clusters. A cluster acts as a hierarchical abstraction of its internals. Hierarchy is an important concept that helps to manage complexity. Processes (and clusters) are relatively independent and they can perform their activities concurrently and at their own speed. Despite their autonomy, processes will frequently have to exchange information. To make the coupling between processes (and clusters) as weak as possible, information exchange should be based upon message passing. The essential feature of message passing is

22

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

that information is exchanged by means of an intermediate artefact called a message. The purpose of a message is to reduce the coupling between the message senders and the message receivers [4]. To exchange information, the sender and the receiver only have to share the format and the general semantics of a message. They do not have to know anything about each other’s internals, i.e. about private data. The internals of a process are said to be encapsulated by a strong encapsulation boundary. The only way for other processes to access these internals is through a clear-cut message interface. A process can exhibit very complex behaviour. It can perform several activities in parallel and is able to exchange messages in various ways (synchronous, asynchronous, interrupt-driven). Behaviour can depend on (hard) real-time concepts such as time-outs, watchdogs and deadlines. It must be possible to express all these forms of behaviour in a system-level modelling language. Processes in hardware=software systems are able to perform complex manipulations on their private data. Since private data can have complex structures of their own, they should be represented by objects too. We will call these objects data objects. Data objects can be exchanged as parameters of messages between processes. Distinct processes cannot share any data objects. 2.2. Models, abstraction and adequacy Early in the design trajectory, global design decisions have to be made in order to achieve a satisfying realisation. Such decisions are based upon the (expected) values of certain properties of the design realisation such as cost, performance, etc. Realising the individual alternatives in order to determine those property values would be time-consuming and costly. Models are often used to determine those property values, since models can be made cheaply and quickly. One can view a property as a function on designs, realisations or models. If the range is boolean the property is called qualitative (e.g. absence of deadlock), otherwise it is called quantitative (e.g. throughput). A model is an abstract representation of some design realisation. It will usually represent the behaviour of the actual realisation not entirely faithfully. A model can be made more adequate by modelling the realisation in more and more detail. This is, however, time-consuming and hampers the (automatic) analysis of the model. Model checking for example, suHers from the state-space explosion and an increase in the model’s detail might lead to an exponential increase in the time needed for veri$cation, up to the point where a conclusive veri$cation is no longer feasible. Therefore, models should be adequate for the properties that are relevant for making a design decision and at the same time be as abstract and simple as possible. 2.3. Example, a switching fabric As an example that will be used throughout this paper, we will discuss a switching fabric as depicted in Fig. 1. It is a network of elementary switches that route data traFc from their inputs to the correct outputs. The elements of information that are sent through the network are called packets or cells and are passed from one switching element to another and can be temporally stored in internal buHers. Issues that play a role when designing such networks are for example queue sizes, priorities, scheduling policy and backpressure (the ability to slow down incoming traFc). The relevant realisation properties include issues like throughput (the amount of traFc the network can

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

23

Fig. 1. A switching fabric.

process), average delay of a packet moving through the network, jitter (the variation in this delay) and quality of service. Models of the network can be used to predict such performance properties for possible implementations, during the initial phases of the design. 3. The POOSL language 3.1. The SHE methodology In [3,5], we introduced the methodology software=hardware engineering (SHE). SHE is a framework for object-oriented speci$cation and design of hardware=software systems. The framework incorporates activities found in many modern object-oriented methods, such as UML or ROOM. Such activities include object class diagrams and interaction diagrams (message sequence charts), see Fig. 2. Starting from such informal and often graphical models, SHE produces rigorous behaviour and architecture models expressed in the formal speci$cation language POOSL [3,6]. The POOSL language has speci$cally been developed to be used as a system-level modelling language. Once POOSL models have been constructed they can be executed and interesting design properties can be determined. The fact that the execution of POOSL models is de$ned by a formal semantics, allows one to create tools to validate and verify the design and estimate performance $gures from such models early in the design trajectory. 3.2. Basic concepts of POOSL The POOSL language combines a process part with a data part. The process part is based on the key ideas of the process algebra CCS [7]. The data part is based upon the concepts of traditional sequential object-oriented programming languages such as Smalltalk and C++. 3.2.1. Process objects In POOSL complex, hard real-time behaviour is represented by a collection of asynchronous concurrent process objects that communicate synchronously by passing messages over static channels. Behaviour of process objects is described by process statements. There is a small collection of very

24

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

Fig. 2. SHE methodology framework.

powerful and entirely compositional statements: • Synchronous (possibly conditional) message (and data object) passing primitives: The statement ch?m(p1 ; : : : ; pn |E) denotes the synchronous reception of a message m on port ch, having n data objects as parameters that are bound upon reception to the variables p1 through pn . The synchronisation will only take place if the expression E (which may depend on the received parameters) evaluates to true. The statement may be followed by a data statement between braces. This data statement will be executed immediately after the message is received. ch!m(E1 ; : : : ; En ) is the corresponding statement used to send a message m on channel ch with as parameters the objects that are the result of evaluating the expressions E1 to En . The send statement may also be followed by an atomic data statement. • Loops (while E do S od), conditional statements (if E then S1 else S2 fi) and sequential composition (S1 ; S2 ) having the usual semantics. • The selection primitive sel S1 or S2 or : : : Sn les executes one of its composite statements, making the decision as soon as one of the composite statements executes an action. • Guarded commands: The statement [E]S is ready to execute whenever S is ready to execute and the guarding expression E evaluates to true. • Parallel composition: The statement par S1 and S2 and : : :and Sn rap denotes the parallel (interleaved) execution of the composite statements. The statement terminates when all composite statements have terminated. • Procedure (method) abstraction and (tail) recursion in the form of method calls using the statement m(E1 ; : : : ; En )(p1 ; : : : ; pm ), which calls the method m passing the expressions E1 to En and receiving results after execution in the variables p1 to pm . If the method call is the last statement of a

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

25

method body, the call is made in a tail-recursive fashion, thus allowing the simple modelling of in$nite behaviour. • Interrupt and abort primitives: The interrupt statement S1 interrupt S2 is a very powerful statement which executes S1 , allowing the execution to be suspended by the execution of S2 . When S2 terminates, the execution of S1 is resumed (and can be interrupted by S2 again). The abort statement S1 abort S2 behaves similarly, but it aborts the execution of S1 , instead of suspending it. • Delay primitive: The statement delay E lets the process delay for E units of time. This is the only statement which expresses quantitative timing information. This is suFcient because it can be combined with other statements such as interrupt or abort to create more complex quantitative timing behaviour such as time-outs or watchdogs. • Data statements: Furthermore, there exist a number of data statements such as assignments to variables (x:=E) and method calls on data objects (Em(E1 ; : : : ; En )). A sequence of data statements can be put between braces to ensure that they are executed atomically in a single step. • The skip statement: Skip performs an action without any eHect, this is useful in combination with other statements. One can use it, for example, to model internal non-deterministic choice using: sel skip; S1 or skip; S2 les. An example of process behaviour is given in the following process method. startUp()() outputBufferArray:=new(Array) size(2); outputBufferArray put(1,new(BoundedFIFOBuffer) size(bufferSize)); outputBufferArray put(2,new(BoundedFIFOBuffer) size(bufferSize)); par handleInput1()(); and handleInput2()(); and handleOutput1()(); and handleOutput2()(); rap. The method is called startUp and has no parameters. The $rst statement creates a new data object of class Array, sets the size of the array to 2 by calling the object’s size method. The resulting array is bound to the variable called outputBufferArray by the assignment. In the second and third statements, a new data object of class BoundedFIFOBuffer is created, its method called size is executed and the resulting object is stored in the previously created array by calling the put method of the array. Then the par: : :and: : :rap statement is executed. It executes four method-call statements concurrently. handleInput1()(), handleInput2()(), handleOutput1()() and handleOutput2()() are the names of corresponding methods. These methods are executed when the method-call statements are invoked. The methods handleInput1()() and handleInput2()() deal with the reception of cells and methods handleOutput1()() and handleOutput2()() handle the forwarding of cells. The method de$nitions will be elaborated in Section 4. In the example, the method calls represent in$nite behaviour and consequently, the statement will never terminate. 3.2.2. Clusters Next to processes, POOSL supports the concept of cluster. A cluster is composed of processes and other clusters and acts as an abstraction of these. Clusters are used to create a hierarchical

26

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

Fig. 3. The cluster class MultistageSwitch.

structure of modules that hide their internal structure. The constituents of a cluster are composed by parallel composition, channel hiding and channel renaming. These combinators are based upon similar combinators originally used in CCS [7]. Together, clusters and channels are suitable for describing architecture structure, topology and implementation boundaries [3]. In Fig. 3, we see a cluster class named MultistageSwitch de$ning clusters that act to their environment as a switch of four inputs and four outputs. Their internals are hidden from the environment and consist of a network of four smaller switches having only two inputs and two outputs. 3.2.3. Data objects To describe complex functional behaviour, POOSL supports data objects. Data objects have sequential behaviour and communicate by synchronous message passing. They are contained in processes and they model the private data of these processes. Data objects are also called travelling objects, since they can be passed between processes. The following example shows a method of data class BoundedFIFOBuffer: firstElement(): Object if fifoDepth= 0 then return nil else return lastLink element fi. From the $rst line, we see that the method is called firstElement and returns a reference to an object of class Object or one of its subclasses. The body of the method is easy to read and consists of an if statement returning nil (referring to no object) if the value of instance variable fifoDepth is zero. If it is not, it will return the result of evaluating the expression lastLink element (calling the method element of the object to which the variable lastLink refers).

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

27

Fig. 4. Two-phase execution model (from [8]).

3.3. Formal semantics The POOSL language is equipped with a complete mathematical semantics. The semantics is based on a two phase execution model [8]. The state of a system can either change by asynchronously executing atomic (communication or data processing) actions (taking no time) or by letting time pass (synchronously) inactively, see Fig. 4. The semantics of a POOSL speci$cation is given by a Plotkin-style structural operational semantics, de$ning a labelled transition system:
    a t Mod; Act; T; → | a ∈ Act ; → | t ∈ T consisting of a set of ‘models’ (POOSL speci$cation during execution), a set of actions Act, a time a domain T and two sets of labelled transition relations. M →M
holds if model M can perform the t action a and after that it will behave as model M
. M →M
holds if model M can delay for t units of time and after that it will behave as model M
. The semantics of the non-real-time part of POOSL is given in [3]. The formalisation of the real-time extension is described in [6,9]. The labelled transition relations are de$ned by sets of axioms and rules, de$ning the behaviour of all primitive statements in a fully compositional way. The following are a few examples of rules that de$ne the semantics of POOSL. The actual rules are more involved, because they also involve data (among other things). The semantics of the delay statement is given by the axiom and rule t

√

delay t →

0 ¡ t
¡ t t


delay t → delay t − t


:

The√$rst axiom states that delay t can wait for t units of time after which it terminates (indicated by ). The second rule states that the delay statement can also wait for less than t units of time and after that it still has to wait for the remaining time. Rules for the parallel composition () operator are 

M1 →M1


M1 M2 →M1
M2

ch!m

ch?m

M1 → M1
; M2 → M2


M1 M2 →M1
M2


t

t

M1 →M1
; M2 →M2
t

M1 M2 →M1
M2


:

The $rst rule says that concurrent components perform their actions () independently and interleaved (the  operator is symmetrical). The second rule states that if components can perform

28

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

Fig. 5. The labelled transition system of transferCells.

complementary actions, they can communicate (synchronously) and the last rule speci$es that time elapses synchronously in concurrent components. As a $nal example, these are the rules for the choice operator (+). 

t

t

M1 →M1


M1 →M1
; M2 →M2


M1 + M2 →M1


M1 + M2 →M1
+ M2




t

:

The $rst states that a choice is made between the components as soon as one of them is ready to perform an action . The second rule states that time may pass if both components allow it and in the meanwhile, no choice is made. The semantics of the following piece of POOSL behaviour transferCells()() |c: Cell| in?cell(c); delay(100); sel skip; out!cell(c) or skip les; transferCells()(). is the labelled transition system represented in Fig. 5, where the state with the double line indicates the initial state. A transition labelled with  indicates an internal action for which no external synchronisation is necessary. 3.4. Comparison to other languages The key feature of POOSL is the expressive power to model very complex hard real-time (communication and functional) behaviour as well as static (architecture and topology) structure in an object-oriented fashion. POOSL can best be compared with the formal description languages LOTOS, SDL and Estelle [10] and the modelling language ROOM [4]. These languages all have a well-de$ned semantics 1 and are relatively simple. 2 They are further based on autonomous, 1

The semantics of LOTOS and SDL are de$ned in a formal mathematical way. As far as we have been able to verify, this is not true for Estelle and ROOM. 2 This especially holds for Estelle. The other languages are a lot more complicated.

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

29

encapsulated asynchronous concurrent entities that are connected in a static topology of channels and communicate using well-de$ned interaction primitives. 3 However, there are many concepts in which these languages diHer from POOSL. Some important diHerences are: Communication: Communication in SDL, Estelle and ROOM, is buHered asynchronously. 4 BuHered asynchronous message passing is certainly a useful concept and should be supported, but it is not suFcient for hardware=software systems. We have experienced that especially at higher levels of abstraction, the concept of synchronous communication 5 is indispensable. It should be noted that asynchronous interaction can easily be expressed in terms of synchronous interaction. This is not true in the other direction. Synchronous interaction is incorporated in the LOTOS language. Although, it is based on undirected (multi-way) action synchronisation, and not message passing, it can be used to express directed message passing too [11], be it in a less natural way. Interrupts and aborts: Interrupts and aborts are very important for describing complex behaviour. In case of an interrupt, the current course of behaviour is temporarily suspended until the interrupting behaviour has terminated. In case of an abort, the current course of behaviour is terminated and the aborting behaviour is started. The LOTOS language only supports aborts. In ROOM behaviour, it can both be aborted as well as interrupted. SDL and Estelle do not have interrupt or abort facilities. Data objects: For describing intricate dynamic data structures, the concept of data object is indispensable. Except for ROOM, none of the languages support data objects. LOTOS and SDL use abstract data types and Estelle uses Pascal types to model data. Abstract data types are attractive from a mathematical point of view, but they have appeared to be diFcult to understand [12] and they are hard to simulate and implement eFciently. Pascal is a procedural language and has insuFcient support for encapsulation and data modularisation. Concurrency and sharing: The combination of concurrency and shared data is often considered dangerous since it introduces a lot of non-determinism in models and can lead to synchronisation and mutual exclusion problems. We agree with this, but we think a restricted combination of concurrency and sharing is necessary to model real-life systems. Therefore, POOSL has a par-statement that allows concurrency inside processes. The restriction lies in the fact that operations on data objects are atomic and hence, concurrency in processes is de$ned at a rather coarse grain. In this way, mutual exclusion and synchronisation problems can be solved very naturally, without forbidding activities to operate on shared data entirely. The grain of concurrency in ROOM, SDL, Estelle and LOTOS is at the level of process objects. 6 These processes cannot share data and therefore it is not possible to model activities that operate on a piece of shared data concurrently. Real-time: None of the above languages have suFcient support to model (hard) real-time behaviour. The LOTOS language does not have any facilities to express time at all. 7 Estelle supports a restricted timing mechanism in the form of time delays. However, the Estelle semantics restricts the interpretation of time in the weakest possible way, placing only those requirements that derive from 3

LOTOS supports concurrent processes. Processes in LOTOS are pieces of behaviour, but they are not objects that perform this behaviour. Nevertheless, objects can be modelled by processes [11]. 4 A sender can always send a message without knowing the readiness of the receiver. In general, messages are buHered until they are consumed by the receiver, but under some circumstances they can also be discarded. 5 A sender may only send a message if the receiver is ready and willing to receive it. 6 In ROOM these objects are called actors, in SDL process instances and in Estelle they are called modules. 7 Although many proposals have been written to extend LOTOS with a notion of time.

30

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

assuming that time moves forward consistently for all modules in the same subsystem [10]. SDL has a built-in real-time mechanism, relying on an asynchronous timer mechanism that is able to access a global clock referring to the current moment in time. However, the delay between the moment of timer expiration and the moment at which the SDL model reacts to this expiry is unbounded. Therefore, SDL is not suitable for expressing hard-real-time behaviour [13]. In fact, the concept of time is not an inherent property of a model in SDL but of the possibly underlying execution engine or operating system. The same holds for the ROOM language.

4. Example In [14], we have shown the suitability of the SHE method and POOSL language for the speci?cation and design of an industrial distributed control system. In this section, we will demonstrate how the POOSL language can be used to model the switching fabric. In Fig. 6 the top level of the hierarchy of the model is shown. The box labelled with X is a cluster that models the entire switching network. Next to the network, there are a number of processes that model the environment in which the network should operate. There are processes labelled SourceN that will create packets according to some stochastic process and oHer them to the network. There are also a number of processes DestinationN that accept the packets coming out of the switching network. The behaviour of the sources and destinations in the model is extended with some functionality to collect statistical information about the cells that move through the network and the time they have spent in the network.

Fig. 6. POOSL model of switching network.

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

31

The cluster X is a cluster of class MultistageSwitch. The de$nition of this cluster class is shown in Fig. 3. The cluster is built from four smaller switches each having only two inputs and outputs. These smaller switches are processes of the same process class, namely Switch. The method discussed in Section 3.2.1 is the initial behaviour of these processes. It created a number of buHers and subsequently started four methods concurrently. Two of which will inde$nitely continue to handle one input port each and two of which handle an output port. We will now take a look at these methods, since they give an impression of the expressiveness of the language. The $rst is the method handleInput1. handleInput1()() | cell: Cell | i1?cell(cell | outputBufferArray at(cell destinationPort) isNotFull) {outputBufferArray at(cell destinationPort) put(cell); cell nextDestinationPort}; delay(cellTime); handleInput1()(). The method has a local variable that is called cell and is of type Cell. The $rst statement is a message receive statement. It waits for a message named cell on port i1 having one parameter which is bound to the variable cell. The synchronisation only takes place, however, if the condition outputBufferArray at(cell destinationPort) isNotFull is true. This is a data expression that checks that the outputbuHer in which the cell that would have been received needs to go is not yet full. Note that since communication is synchronous, the cell will remain blocked in the process that wants to send the cell until there is room in the output buHer. This is a powerful way to model a form of backpressure and it illustrates the claim made in the previous section, that synchronous communication is often very useful at a higher level of abstraction. After the message is received, the following statement (enclosed by braces) is executed atomically together with the receive statement. It stores the cell in the proper output buHer. This is done atomically, since there is a second handler for the second input port and we do not want the buHer to be $lled in between the reception of the cell and storing it in the buHer. Since we can do this atomically, we can let both input handlers concurrently access the shared buHer. After this has been done, a delay is performed to model the fact that the operations performed on the incoming cell take some time in reality (in POOSL actions do not take any time). After this the method tail-recursively calls itself and is thus ready to accept the next cell. The following method called handleOutput1 shows how the outputs of the switch are modelled: handleOutput1()() [outputBufferArray at(1) isNotEmpty] o1!cell(outputBufferArray at(1) firstElement) {outputBufferArray at(1) removeFirstElement}; delay(cellTime); handleOutput1()(). The $rst statement is a guarded message send statement. The process tries to send a message cell on port o1 with a parameter the $rst element of the output buHer of output one. This statement is

32

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

guarded by the expression outputBufferArray at(1) isNotEmpty. A message can thus only be sent whenever the output buHer actually contains a cell. After the message has been sent, the cell is (atomically) removed from the output buHer. After this the process delays to model the processing time and subsequently calls handleOutput1 again. 5. Tool support In order to be able to eHectively use a design methodology and modelling language, it should be supported by easy-to-use and preferably graphical tools. Such tools should at least be able to execute the models that are made and allow the designer to ‘play’ with them and analyse, verify or validate them. 5.1. Interactive modelling and simulation in the SHESim tool The drawings we used in the previous sections are snapshots taken from an interactive model editing and simulation tool for the SHE method, which is called SHESim. The tool is used to incrementally specify and modify classes of data, processes and clusters in a graphical way. A speci$cation does not have to be complete before it can be tested and simulated. Using the various buttons at the bottom of the simulation window of Fig. 7, the current (partial) model can be executed in diHerent modes of simulation. The messages and parameters that are passed between the diHerent processes and clusters are indicated on the appropriate channels. It is possible to open inspectors on each part of the model (data objects, process objects and clusters).

Fig. 7. Simulation of the POOSL model.

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

33

Fig. 8. Inspector on a process object.

The inspectors show the current state of each variable; for processes they show the statements that are about to be executed as well (Fig. 8). To inspect the history of all messages exchanged between the diHerent entities, interaction diagrams (sometimes called message sequence charts) can be generated automatically. An example of an interaction diagram is shown in Fig. 9. The diagram shows the diHerent model entities and the messages exchanged between these entities. For each message, the time, the channel and the parameters are indicated. For instance on time 20.0, message cell with parameter Cell is exchanged between Source1 and the network X on channel i1. By default the class name is used to represent the object, but classes can also rede$ne the way they are displayed to be more informative. Notice that not every instance of message exchange is shown in Fig. 9. The communications inside the switching network X are hidden and it cannot be observed which entity inside X actually received the message. They can be made visible, however, by either exploding or entering the network X, see Fig. 9. This way one can traverse the hierarchy of the system, displaying everything or hiding communications either inside or outside of clusters. Another way to handle the complexity of behaviour is through the concept of scenario [3,15]. A scenario de$nes a coherent piece of behaviour in terms of the entities (processes, clusters and channels) that are involved in this behaviour. The interaction diagram in Fig. 10 visualises the behaviour corresponding to the S1D1 scenario only. This scenario involves the network X, Source1 and Destination1 as well as channels i1 and o1. The other entities that are not involved, are now invisible. This allows a designer to focus on speci$c aspects of the model, for example when discussing the model with specialists that are interested in these aspects in particular and should not be confused with other details that are unimportant to them.

34

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

Fig. 9. Interaction diagram.

5.2. Other analysis methods and tools Using the kind of model described, one is able to try out diHerent design alternatives such as scheduling and buHering strategies and estimate the performance of the network. The semantics of POOSL currently supports only non-deterministic and not probabilistic choice. Performance analysis is possible however, by using data objects to model (pseudo) random generators and the probabilistic interpretation given to the model by the simulation scheduler. In order to get a more solid basis to reason about performance and analysing it, current research concerns an extension of the semantics with probabilistic choice. This way POOSL models can be interpreted as Markov chains and well-known analysis methods can be applied [16,17]. Provided that the models are not too large, it is then possible to compute performance measures analytically. If the models are too large, performance measures can be estimated by using statistical methods on simulations of the model. The same is true when investigating qualitative properties. By using a formal veri$cation tool for CCS, we have been able to verify the correctness of an abstract CCS version of the positive acknowledgement with retransmission protocol, but even for this protocol we had to make severe abstractions (with respect to real-time and unbounded sequence numbers of packets) to make formal veri$cation feasible. The truth is that the general problem of exhaustive formal veri$cation is in many cases either theoretically or practically unsolvable. Often models will be too large and exhaustive

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

35

Fig. 10. Using scenarios.

veri$cation will be infeasible. In this case, an alternative could be ‘empirical veri$cation’. One can automatically verify a trace generated by a simulation run against certain formalised desired or undesired properties. Invariants and assertions can be checked for example, but also (certain) linear time temporal logic formulas can be checked by constructing ‘observers’ that run along with the model and detect violations of the property [18–20]. We are currently investigating methods to perform automatic, non-exhaustive veri$cation of (real-time) properties on full models [21,22]. Research is also being carried out into system-level synthesis of POOSL speci$cations [23]. A tool has been developed to compile POOSL speci$cations into C++. After a POOSL model has been de$ned in the interactive environment, the automatically generated C++ program can be used for faster simulation, performance analysis or veri$cation purposes. In some cases, it can even be used as a $nal implementation. The $rst results into the mapping of POOSL onto hardware are presented in [24]. Further, a system of behaviour-preserving transformations has been developed [3,25]. Behaviour-preserving transformations are transformation rules that are proven to preserve the behaviour of the system. These rules thus allow the architecture of POOSL models to be modi$ed, without changing their functional and communication behaviour. 6. Conclusions and future research In this paper, we have described the SHE methodology and in particular, the system-level modelling language POOSL and its supporting tools. POOSL is a language with a complete mathematical semantics and is developed as part of the SHE method for hardware=software systems. The language combines a process part based on CCS, with a data part based on the concepts of traditional

36

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

object-oriented programming languages. Very complex hard real-time behaviour is represented by a collection of asynchronous concurrent process objects that communicate synchronously by passing messages (with data objects) over static channels. Behaviour of process objects is described by synchronous message passing primitives, choice, loop and select primitives, guarded commands, parallel and sequential composition, method abstraction, (tail) recursion and interrupt, abort and delay primitives. To describe intricate data structures, POOSL supports data objects. Data objects are contained in processes and they model the private data of these processes. A restricted form of concurrency on shared data within a process is allowed. Architecture structure and topology of systems can be represented graphically by clusters and channels. A cluster is composed of processes and other clusters and acts as an abstraction of these. The combination of supported concepts makes POOSL a powerful system-level language that has important advantages over other modelling languages such as SDL, Estelle, LOTOS and ROOM. A number of supporting software tools have been developed. An available interactive simulator tool allows POOSL models to be entered, simulated and validated in a graphical environment. Model validation is supported by inspectors, interaction diagrams and scenarios. Interaction diagrams also support manual performance evaluation of models. By making abstractions into process algebra CCS, a limited form of formal veri$cation can be carried out. Important current research topics involve the automatic non-exhaustive veri$cation of (hard real-time) properties, statistical estimation of performance parameters and system-level hardware and software synthesis. In order to obtain a sound basis for the latter, the semantics of POOSL is being extended with probabilistic choice [16] and the connection to Markov chains and Markov reward structures is investigated. 7. Summary Industry is facing a crisis in the design of complex hardware=software systems. Due to the increasing complexity, the gap between the generation of a product idea and the realisation of a working system is expanding rapidly. To manage complexity and to shorten design cycles, industry is forced to look at system-level languages towards speci$cation and design. The (formal) system-level modelling language called POOSL is very expressive and is able to model dynamic hard real-time behaviour and to (visually) capture static (architecture and topology) structure in an object-oriented fashion. The language integrates a process part, based on the process algebra CCS, with a data part, based on the concepts of traditional object-oriented programming languages and it is equipped with a formal semantics. Currently, a number of automated software tools (model editing, simulator and compiler tools) are available in an environment called SHESim. These tools allow visual entry of structure and topology of the system, whereas dynamic behaviour of individual processes is expressed in an expressive imperative language. The formal semantics of POOSL provides a solid basis for the application of veri$cation and performance analysis techniques and establishing a rigorous connection to existing analysis tools. References [1] Voeten JPM, van der Putten PHA, Geilen MCW, Vranken HPE, Stevens MPJ. System level description of complex hybrid systems. Presentation at Barga System Level Design Workshop, Barga, Italy, July 8–10, 1997.

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

37

[2] Gajski D, Vahid F, Narayan S, Gong J. Speci$cation and design of embedded systems. Englewood CliHs, NJ: Prentice-Hall, 1994. [3] van der Putten PHA, Voeten JPM. Speci$cation of reactive hardware=software systems. Ph.D. thesis, Eindhoven University of Technology, Department of Electrical Engineering, 1997. [4] Selic B, Gullekson G, Ward P. Real-time object-oriented modeling. New York: Wiley, 1994. [5] van der Putten PHA, Voeten JPM, Stevens MPJ. Object-oriented co-design for hardware=software systems. In: Cavanaugh M, editor. Proceedings of Euromicro’95. Los Alamitos, CA: IEEE Computer Society Press, 1995. p. 718–26. [6] Geilen MCW. Real-time concepts for software=hardware engineering. Master’s thesis, Faculty of Electrical Engineering, Eindhoven University of Technology, Eindhoven, The Netherlands, 1996. [7] Milner R. Communication and concurrency. Englewood CliHs, NJ: Prentice-Hall, 1989. [8] Nicollin X, Sifakis J. An overview and synthesis on timed process algebras. In: Larsen K, Skou A, editors. T Proceedings of the CAV’91 Third International Workshop Computer Aided Veri$cation. Alborg, Denmark, July 1991 (LNCS 575). Berlin: Springer, 1992. p. 376 –98. [9] Geilen MCW, Voeten JPM. Real-time concepts for a formal speci$cation language for software=hardware systems. Proceedings of ProRISC 1997. Utrecht: STW, Technology Foundation, 1997. [10] Turner K. Using formal description techniques. Chichester: Wiley, 1993. [11] Moreira A. Rigorous object-oriented analysis. Ph.D. thesis, University of Stirling, Scotland, 1994. [12] Narfelt K. SYSDAX: an object oriented design methodology based on SDL. In: Saracco R, Tilanus P, editors. Proceedings of SDL’87: State of the Art and Future Trends. Amsterdam: North-Holland, 1987. p. 247–54. [13] Leue S. Specifying real-time requirements for SDL speci$cations—a temporal logic-based approach. In: DembiVnski P, SV redniawa M, editors. Protocol speci$cation, testing and veri$cation XV. London: Chapman & Hall, 1997. p. 19 –34. [14] Voeten JPM, van der Putten PHA, Stevens MPJ. Systematic development of industrial control systems using software=hardware engineering. In: Milligan P, Corr P, editors. Proceedings of EUROMICRO ’97, Short Contributions. Los Alamitos, CA: IEEE Computer Society Press, 1998. p. 26 –36. [15] van der Putten PHA, Voeten JPM, Geilen MCW, Stevens MPJ. Multidisciplinary scenarios in hardware=software engineering, object-oriented co-speci$cation of complex systems. In: Veen J, editor. Proceedings of ProRISC= IEEE’97. Utrecht: STW, Technology Foundation, 1997. [16] Voeten JPM, Geilen MCW, van Bokhoven LJ, van der Putten PHA, Stevens MPJ. A probabilistic real-time calculus for performance evaluation. In: Horton G, MXoller D, RXude U, editors. Proceedings of the 11th European Simulation Symposium 1999, Erlangen, Germany. The Netherlands: Delft, 1999. SCS. p. 608–17. [17] Voeten JPM. Temporal rewards for performance evaluation. Proceedings of the Satellite Workshops of the 27th International Colloquium on Automata, Languages, and Programming, Geneva, Switzerland, Canada: Carleton Scienti$c, 2000. p. 511–22. [18] Geilen MCW, Dams DR, Voeten JPM. Applying veri$cation methods to non-exhaustive veri$cation of software=hardware systems. In: Veen J, editor. Proceedings of CSSP-98, Ninth Annual ProRISC=IEEE Workshop on Circuits, Systems and Signal Processing Mierlo, Netherlands, November 25 –27, 1998, Utrecht, The Netherlands: STW, Technology Foundation, 1998. p. 177–83. [19] Can$eld W, Emerson EA, Saha A. Checking formal speci$cations under simulation. Proceedings International Conference on Computer Design. VLSI in Computers and Processors. Los Alamitos, CA, USA: IEEE Computer Society Press, 1997. p. 455 – 60. [20] Schwiderski S, Hartmann T, Saake G. Monitoring temporal preconditions in a behaviour oriented object model. Technical Report Informatik Berichte 93-07, Technische Universitaet Braunschweig, November, 1993. [21] Geilen MCW. Non-exhaustive model-checking in component based systems. Journal of systems architecture: the EUROMICRO Journal, 2000, submitted for publication. [22] Geilen MCW, Dams DR. An on-the-Fly tableau construction for a real-time temporal logic. In: Joseph M, editor. Proceedings of the Sixth International Symposium on Formal Techniques in Real-Time and Fault-Tolerant Systems, FTRTFT2000, 20 –22 September 2000 Pune, India, Lecture Notes in Computer Science 1926. Berlin: Springer, 2000. p. 276 –90.

38

M.C.W. Geilen et al. / Computer Languages 27 (2001) 19–38

[23] van Bokhoven LJ, Voeten JPM, Geilen MCW. Software synthesis for system level design using process execution trees. Proceedings 25th Euromicro Conference, Milan, Italy, 1999. Los Alamitos, CA: IEEE Computer Society Press, 1999. p. 463–7. [24] Michielsen R, Voeten JPM. Implementation of POOSL in hardware. Proceedings of ProRISC’97. 1997. [25] Voeten JPM, van der Putten PHA, Stevens MPJ. Behaviour preserving transformations in SHE—a formal approach to architecture design. Proceedings of Euromicro’96. 1996. Marc Geilen has been working from 1996 to 2000 as a Ph.D. student at the Information and Communication Systems group at the faculty of Electrical Engineering at Eindhoven University of Technology and since 2000 as an assistant professor. In 1996, he received his Master’s degree in Information Technology from this institute. His research interests and current activities include speci$cation and modelling of real-time concurrent systems and their (formal) veri$cation and validation. Jeroen Voeten received his master’s degree in Mathematics and Computing Science in 1991 and his Ph.D. in Electrical Engineering in 1997 from the Eindhoven University of Technology, the Netherlands. Since 1997, he is working in this institute as an assistant professor in the section of Information and Communication Systems. Current research interests include formal techniques for the design, speci$cation, analysis and implementation of communicating hardware=software systems. Piet van der Putten received his degree in Electrical Engineering from the IHBO te Eindhoven in 1971. Since 1974, he was research employee at the Faculty of Electrical Engineering of the Eindhoven University of Technology in the section Digital Systems. He followed the post masters programme in Information and Communication Technology and received the degree of Master of Technological Design from the Stan Ackermans Institute in 1993. Since 1993, he is an assistant professor in the section of Computers, Networks and Design. In 1997, he received his Ph.D. from the Eindhoven University of Technology. His interests include requirements analysis, object-oriented analysis, design methodology, and system level modelling of hardware=software systems. Leo van Bokhoven received his master’s degree in Information Technology Sciences in 1998 from the Eindhoven University of Technology (TU=e), the Netherlands. Since 1998, he is a Ph.D. student at the section of Information and Communication System, working on simulation for system-level design languages for hardware=software systems. Mario Stevens received his master’s degree in Electrical Engineering in 1971 from the Eindhoven University of Technology (TU=e). From 1970 till 1986, he was working as a member of the research staH in the Digital Systems section. He was employed as a part time professor Microprocessor technology at the Open University Heerlen from 1986 till 1998. From 1995 till 1997, he was the Scienti$c Director of the Stan Ackermans Institute for Technological Design (TU=e). Since 1986, he is full professor of Digital Information Techniques at the TU=e. His research interest is in the area of design methodology for digital information processing systems.