Step-wise Refinement Design Example Using LOTOS

Transcription

1 Step-wise Refinement Design Example Using LOTOS Luís Ferreira Pires a and Wanderley Lopes de Souza b a Tele-Informatics Group, University of Twente, PO Box 217,7500 AE Enschede, the Netherlands b GRC/DSC/CCT, Universidade Federal da Paraíba, Av. Aprígio Veloso, 882,58100 Campina Grande (Pb),Brazil Abstract The importance of a design methodology when using Formal Description Techniques is generally agreed in the scientific community. This paper presents some design principles and concepts that characterize a step-wise refinement design approach and illustrates their application on an example of a mutual exclusion access system. The relevance of this work is to provide a reference as to how design decisions during the design trajectory can be taken and represented in LOTOS specifications, and to evaluate the suitability of such techniques for use on an industrial scale. 1. INTRODUCTION LOTOS - Language Of Temporal Ordering Specification - is one of the Formal Description Techniques (FDTs) standardized by ISO [1] aiming at support of specification of OSI services and protocols. Due to its high expressive power, LOTOS is suitable for description of systems that display concurrency, distribution and synchronization. Since LOTOS is an International Standard and has therefore gained stability, it is important to explore the use of the language in the various possible application fields. The availability of methodologies and tools will enable LOTOS to be used on a large scale in the industrial and academic worlds. This paper discusses the use of LOTOS to support system implementation design, according to certain design principles, by means of a medium size non-trivial example. Our purpose is to illustrate how designers can reach a sufficiently refined specification of a system, from which an implementation could be derived. The paper is organized as follows: section 2 summarizes the main concepts (e.g. step-wise refinement and specification styles) that we make use of, relating our work to current research; section 3 presents the example problem and its more abstract formal specification; section 4 shows the step-wise refinement process applied to the specification of section 3; conclusions are drawn in section THE DESIGN PROCESS The ultimate goal of the system design process is to derive a system realization - a concrete instance of a system - that fulfils the user requirements. The design process, in the case of complex distributed and concurrent systems, is a complicated task. In order to cope with complexity the design process must be carried out in steps, characterizing a design trajectory. In each design step a more refined version of the design is elaborated. Some qualitative de

2 sign principles (orthogonality, generality and open-endedness) to evaluate designs and the way in which they are formulated have been addressed in [2]. Specification styles, as a means to guide the designer in making efficient use of language elements, is of paramount importance as a measure of the suitability of specifications for their purpose in the design trajectory. In the initial steps of a design trajectory the user requirements must be analyzed and partly formalized in an initial specification. We call this specification an architecture 1. The architecture must not contain irrelevant details such as internal structure, since these details must be subject to design at lower levels of abstraction. A realization can be obtained from the architecture by taking a set of design decisions. A good practice is to evaluate and to take a small amount of design decisions in isolation each time, producing therewith intermediate more refined specifications, until a final specification that can be mapped onto a realization in a straightforward way is reached. This final specification is called an implementation and the approach towards design in which design decisions are evaluated and taken in isolation is called step-wise refinement([3]). Nevertheless LOTOS seems to present limitations with respect to representation of concreteness, as required in the implementation. Consequently we expect that a translation from LOTOS to an implementation language (programming or hardware design language) will take place some in the design trajectory. We strive for this translation to happen at late steps, since it appears that many aspects of system functionality can be effectively represented in LOTOS throughout the design trajectory. When talking about literature, style denotes the way someone expresses himself making use of words. In our context of formal specification, style denotes the way the designer expresses the functionality of systems making use of language elements. Therefore we conclude that styles are inherent to designers, although designers have to be disciplined to make efficient use of language elements. A specification can generally be regarded as one of: (i) extensional description: representing "what" the system does, abstracting from internal structure and details; (ii) intensional description, representing "how" the system does its functions, thus showing system structure or detail. For extensional descriptions the monolithic and the constraint-oriented styles are defined; for intensional descriptions the state-oriented and the resource-oriented styles apply. Further information and examples for these styles can be found in [2]. 3. THE MUTUAL EXCLUSION ACCESS PROBLEM Our design example is a mutual exclusion access system that coordinates the access of users to a shared resource (e.g. printer, plotter). The mutual exclusion access service presents two service primitives (SPs), ME_Begin to indicate the beginning of resource access and ME_End to indicate the release of the resource. Any ME_Begin at a certain service access point (SAP) must be followed by a ME_End at the same SAP, characterizing the mutual exclusion. The user requirements state that the mutual exclusion access service users may be placed at different sites (a distributed system). This requirement means that some initial design decisions have to be taken in order to provide connectivity between users (a lower layer service) and intelligence to coordinate the mutual exclusion (protocol). Therefore service users are connected to local controllers and all the controllers are attached to a virtual ring (VR), which is their communication path ([4,5]). The privilege to access the resource is negotiated by the controllers that make use of the virtual ring to exchange state information. Depending on its left neighbour s state and its own state, each controller decides whether or not its user can access the resource. The algorithm to define the access privilege is a modified version of the one presented in [6]. Here we consider that only one controller at a time has the privilege. The controller that has the privilege may allow its user 1 The use of the term architecture in this paper may seem unconventional, but it is the same concept as in [2]

3 to access the resource; after some time this controller makes a move and changes its state, passing the privilege to its right neighbour. For further details about the algorithm we refer to [7]. The virtual ring service supports the exchange of state information between two neighbouring controllers. An S_Req service primitive (SP) at VR SAP i leads to an S_Ind at VR SAP i The ring service expects then an S_Resp SP with the requested state value at i-1, that pops up as an S_Conf SP at i. Figure 1 shows the structure of the system in terms of service boundaries and access points. User 0 User i User i+1 User N-1 u Controller 0 Controller i Controller i+1 Controller N-1 r Virtual Ring Service Provider Figure 1. System Structure in terms of Service Boundaries. We concentrate our attention on the design of a controller, since it is expected to be part of the embedded system to be produced. In the most abstract description we model the controller as a black box that interacts with its environment through gates u and r. Gate u represents the mutual exclusion (ME) SAP while gate r represents the VR SAP. Due to the fact that each controller has only one ME SAP and one VR SAP, we abstract from the identification of SAPs in the formal description. Nevertheless it is interesting to remark that combining the controllers and the virtual ring makes the identification of SAPs mandatory. Unlike [5] we do not consider failure procedures here. The architecture of the controller was specified using constraint-oriented style. The behaviour of a controller is regarded as a composition of local concerns at gate r represented in process RingConstraints and concerns related to communication between gates u and r described in process ControllerProtocol. The local constraints at gate r are described as a composition of constraints related to asking state of the left neighbour (process AskLState) and constraints related to answering state to the right neighbour (process AnswerRState). Here we require that the controller only answers its state to its right neighbour if it has asked the state of its left neighbour beforehand, since we want the privilege to circulate in the ring, and only a single controller offering access at a time (mutual exclusion). Constraints on the relationship between gates u and r represent the protocol mechanisms, i.e. how resource access is granted to the resource user. Process Controller-Protocol contains an initialization phase in which an initial state is chosen. The initial state must also comply with the requirement that only one controller in the whole mutual exclusion system has the privilege at a time. The protocol operation that follows the initialization consists of a repetition of three consecutive activities, namely trying to get the privilege, offering access to the resource user and modifying the controller state. From time to time the controller will try to get the privilege. This is modelled in the specification by an internal event, since we want to have a language element to explicitly describe this fact. After the privilege is obtained by the controller, the resource is available to the mutual exclusion service user. The controller will decide when to cease the access offer in case the user does not make use of the resource; this situation is described by an internal event modelling an access timeout. There follows the most abstract LOTOS specification of the controller. Abstract Data Type (ADT) definitions are considered to be available although they are omitted in the text for rea- 2 i {0, 1,..., N-1}; an S_Req at SAP i=0 leads to an S_Ind at SAP N-1-3 -

4 sons of brevity, but can be found in [8]. specification ME_Controller[u,r] : noexit <ADTs> behaviour RingConstraints[r] [r] ControllerProtocol[u,r] process RingConstraints[r] : noexit:= AskLState[r] AnswerRState[r] process AskLState[r] : noexit:= r!s_req ; WaitForConf[r] >> AskLState[r] process WaitForConf[r] : exit:= r?prim : RingPrim [IsNotReq(prim)] ; ( [IsConf(prim)] -> exit [] [IsNotConf(prim)] -> WaitForConf[r] ) endproc (* WaitForConf *) endproc (* AskLState *) process AnswerRState[r] : noexit:= r?prim1 : RingPrim [IsNotResp(prim1)] ; ( [IsInd(prim1)] -> r?prim2 : RingPrim [IsResp(prim2)] ; AnswerRState[r] [] [IsNotInd(prim1)] -> AnswerRState[r] ) endproc (* AnswerRState *) endproc (* RingConstraints *) process ControllerProtocol[u,r] : noexit:= choice InitialState : State [] i ; ProtocolOperation[u,r](InitialState) process ProtocolOperation[u,r](s : State) : noexit:= i ; AskPrivilege[u,r](s) >> AccessOffered[u] >> ( choice NewState : State [] [NewState ne s] -> i ; ProtocolOperation[u,r](NewState) ) process AskPrivilege[u,r](s : State) : exit:= r?prim : RingPrim [IsResp(prim) implies (s IsStateOf prim)] ; ( [IsConf(prim)] -> ( [s HasPrivilegeWith State(prim)] -> exit [] [s NoPrivilegeWith State(prim)] -> ProtocolOperation[u,r](s) ) [] [IsNotConf(prim)] -> AskPrivilege[u,r](s) ) endproc (* AskPrivilege *) process AccessOffered[u] : exit:= SingleAccess[u] [] i ; exit process SingleAccess[u] : exit:= u!me_begin ; u!me_end ; exit endproc (* SingleAccess *) endproc (* AccessOffered *) endproc (* ProtocolOperation *) endproc (* ControllerProtocol *) endspec (* ME_Controller *) 4. DESIGN STEPS In this section we discuss the design steps that lead us to intermediate specifications. In each design step we consider that there is an initial specification at some (N) level of abstraction that is transformed to a more refined specification at some (N+1) level of abstraction. Some typical design decisions to be taken at a design step are definition of internal structure, removal (or iso

5 lation) of non-determinism, or refinement of interfaces. We address in this paper the first two examples of these design decisions. When facing the problem of how to define structure, the designer has the choice of applying the principle of "separation of concerns". This principle consists of identifying (partly) independent concerns and, based on these concerns, defining cooperative components. The degree of independence of the components may determine the complexity of their interface; poor separation of concerns may lead to a highly complicated interface. The removal of non-determinism can be accomplished by refining the specification down to the details (e.g. description of algorithms). The isolation of non-determinism can be applied to aspects that cannot be formally represented with the specification language model (e.g. timing in LOTOS). When defining structure we need to express the structural decisions (components and component interactions) in our design specifications. In LOTOS we can do that using language elements such as the parallel operator and hiding of gates; the use of these language elements characterizes the resource-oriented specification style. Furthermore there are behavioural aspects of the initial architecture that will be preserved through the step-wise refinement process Resource Access Control Refinement From the analysis of the controller specification in section 3 one can identify two main streams of functionality: resource access control and handling of privilege at the ring. These two aspects can be used to define cooperative components, as shown in figure 2. Figure 2. Resource Access Control Refinement. Process AccessControl and process PrivManager communicate through gate a, considered to be internal to the controller. Although the so-generated new specification of the controller displays resource-oriented style, each of the components (PrivManager and AccessControl) will be again specified in monolithic or constraint-oriented style. Interactions at gate a indicate access enabled or disabled to process AccessControl. Process AccessControl waits until the access is enabled by PrivManager. When the access is enabled the user is given a chance to access the resource. The sequence is finished when the access is disabled either by an access timeout or by a resource access. There follows the LOTOS specification of this structure. Some processes omitted here can be found in [8]. specification ME_Controller1[u,r] : noexit <ADTs> behaviour hide a in AccessControl[u,a] [a] PrivManager[a,r] process AccessControl[u,a] : noexit:= WaitEnable[a] >> AccessOffered[u] >> WaitDisable[a] >> AccessControl[u,a]... process PrivManager[a,r] : noexit:= RingConstraints[r] [r] PrivOperation[a,r] process PrivOperation[a,r] : noexit:= choice InitialState : State [] i ; ProtocolOperation[a,r](InitialState) process ProtocolOperation[a,r](s : State) : noexit:= u AccessControl a PrivManager r - 5 -

6 i ; AskPrivilege[a,r](s) >> AccessInstance[a] >> ( choice NewState : State [] [NewState ne s] -> i ; ProtocolOperation[a,r](NewState) )... endspec (* ME_Controller1 *) 4.2. Privilege Handling Refinement In process PrivManager we can identify two concerns, namely the ring primitive handling and central management. The controller is decomposed as shown is figure 3. Figure 3. Privilege Handling Refinement. Gate m represents the interaction point between CentralManager and RingHandler. The interactions at gate m are to request (PrivReq (state)) and to respond (PrivResp (state)) to privilege. Therefore we isolate the handling of ring primitives from the evaluation of privilege states. specification PrivManager1[a,r] : noexit <ADTs> behaviour hide m in CentralManager[a,m] [m] RingHandler[m,r] process CentralManager[a,m] : noexit:= ManagConstraints[m] [m] ManagControl[a,m] process ManagConstraints[m] : noexit:= m?p1 : PrivPrim [IsPrivReq(p1)]; m?p2 : PrivPrim [IsPrivResp(p2)] ; ManagConstraints[m] endproc (* ManagConstraints *) process ManagControl[a,m] : noexit:= choice InitialState : State [] i ; ManagControlRun[a,m](InitialState)... process RingHandler[m,r] : noexit:= RingConstraints[r] [r] RingSeqHandler[m, r] process RingSeqHandler [m,r] : noexit:= WaitPrivState[m] >> accept s : State in WaitConf[r](s) >> accept s1 : State in RespPrivState[m](s1) >> RingSeqHandler[m,r]... endspec (* PrivManager1 *) 4.3. Central Manager Refinement In this design step we refine CentralManager by identifying cooperative functions that will have to be performed by this component at a lower abstraction level. These functions are state initialization, state storage, privilege request initiation, access grant (privilege algorithm) and state actualization. The structure we have chosen to reflect these functions (see figure 4) consists of processes Initialization and Memory as kinds of peripherals and process CentralControl to coordinate their operation. Process Memory interacts with its environment via either a Read(state) or u AccessControl a CentralManager m RingHandler r - 6 -

7 a Write(state) interaction. In our example the memory must be first written by an initialization component and only then can read and write operations happen in any order. Process Init performs the initialization of the memory and then halts. Process CentralControl starts a privilege request, runs the privilege algorithm eventually enabling access, and generates a new state. a Init Memory me m CentralControl Figure 4. Central Manager Refinement. specification CentralManager1[a,m] : noexit <ADTs> behaviour hide me in ( Initialization[me] CentralControl[me,a,m] ) [me] Memory[me] process Memory[me] : noexit:= me?op : MemoryOperation [IsWrite(op)] ; MemoryRun[me](State(op)) process MemoryRun[me](s : State) : noexit:= me?op: MemoryOperation [IsRead(op) implies (s IsStateOf op)] ; MemoryRun[me](State(op)) endproc (* MemoryRun *) endproc (* Memory *)... endspec (* CentralManager1 *) 4.4. Further Implementation Decisions From a certain point in the design trajectory, the design decisions are more guided by some knowledge about target realization environments, such as hardware, software, firmware or operating system resources. When dealing with hardware realization, a possibility could be to define basic hardware building blocks, which would be then specified in LOTOS. The components of our intermediate architecture can be specified as a composition of such hardware building blocks. In [8] we illustrate this idea with process AccessControl, which is structured there as a combination of a sequencer and a timer. Aspects that can still be refined in LOTOS include the algorithm that gives the access to resources. More detail about the conditions for privilege (refinement of HasPrivilegeWith) and the generation of new state can be introduced as further refinements of CentralControl, aiming at removing non-determinism due to incompleteness. So far we have considered the controller s state as a sort in the ADT definition without any structure. Nevertheless the algorithm determines that states have two components, a fixed one that indicates the controller position (Site_Id) and a counter, which is incremented every time a controller makes a move. The formal description of the state can be complemented with ADT definitions that fully describe the structure of the states, the privilege conditions and the new state values. 5. CONCLUSIONS In this paper we have considered at each point in the example s design trajectory one of the multiple possible design decisions, and have formalized them in a more refined version of the design. At each design step the resulting specification must conform to the previous one. We have tested the specifications for syntax and (static and dynamic) semantics correctness through - 7 -

8 simulation, using the SEDOS HIPPO [9] simulator tool. The novelty of the design strategy taken in this paper in comparison with the one taken in [4] for the same example in CCS (Calculus of Communicating Systems, [10]) is that here we identify components of the processes to be decomposed from concerns (functions) they relate to, while in [4] the strategy was to search for a composition of pre-defined CCS components that would be equivalent to the initial specification. We claim that the approach taken in this paper is much more general and, unlike the approach taken in [4], it could be applied efficiently in the systematic implementation design of much more complex systems than the one in the example. Another important aspect of the design methodology applied in this work is controlled design using FDTs. By controlled design we mean that design decisions are justified, taken and documented in formal specifications. These specifications can be verified using tools, allowing design mistakes to be detected and corrected much earlier than in conventional design methodologies, with obvious savings in time and money. 6. REFERENCES 1 International Organization for Standardization, Information Processing Systems - Open Systems Interconnection - LOTOS - A Formal Description Technique Based on the Temporal Ordering of Observational Behaviour, ISO, C.A. Vissers, G. Scollo and M. van Sinderen, Architecture and Specification Style in Formal Descriptions of Distributed Systems. In S. Aggarwal and K. Sabnani (eds.), Protocol Specification, Testing, and Verification, VIII,1988, North-Holland, pages K. Bogaards, LOTOS Supported System Development. In K. J. Turner (ed.) Formal Description Techniques, 1989, pages W. L. de Souza and B. G. Riso, Using CCS for Protocol Specifications by Step-wise Refinements. In Proceedings of the Second International Symposium on Interoperable Information Systems, INTA, Tokyo, Nov.1988, pages G. v. Bochmann and J. P. Verjus, Some Comments on Transition-Oriented versus Structured Specification of Distributed Algorithms and Protocols. IEEE Transactions on Software Engineering, 1987, 13, pages E. W. Dijkstra, Self-stabilizing Systems in Spite of Distributed Control. Communications of the ACM,17(11),1974, pages J. Mossiere, J. Tchente and J.P. Verjus, Sur l exclusion mutuelle dans les reseaux informatiques - Publ. 75, IRISA, Rennes, France, L. Ferreira Pires and W. L. de Souza, Step-wise Refinement Design Example Using LO- TOS - Memoranda Informatica 90-55, University of Twente, Enschede, the Netherlands, P. van Eijk, Software tools for the Specification Language LOTOS - PhD Thesis, Twente University of Technology, Enschede, the Netherlands, R. Milner, A Calculus for Communicating Systems - LNCS 92, Springer-Verlag,