represents the reception of an indication message from a peer without needs of

response. Furthermore, it is also possible to describe more specific situations by

combining with other patterns. For example, by combing the pattern unconfirmed

receiver with the pattern timer, we can get a new pattern timed receiver which is a

common situation to take a message in timing constraints.

For the adaptation of patterns in a real system, patterns have to be instan-

tiated. In other words, all states, messages, actions, timers, and predicates have

the concrete names and values before applying to the system. For example, the

pattern unconfirmed receiver can be instantiated to be used in an ATM connection

such as ({WAIT, EST}, WAIT, {AAL_EST.ind}, {
"allocate i. -..in..' ->}, ,). Upon receiving AALEST.ind at the state WAIT, the

CEFSM moves to the next state EST after performing the action allocate resource.

There are no outputs and variables in this instantiation. Note that the indication

at the pattern unconfirmed receiver has the real name AAL_EST.ind. As a result,

the instantiated pattern is actually used at the design of a system. The concept of

specialization and instantiation was introduced by Casati et al. [19] where the au-

thors provide a formal basis for expanding their patterns to deal with the exception

cases in workflow design. Structural patterns also need the instantiation such as

the behavioral patterns.

Meanwhile, the elementary patterns can be used to make new patterns specific

to other domains. For instance, suppose we are going to develop a pattern language

for reactive systems. First, we identify and analyze recurring situations in the

domain. Then, patterns for the domain are constructed on top of the elementary

patterns such as the case of message transfer.

The remainder of the dissertation is organized as follows. In Chapter 2, we

begin with the related work and background information on patterns, SDL, and

SPIN model checker. Then, each structural and behavioral pattern of the pattern

language is described in detail in Chapter 3. Next, in Chapter 4, we present the

validation technique of pattern-based design which includes model construction

and SPIN usage in the validation. In Chapter 5, we perform case studies on an

alternate bit protocol and an ATM signaling system to show the feasibility of our

methodology. We conclude in Chapter 6 with a summary of the dissertation and

further research.

CHAPTER 2
RELATED WORK

2.1 Patterns in Communication Systems

This section provides the basic concept of a pattern and its relationship to

our work. The notion of a pattern was made by a group of building architects who

identified recurring problems in building constructions. They presented solutions to

the problems in a book for other architects to reuse them in similar situations [20].
Each pattern describes a problem that occurs over and over again in
our environment and then describes the core of the solution to that
problem in such a way that you can use this solution a million times
over without ever doing it the same way twice.
Software engineers have used the idea in software developments. From the essential

techniques and well-proven experience in software design and implementation,

developers are able to reuse the successful practices in their further developments.

Although the concept of a pattern is simple and has been known for a long time,

software patterns have become popular with the introduction of the books of

Buschmann et al. [1] and Gamma et al. [2]. See also the patterns home page [21]

components of the patterns have direct counterparts in PROMELA. By converting

each component into the corresponding PROMELA construct, we can build a model.

At the design phase, we separate the modeling in two steps for architectural design

and behavioral design.

4.1.1 Model Construction from Patterns

4.1.1.1 Modeling architectural design
The main task in this step is to construct an outline of a model from archi-
tectural components. A block is mapped to a process declaration in proctype and
an instance of the block can be created dynamically in the run operator. A com-
munication path between blocks is implemented in a PROMELA channel chan that
carries messages and their parameters. All input and output messages are defined
by symbolic constants in mtype. As an example of the model construction, we

present a fragment of PROMELA code for the architecture of the nine-digit dialing
as in Figure 4-2 (a). The block i;.'. _i.l-i/L_,til reads a telephone number composed
of nine digits from an upper layer caller. Then, it requests a connection conn_req

with a callee via the lower layer. In the modeling, attention has to be paid to the
interface with environments. The block is in the middle of two adjacency blocks
caller and lower. There are two communication paths fromcaller and tolower
among them.

size. A typical approach we have used regarding the channel capacity is to check

both synchronous and asynchronous communication all the times if it is possible.

The results are quite different in many cases. We start with the channel size zero

for synchronous communication and then increase it gradually. When the valida-

tion cannot be performed due to the state space explosion, we use other techniques

such as state-vector compression and bit-state hashing.

When a process transfers a message, message fields specified in a send or

receive statement must have the same number of fields and each field has to be

compatible with data type as in channel declaration. One problem in implementing

a communication path is that several messages with different definitions could

be passed through a single communication channel. As a simple solution of this

problem, a channel can be declared to be wide enough to carry all messages on the

channel. Each channel thus has appropriate fields to store each message with its

parameters [58].

4.1.3 Timer Handling

One challenging issue in the behavioral pattern is the modeling of a timer. In

a communication system, a message may occur later than it is expected, or not

happen at all because of a lost message. Thus, timing constraints are necessary to

control the waiting time of an expected message. For this purpose, we introduce

the timer and timer-related operations, set and reset.

A timer is a component of the pattern language to generate a timer expiration

signal when a time value assigned to the timer has been exceeded [14]. It has two

modes, active and inactive. Initially, a timer is inactive. The operation set(v,T)

allocates the time value v to the timer T and makes the timer be in the active

mode. Once a timer is set, the timer creates a timer expiration signal after passing

the time value unless it has been cancelled by the reset operation. The operation

reset(T) stops the timer T and changes the timer to the initial inactive mode.

Typically, if an expected message arrived before a timer expiration signal, the

system resets the timer. Otherwise, the system receives the timer expiration signal

and then sends an error notification for the lossy message or requests resubmission

of the expected message. Note that the unit of a time value depends on the context

of an application.
To validate the pattern-based design, it is necessary to translate the timer,
timer-related operations, and timer expiration in a PROMELA model. In our
modeling, we use an abstraction of a timer as introduced in Bosnacki et al. [55]
where a timer is represented in a Boolean variable initialized to false. For the
set operation, the timer variable is assigned to true to activate the timer. For
the reset operation, it has false value to inactivate the timer. The arrival of a
timer expiration signal is simulated by investigating the current value of the
timer variable. If a timer has true value at the investigation, this means that the
timer was activated sometime before. Thus, we assume that the timer expiration

signal has arrived at the time of investigation. This method abstracts out the

real concrete value of a timer. The following shows the modeling of timer T in

This method is simple and covers all potential situations regardless of the

timer value. One problem with this method is the possibility of an unreceived

message remaining in the channel. This happens due to either the prematured

timer expiration, i.e. a timer is expired even though the message is delivered in

time, or a delayed message. Therefore, it is necessary for a process to consume

the remaining message. For instance with the above example, it is possible for the

sender to execute the timer expiration part even though the receiver replied with

the ACK. As a result, the sender has to consume or receive the message from the

channel comm sometime later. If there are many timers in a system, it is hard to

consider all situations of unreceived messages. Moreover, the prematured timer

expiration is not common in a real situation.

As a second method to model the timer, we assume that the timer expiration

happens only due to the message loss. In this situation, we simulate the timer

expiration by investigating the status of the model as well as the timer variable.

If a timer has true value and the model is in the deadlock state, we assume that

the deadlock was caused by a message loss. Thus, the code to handle the timer

expiration signal is executed to resolve the deadlock. For the checking of deadlock,

we use timeout, a PROMELA predefined variable. It is true if no statement is

executable in any active process. Otherwise it is false. Consequently, the timer

expiration is simulated as follows:

timer expiration: (T == true) && (timeout)

Typically, the usage of timeout for timer expiration is enough in many cases [48].
One drawback of this approach is that a deadlock which has occurred for
some other reason, not by a message loss, can not be checked properly [48]. It
may be necessary for a model to reflect the message loss precisely. Thus, in a third
method, we introduce a special message that indicates the message loss. A similar
trick is found in D'Argenio et al. [46]. In this method, we do not have a timer

variable anymore. Instead, a message for a message loss is used. Then, an entity
transfers the message to simulate the message loss. As an example of this method,
the DATA-ACK example presented above could be modeled using the message
ACKLoss.

P A TTERN-BASED DESIGN AND V ALID A TION OF COMMUNICA TION PR OTOCOLS By YOUNGJOON BYUN A DISSER T A TION PRESENTED TO THE GRADUA TE SCHOOL OF THE UNIVERSITY OF FLORID A IN P AR TIAL FULFILLMENT OF THE REQUIREMENTS F OR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORID A 2003

Abstract of Dissertation Presen ted to the Graduate Sc ho ol of the Univ ersit y of Florida in P artial F ulllmen t of the Requiremen ts for the Degree of Do ctor of Philosoph y P A TTERN-BASED DESIGN AND V ALID A TION OF COMMUNICA TION PR OTOCOLS By Y oung jo on Byun August 2003 Chair: Bev erly A. Sanders Ma jor Departmen t: Computer and Information Science and Engineering P atterns help to impro v e soft w are qualit y and reduce dev elopmen t cost b y reusing the exp erience of exp erts for recurring problems. In this dissertation, w e apply the pattern concept to the dev elopmen t of comm unication proto cols, particularly fo cusing on the description and v alidation of message in teraction in the proto cols. T ypically it is imp ortan t for designers to capture essen tial functions of a system at the initial design phase and unco v er design errors as early as p ossible to prev en t the errors from aecting later phases. There are man y useful patterns for comm unication systems, but to date they are mainly concen trated on the ob jectorien ted design and implemen tation. There is little researc h on the patterns for message in teraction and the v alidation of pattern-based design. W e h yp othesize that man y comm unication proto cols can b e dev elop ed using a few recurring patterns. In this pattern-based metho dology w e prop ose a set of patterns to describ e the arc hitectural and b eha vioral sp ecication of comm unication proto cols. A complex proto col can b e obtained b y comp osing suc h patterns. T o pro vide condence in the design, w e suggest a v alidation metho d for the design using the Spin mo del x

PAGE 11

c hec k er. The v alidation is comp osed of mo del construction for the design and iden tication of desired prop erties of the system. Then, the mo del is c hec k ed against the prop erties. The most dicult part of using to ols suc h as Spin is obtaining the appropriate prop erties of a system in a formal w a y against whic h to c hec k the design. An inno v ativ e feature of our patterns is a section that helps the designer obtain the prop erties in linear temp oral logic. T o sho w the usefulness of our metho dology w e p erform sev eral case studies. F rom the metho dology proto col designers can abstract a system in sev eral patterns and unco v er design errors b efore the detailed design and implemen tation. xi

PAGE 12

CHAPTER 1 INTR ODUCTION When programmers dev elop soft w are systems, they often nd situations similar to those that ha v e arisen in previous dev elopmen ts. A design pattern is a written do cumen t pro viding a generic solution for a recurring problem in a certain con text [ 1 2 ]. A design solution that has w ork ed w ell in a particular situation can b e used again in similar situations in the future. Design patterns, therefore, help to impro v e soft w are qualit y and reduce dev elopmen t cost through predened solutions and their reuse. P atterns are considered to b e useful in man y t yp es of soft w are systems b ecause they pro vide generic solutions for common problems. Ho w ev er, it is not alw a ys easy for a domain sp ecic designer to nd and use the generic solution in a sp ecic application. The solution ma y b e unsuitable for a particular area. Th us, it is frequen tly useful to ha v e a set of patterns for a sp ecic domain. In this dissertation, w e presen t sev eral patterns for the dev elopmen t of comm unication proto cols. Actually researc h and usage of patterns in comm unication systems are increasing as an emerging area in the design patterns comm unit y [ 3 4 ]. Muc h of the w ork fo cuses on the structure of comm unicating blo c ks or ob jects and the relationship among them. Although the patterns are v aluable in system dev elopmen ts, our main concern exists in the message exc hanges among comm unicating blo c ks b ecause those exc hanges pro vide the principles of proto col op eration. Another problem that w e handle in this dissertation is the correctness and v alidation of pattern-based design. Curren tly man y patterns are concen trated on the design and implemen tation of soft w are dev elopmen t without consideration of other asp ects, for example, patterns for requiremen ts analysis and testing [ 1 ]. 1

3 design and implemen tation. F or the sp ecication of the abstract system, w e prop ose a pattern language, a collection of patterns that w ork together to solv e problems in a sp ecic domain. The pattern language is categorized in t w o groups, structural patterns and b eha vioral patterns, to address o v erall arc hitecture and common b eha vior of a proto col system. Figure 1{1 illustrates the pattern-based dev elopmen t metho dology The patterns are con tained in the pattern rep ository that has an expandable structure with pattern sp ecialization and instan tiation. After analyzing the requiremen ts of a proto col, w e devise the arc hitecture of the proto col with structural patterns. The arc hitecture is comp osed of sev eral blo c ks along with comm unication paths b et w een them. A blo c k is an arc hitectural building elemen t of a dev eloping system and can con tain other blo c ks. A t this p oin t, blo c ks are considered to b e blac k b o xes. The external in terfaces suc h as comm unication paths and messages are dened, but the in ternal details are not. The execution of the abstract system is acquired in b eha vioral patterns after the arc hitectural design. The b eha vioral patterns pro vide common b eha vior of a proto col system, fo cusing on the in teraction b et w een blo c ks. They assist dev elop ers in describing the in ternal b eha vior of blo c ks. Eac h blo c k instance has a state that ma y c hange to another state in resp onse to a message input. The resp onse ma y also trigger additional ev en ts suc h as the generation of output messages. W e use a comm unicating extended nite state mac hine (CEFSM) to formally describ e the b eha vior. Predicates and timers ma y b e used to describ e conditional b eha vior and timing constrain ts. Note that w e use the ev en t, signal, and message in terc hangeably in this dissertation. Proto col designers complete the abstract design of a proto col system b y comp osing the structural and b eha vioral patterns. It ma y b e necessary to revise the requiremen ts during the design step to x an y unclear requiremen ts. As a result of the design, w e ha v e a system design description whic h sk etc hes an

PAGE 15

4 abstract system of a proto col fo cusing on message exc hanges. The description is a com bination of instan tiated blo c ks, comm unication paths, messages, and other comp onen ts of patterns used. After the pattern-based high-lev el design, w e p erform a v alidation of the sp ecied system to v alidate the correctness and consistency of the design. It is imp ortan t to unco v er them as early as p ossible to prev en t the errors from aecting the later phases. In this dissertation, w e suggest a mo del c hec king tec hnique for the v alidation of the design. Mo del c hec king is an automatic tec hnique to v erify prop erties of a system b y in v estigating a mo del of the system [ 7 8 ]. W e selected Spin (Simple Promela INterpreter) as our mo del c hec king to ol. It w as dev elop ed at Bell Labs for the analysis and v alidation of distributed systems, esp ecially of comm unication proto cols [ 9 10 11 ]. F urthermore, it is freely a v ailable from the Spin w eb site [ 11 ]. F or the Spin mo del c hec king, w e rst build a mo del of the system design description in Pr omela an input language of Spin and iden tify requiremen ts or prop erties to b e c hec k ed from the description. Then, the mo del is sim ulated and v eried against the prop erties using Spin Usually the construction of a mo del is a c hallenging practice in formal v alidation b ecause it is crucial to v alidation result and it m ust rerect the system to b e dev elop ed exactly W e pro vide a translation mec hanism to build a mo del from a pattern-based design sp ecication. The translation is simple b ecause of the corresp ondence b et w een the pattern elemen ts and Pr omela constructs. Mean while, it is imp ortan t to iden tify the prop erties of a system in the design phase so that they can b e used for later testing and main tenance of the system as w ell as for the design v alidation. F or this purp ose, eac h pattern of our pattern language pro vides a prop ert y sp ecication section to help to describ e some prop erties from the pattern. Consequen tly prop erties to b e c hec k ed at the v alidation phase

6 is giv en in Section 3.1 and 3.2 Structural patterns are used to represen t the abstract arc hitecture of a proto col system whic h is a com bination of comm unicating blo c ks, comm unication paths, and messages. One pattern is able to depict a hierarc hical structure b y nesting other patterns. In addition to the static arc hitecture expressed in the pattern proto col la y er or m ux, blo c k instances can b e created dynamically using the pattern dynamic handler. Beha vioral patterns help a designer describ e in ternal b eha vior of blo c ks iden tied in structural patterns. W e use CEFSM to describ e the b eha vior. One feature of the b eha vioral patterns is that a state transition diagram (STD) is used to represen t the CEFSM. There is no standard notation for pattern description, although for ob ject-orien ted systems the Unied Mo deling Language (UML) and Ob ject Mo deling T ec hnique (OMT) are common [ 15 16 ]. W e use STD b ecause it is easy to understand and translate in to our v alidation language Pr omela A pattern is represen ted in a particular form to describ e the design problem and its solution. There are man y v arian ts in the form, but most forms t ypically ha v e name, con text, problem, solution, and example sections. W e follo w a traditional pattern description form suggested in Busc hmann et al. [ 1 ], but our form exploits SDL as an implemen tation language and additionally presen ts the prop ert y sp ecication section to aid v alidation of a system dev elop ed using the pattern. The follo wing en umerates eac h section of the form: Name: The name of the pattern. A meaningful w ord or phrase has to b e used to in tuitiv ely presen t the main purp ose of the pattern. Con text: A situation in whic h the problem of the pattern arises. Problem: General description of problem's essence. F orce: V arious viewp oin ts and asp ects of the problem that should b e considered when solving the problem. It describ es requiremen ts that m ust

PAGE 18

7 b e considered in the solution, constrain ts of the problem or con text, and desirable prop erties of the solution. Solution: The generic solution to the problem. W e use diagrams and CEFSMs to illustrate the static and dynamic asp ects of the solution. Prop ert y sp ecication: Prop erties that can b e captured from the pattern when it is used in a system design. Implemen tation: Guidelines or suggestions to transform the solution in to SDL. It is usually obtained b y one-to-one mapping of pattern elemen ts. Example: An y kno wn usages of the pattern in real applications. V arian ts: Sligh tly dieren t solutions for similar problems or more sp ecic situations. See also: An y related or similar patterns. 1.3 Organization of P atterns Soft w are reuse is a p o w erful discipline to create a new soft w are system from existing ones [ 17 ]. Although the concept is simple, it is not easy to nd a reusable artifact that pro vides high-lev el abstraction applicable to sev eral dev elopmen ts. The pattern is a go o d candidate for soft w are reuse through exp erienced design abstraction instead of real source co de. It is b eliev ed that design reuse has adv an tages o v er co de reuse [ 18 ]. M e s s a g e T r a n s f e r R e p e a t e d E v e n t s I n s t a n t i a t e d P a t t e r n s B a s i c C E F S M T i m e r i n s t a n t i a t i o n s p e c i a l i z a t i o nS t r u c t u r a l P a t t e r n s Figure 1{2: Organization of pattern language

9 the concrete names and v alues b efore applying to the system. F or example, the pattern unconrmed receiv er can b e instan tiated to b e used in an A TM connection suc h as ( f W AIT, EST g W AIT, f AAL EST.ind g f < W AIT, AAL EST.ind, EST, \allo cate resource", > g ). Up on receiving AAL EST.ind at the state W AIT, the CEFSM mo v es to the next state EST after p erforming the action al lo c ate r esour c e There are no outputs and v ariables in this instan tiation. Note that the indication at the pattern unconrmed receiv er has the real name AAL EST.ind. As a result, the instan tiated pattern is actually used at the design of a system. The concept of sp ecialization and instan tiation w as in tro duced b y Casati et al. [ 19 ] where the authors pro vide a formal basis for expanding their patterns to deal with the exception cases in w orkro w design. Structural patterns also need the instan tiation suc h as the b eha vioral patterns. Mean while, the elemen tary patterns can b e used to mak e new patterns sp ecic to other domains. F or instance, supp ose w e are going to dev elop a pattern language for reactiv e systems. First, w e iden tify and analyze recurring situations in the domain. Then, patterns for the domain are constructed on top of the elemen tary patterns suc h as the case of message transfer. The remainder of the dissertation is organized as follo ws. In Chapter 2, w e b egin with the related w ork and bac kground information on patterns, SDL, and Spin mo del c hec k er. Then, eac h structural and b eha vioral pattern of the pattern language is describ ed in detail in Chapter 3. Next, in Chapter 4, w e presen t the v alidation tec hnique of pattern-based design whic h includes mo del construction and Spin usage in the v alidation. In Chapter 5, w e p erform case studies on an alternate bit proto col and an A TM signaling system to sho w the feasibilit y of our metho dology W e conclude in Chapter 6 with a summary of the dissertation and further researc h.

PAGE 21

CHAPTER 2 RELA TED W ORK 2.1 P atterns in Comm unication Systems This section pro vides the basic concept of a pattern and its relationship to our w ork. The notion of a pattern w as made b y a group of building arc hitects who iden tied recurring problems in building constructions. They presen ted solutions to the problems in a b o ok for other arc hitects to reuse them in similar situations [ 20 ]. Eac h pattern describ es a problem that o ccurs o v er and o v er again in our en vironmen t and then describ es the core of the solution to that problem in suc h a w a y that y ou can use this solution a million times o v er without ev er doing it the same w a y t wice. Soft w are engineers ha v e used the idea in soft w are dev elopmen ts. F rom the essen tial tec hniques and w ell-pro v en exp erience in soft w are design and implemen tation, dev elop ers are able to reuse the successful practices in their further dev elopmen ts. Although the concept of a pattern is simple and has b een kno wn for a long time, soft w are patterns ha v e b ecome p opular with the in tro duction of the b o oks of Busc hmann et al. [ 1 ] and Gamma et al. [ 2 ]. See also the patterns home page [ 21 ] for the general in tro duction to the patterns. As closely related w ork, Gepp ert and R oler [ 22 ] and Gotzhein [ 23 ] suggested a pattern-based SDL design where a pattern p o ol main tains a set of SDL patterns that can b e selected, adapted, and comp osed for a new SDL system. In fact, their researc h pro vided us with the initial motiv ation. The SDL patterns are SDL-orien ted b y presen ting SDL seman tics as w ell as SDL syn tactic rules in the pattern description. Due to the SDL orien tation, their approac h mak es it p ossible to generate an executable SDL sp ecication directly from the patternbased design. Our metho dology on the other hand, can supp ort other formal 10

PAGE 22

11 description tec hniques suc h as Estelle [ 24 ] and LOTOS [ 25 ] as a design sp ecication language b ecause our patterns are represen ted in a general CEFSM. Moreo v er, b y p erforming a v alidation b efore the implemen tation, it is p ossible to nd design errors immediately after the design. Huni and his colleagues [ 26 ] prop osed a framew ork called Conduits+ to address a generalized soft w are arc hitecture for comm unication proto cols. The framew ork has t w o t yp es of elemen ts: c onduits proto col indep enden t comp onen ts, and information chunks messages that ro ws through conduits. There are four kinds of conduits in the framew ork, that is, Proto col, Mux, Adapter, and ConduitF actory By using a sequence of design patterns of Gamma patterns [ 2 ], Conduits+ is able to implemen t a net w ork proto col with a graph of conduits and information c h unks. Since the conduits pro vide simple and concise arc hitectural elemen ts for net w ork proto cols, w e use them as a part of our structural patterns. Other patterns for static comp onen ts of a proto col system are also found in P arssinen and T urunen [ 27 ] where the authors presen t common principles of a comm unication proto col in proto col system, proto col en tit y proto col b eha vior, and en tit y in terface. W e use the CEFSM to formally describ e the b eha vior of comm unication proto cols. The theoretical bac kground of it is found at the b o ok of Ellsb erger et al. [ 14 ]. There are sev eral w a ys to implemen t a nite state mac hine (FSM) in patterns [ 2 28 ]. Y acoub and Ammar [ 28 ] presen ts a pattern language that pro vides a pattern system for FSMs in ob ject-orien ted design. They prop ose a basic FSM pattern and its extensions to handle sev eral design issues suc h as state transition mec hanisms, design structure, state instan tiations, exp osure of in ternal state, and the mac hine t yp e, fo cusing on the ob ject-orien ted implemen tation. In our case, a CEFSM pattern is depicted in an STD so that the description is simple and straigh tforw ard. F urthermore, the CEFSM has an expandable hierarc hical structure using the sp ecialization and instan tiation. The pattern sp ecialization is a

PAGE 23

12 mec hanism for creating a new pattern from an existing one and the instan tiation is a nalization of a pattern to adapt it in a concrete situation [ 19 ]. Mean while, our notation in the b eha vioral patterns is based on the Statec harts [ 29 ], a visual formalism for the sp ecication of reactiv e systems. A transition of an STD has a lab el with an input ev en t, predicates, actions, and outputs ev en ts where all elds are optional although the input ev en t is almost alw a ys necessary A transition of Statec harts is lab eled with an ev en t, a condition, and an action. Statec harts ha v e more descriptiv e p o w er than our STD through the use of hierarc hies of states, orthogonalit y and history connectors. Ho w ev er, sev eral exp erimen ts suc h as the case studies presen ted in Chapter 5 sho w that our notation is enough for the description of comm unication proto cols. F aison emphasizes the imp ortance of in teraction in soft w are with m ultiple pro cesses or comp onen ts [ 30 ]. Actually in teractions b et w een comm unicating en tities are essen tial in the description of b eha vior in man y application domains. He found fundamen tal patterns in the in teractions suc h as pull in teraction and push in teraction to describ e the w a y the en tities relate to and comm unicate with eac h other. He also pro vided man y useful examples in real life and soft w are comp onen ts. The basic idea of the patterns is also found at our message transfer pattern. As a similar approac h in a dieren t domain, a w orkro w system uses pattern concept called rule p atterns in the design of exceptional handling [ 19 ]. An exceptional handling rule is represen ted with ev en t, condition, action, and output, whic h is analogous to our b eha vioral patterns except the timing concept. The authors disco v ered frequen tly o ccurring exceptional situations in w orkro w design and mo deled the abstract activit y in an application-indep enden t manner. They also in tro duced the sp ecialization and instan tiation as a formal basis for expanding their patterns.

PAGE 24

13 P atterns can b e used not only in soft w are dev elopmen ts, but also in other areas. As an example of patterns that are not relev an t to soft w are dev elopmen t, Adams and his colleagues [ 31 ] presen ted sev eral patterns for op erations and main tenance of telecomm unications systems. They describ ed their exp erience and exp ertise for highly a v ailable fault toleran t switc hes. There are also sev eral eorts made to capture patterns for domain-sp ecic applications suc h as factory automation, e-business, em b edded systems, and en terprise application [ 32 33 34 ]. Our patterns ha v e a section named se e also to pro vide the related patterns and relationship with other patterns. F urther related w ork can b e found in this section. F or more information on patterns for comm unication systems, see Busc hmann et al. [ 1 ], Sc hmidt et al. [ 3 ], and Rising [ 35 4 ]. 2.2 Mo del Chec king using Spin and Pr omela Mo del c hec king is an automated tec hnique to v alidate correctness of a system b y in v estigating a nite state mo del of the system [ 7 8 36 ]. The tec hnique is esp ecially useful for reactiv e and distributed systems that are c haracterized b y man y in teractions among pro cesses. A mo del c hec k er explores all states reac hable from an initial state and v alidates a set of correctness prop erties on the mo del. Mo del c hec king t ypically starts with the construction of a mo del and the iden tication of prop erties to b e c hec k ed. Then, it v alidates the prop erties with an appropriate mo del c hec k er. A system is usually mo deled using a state based description suc h as comm unication automata, CSP (Comm unicating Sequen tial Pro cesses), P etri Nets, etc. A mo del m ust b e made as closely as p ossible to a system so that the v alidation results for the mo del rerects the system's execution exactly The prop erties a mo del c hec k er v alidates in a mo del include the reac habilit y of a certain state, safet y and liv eness of a system, and relativ e order of ev en ts in a system [ 7 ]. Sev eral formalisms are used to precisely express the prop erties. T emp oral logic [ 37 ] is sp ecically tailored for the description of prop erties of system

16 expressed in the sym b ol ? is used suc h as child?result The c hannel in the example can store up to one in teger v alue b ecause the size of eac h c hannel is declared as one. F or sync hronous comm unication, the c hannel size has zero. There are three kinds of con trol ro w constructs in Pr omela namely selection, rep etition, and unconditional jumps. The if selection con tains sev eral execution sequences, eac h preceded b y a double colon. A sequence can b e selected only if its rst statemen t is executable. The rst statemen t is therefore called a guard. If none of the guards of the statemen t is executable, the construct blo c ks. In the ab o v e example, the if construct has t w o sequences. Note that only one sequence can b e selected among the sequences. The rep etition construct do conducts the same mec hanism as if But it rep eats the construct un til it meets the break Another w a y to terminate the rep etition is to jump to a lab el outside of the statemen t with goto A lab el iden ties a unique con trol state and can app ear b efore a statemen t. By prexing a sequence of statemen ts enclosed in paren theses with the k eyw ord atomic a user can indicate that the sequence is to b e executed as one indivisible unit, that is non-in terlea v ed with an y other pro cesses. Mean while, Spin is able to express the correctness prop erties in the Pr omela statemen ts suc h as assert end lab el, progress lab el, accept lab el, and never claims [ 44 ]. The follo wing sho ws a result of v alidation using Spin for the example Pr omela co de. (Spin Version 3.4.16 -2 June 2002) + Partial Order Reduction Full statespace search for: never-claim (not selected) assertion violations (disabled by -A flag) cycle checks (disabled by -DSAFETY) invalid endstates + State-vector 124 byte, depth reached 27, errors: 0 28 states, stored 0 states, matched

PAGE 28

17 28 transitions (= stored+matched) 0 atomic steps hash conflicts: 0 (resolved) (max size 2^19 states) 2.542 memory usage (Mbyte) unreached in proctype fact (0 of 9 states) unreached in proctype :init: (0 of 4 states) real 0.0 user 0.0 sys 0.0 In ternally Spin main tains three k ey data structure [ 45 ]: state-v ector, depth-rst stac k, and seen set. The state-vector sho ws the size of a state whic h is comp osed of the v alue of lo cal and global v ariables, con trol ro w lo cation of eac h pro cess, and the con ten ts of message c hannels. In the example, eac h state o ccupies 124 b ytes. The depth reached eld represen ts the deep est stac k depth reac hed during the depth rst searc h of the state space. The seen set holds the states already explored during the searc h. Th us, the stored means the n um b er of states stored in the seen set. The matched is the n um b er of states that w ere already found in the seen set. There is a lot of researc h that exploits Spin and Pr omela for the v alidation of comm unication proto cols [ 46 44 47 48 ]. Kamel and Leue [ 47 ] presen ted the mo deling and v alidation of the General In ter-ORB Proto col (GIOP) using Spin This pap er pro vides useful examples in the to ol usage. The authors elicit ten high-lev el requiremen ts from the text-based sp ecication and formally express them in L TL for the v alidation. Prop ert y extraction from a system requiremen ts sp ecication is common in practice. Note that our approac h to capture the system prop erties from a pattern do es not en umerate all p oten tial prop erties of a system. Nonetheless, this metho d pro vides a systematic w a y to elicit the part of prop erties of the target system.

PAGE 29

18 D'Argenio and his colleagues [ 46 ] describ ed the transfer of les on a lossy comm unication c hannel using a b ounded retransmission proto col. They presen t a sp ecication of the proto col in a net w ork of timed automata and a list of prop erties of the proto col with resp ect to inputs and outputs. Spin and Upp aal are used for the c hec king of the prop erties and sho ws the imp ortance of the real-time asp ects in the proto col v alidation. F or more exp erience and usages of Spin in proto col v alidation and other applications, refer the pro ceedings of Spin w orkshops [ 11 ]. Our design pro vides a visual description of a system in the comp osition of patterns. In fact, using the visual sp ecication suc h as STD is a common w a y to describ e a system abstraction b efore the formal Pr omela mo deling [ 49 50 ]. Leue and Holzmann [ 51 ] suggested v-Promela, a visual and ob ject-orien ted mo deling language for Spin The language is designed to presen t abstraction and hierarc hical la y ering. The visual notation is able to express b oth structure and b eha vior of a reactiv e concurren t system to acquire soft w are arc hitecture at the early life-cycle stages. They use UML for Real-Time (UML-R T) notation for structural description and adapt man y imp ortan t ideas from Realtime Ob ject-Orien ted Mo deling (R OOM). Beha vior is sp ecied using hierarc hical comm unicating extended nite state mac hines (HCEFSMs). This pap er suggests a translation mec hanism from the visual constructs to a Pr omela program. The visual notation is supp orted b y a graphical to ol, VIP On the other hand, Mikk et al. [ 52 ] ha v e translated Statec harts in to Pr omela using extended hierarc hical automata as an in termediate format. Their tec hnique allo ws a system describ ed in Statec harts to b e v alidated in a linear temp oral logic mo del c hec k er. 2.3 In tro duction to SDL and Mo del Chec king SDL System Our metho dology prop osed in this dissertation w as originally aimed at the initial design of a comm unication system to b e implemen ted in SDL. SDL sk eleton co de whic h outlines the system arc hitecture and b eha vior could b e generated after

PAGE 30

19 the pattern-based design and v alidation. In this section, w e presen t the basic concept of SDL whic h is related to our tec hniques. F urther information on SDL is a v ailable at [ 13 14 53 ]. Mean while, our pattern rep ository can b e com bined with other SDL dev elopmen t metho dologies suc h as SDL+ [ 54 ] as a library of reusable artifacts. SDL is an ob ject-orien ted formal language recommended b y the ITU T elecomm unication Standardization Sector (ITU-T) for the precise and unam biguous sp ecication of ev en t-driv en and reactiv e systems, in particular, comm unication systems [ 12 ]. It describ es structure, b eha vior, and data of a system in formal notation. The static structure of an SDL system is describ ed b y hierarc hical blo c ks. A blo c k can con tain other blo c ks, resulting in a tree structure. A leaf blo c k is made up of one or more pro cesses. Channels and signal routes are used to con v ey signals b et w een the structural elemen ts. Pro cesses are connected with eac h other and to the b oundary of the nesting blo c k b y signal routes. Blo c ks are connected together b y c hannels. If man y signals are transferred on the same c hannel or signal route, their ordering is preserv ed. In addition to the static pro cess, the SDL pro cess can also b e created dynamically The b eha vior of a system is describ ed b y a set of autonomous and concurren t pro cesses. A pro cess is an extended nite state mac hine, comm unicating async hronously with other pro cesses b y signals. Eac h pro cess has an implicit un b ounded FIF O input queue where signals are buered on arriv al. Signals are extracted from the input queue in the order of arriv al. An exp ected signal triggers a transition, and the pro cess executes a set of tasks suc h as an assignmen t of a v alue to a v ariable, a pro cedure call, and a signal output. After initiating a transition, a signal is remo v ed from the input queue. Eac h pro cess has a unique address. A signal alw a ys carries the address of the sending and the receiving pro cesses. The

PAGE 31

20 destination address ma y b e used if the destination pro cess cannot b e determined statically and the address of the sending pro cess ma y b e used to reply to a signal. In SDL, v ariables are o wned b y a sp ecic pro cess and cannot b e mo died b y other pro cesses. The sync hronization b et w een pro cesses is ac hiev ed using the exc hange of signals or remote v ariables. Man y researc hers ha v e in v estigated the sim ulation and v alidation of SDL systems using Spin / Pr omela [ 55 56 57 58 ]. Holzmann and P atti [ 56 ] in tro duced an exp erimen tal v alidation to ol, sup ertr ac e for the v alidation of an SDL sp ecication. In fact, the to ol is an ancestor of Spin and used for A T&T's 5ESS c r switc hing system with a practical size. They also presen ted some consideration in the usage of the to ol suc h as closeness of a mo del and handling of time expiration that are still op en questions in curren t Spin v ersion. Bozga and his colleagues [ 59 ] suggested a v alidation to olset with an in termediate represen tation called IF for distributed soft w are systems. The IF v alidation en vironmen t pro vides a translator from SDL to IF sdl2if so that a system describ ed in IF is able to b e v alidated in sev eral dieren t v alidation to ols suc h as Cadp [ 60 ], Kr onos [ 40 ], and Tgv [ 61 ]. Consequen tly the en vironmen t mak es it p ossible to supp ort sev eral dieren t tec hniques for one system v alidation. Sidoro v a and Steen suggested a v alidation metho dology for a large-scale SDL system in whic h an SDL sp ecication is transformed to a Pr omela mo del using the existing to ols suc h as sdl2if LIVE, and if2pml [ 57 ]. As the size of a system to b e mo del c hec k ed is limited, they use a b ottom-up comp ositional tec hnique whic h starts from small comp onen ts and then comp oses them for larger ones. T uominen [ 58 ] pro vided a translation mec hanism from an SDL-88 dialect to Pr omela Bosnac ki and his colleagues [ 55 ] ha v e extended Spin to v alidate the timing prop erties of the SDL mo del. The resulting to ol DTSpin allo ws to quan tify the time elapse b et w een ev en ts. Mean while, Prigen t et al. [ 62 ] ha v e suggested a

PAGE 32

21 v alidation of the SDL program with save op erator whic h is not handled in other literature. They extended the to ol if2pml to get a Pr omela co de from IF with save One feature in their attempts is that they extract an abstraction mo del from a completely dev elop ed SDL system. T ypically a mo del from a nal system suers from a state space explosion and cannot b e v alidated as a whole due to the size of the system. As a result, the system is split in to sev eral small comp onen ts and p erforms a v alidation from eac h comp onen t [ 55 57 ]. In our case, w e design a system in high-lev el from the patterns and obtain a v alidation mo del from it. Th us, the mo del needs relativ ely small n um b er of states for the v alidation. Additionally w e can extract sev eral prop erties of the system during the design phase. Accordingly the prop erties can b e used at the testing phase after the implemen tation of the system as w ell as the v alidation for the design. Mean while, the patterns discussed in this pap er are sp ecic to the comm unication proto cols. Ho w ev er, SDL is not alw a ys used for comm unication systems. It is p ossible for man y SDL systems to b e dev elop ed using the patterns p opular in other domains. W orm [ 63 ] presen ted SDL implemen tation of the classic patterns suc h as Observ er and F actory The examples in this pap er guide the SDL users ho w to apply the patterns in an SDL system.

28 3.1.3.2 Problem Ho w can a blo c k b e organized in ternally to service m ultiple comm unication requests?3.1.3.3 F orces Concurr ent pr o c essing : T o pro vide a go o d resp onse time, requests should b e pro cessed concurren tly Cap acity : Handling concurren t requests imp oses o v erhead for con text switc hes, resource con ten tion, etc. If to o man y requests are handled at the same time, the o v erhead will dominate the computation and the system p erformance will degrade unacceptably Therefore the amoun t of concurrency should b e b ounded. Finding the optimal b ound ma y b e dicult to determine. Static vs dynamic hand ler cr e ation : A comm unication request is serviced b y a handler, an instance of a blo c k servicing the request. An imp ortan t design decision considers when the handler instances should b e created. The static approac h creates all handlers at the system start-up time and their lifetime extends un til the system is sh ut do wn. When not servicing a request, the handlers are idle, but still utilizing system resources. On the other hand, an idle handler ma y b e quic kly deplo y ed to handle a new request with little o v erhead. The dynamic approac h creates a handler up on a request and its lifetime spans only as long as necessary to service the request. This approac h incurs o v erhead for handler creation and termination, but there are no idle handlers to unnecessarily consume system resources. Th us the resources used b y request handling adapt to the load. A static approac h is useful when the system load is uniformly high. A dynamic approac h is b etter when the system is appropriately sized and the

33 3.2.1.3 F orces Understandability : The notation should capture the most imp ortan t asp ects of the b eha vior of a system in a w a y that is con v enien t to express and can b e easily understo o d b y a reader. Completeness : The notation should b e able to express all the imp ortan t asp ects of a design. Dene dness : The notation should b e w ell-dened, preferably standardized. A formally dened notation allo ws the p ossibilit y of to ol supp ort for analysis, sim ulation, v erication, co de generation, etc. Sc alability : The notation should remain tractable for systems with large n um b ers of states. Ease of implementation : The formalism should represen t the system's b eha vior in a w a y that can b e easily mapp ed in to an implemen tation language. 3.2.1.4 Solution The b eha vior of a comm unication system can b e describ ed using a comm unicating extended nite state mac hine (CEFSM). A CEFSM is a nite state mac hine extended with lo cal v ariables and parameterized comm unication ev en ts indicating comm unication with another CEFSM [ 14 71 ]. These state mac hines are v ery familiar to computer scien tists and engineers and meet the criteria discussed in the forces section. In particular, the lo cal v ariables help with the scalabilit y problem b y allo wing, for example, an 8-bit coun ter to b e represen ted b y one v ariable instead of 256 states. Other state based formalisms [ 29 ] ma y pro vide b etter supp ort for mo dularizing large designs at the exp ense of a more complex notation. A surv ey of other formalisms that can b e used for telecomm unication systems design can b e found in [ 72 ]. When an ev en t is initiated b y the en vironmen t, the system up dates lo cal v ariables, emits output ev en ts and transitions to a new state.

47 3.2.1.11 See also T o describ e the CEFSM, w e use the STD with transitions lab eling with an ev en t, predicates, actions, and outputs. The similar notation is used at Statec harts [ 29 ], a visual formalism for the sp ecication of reactiv e systems, where a transition is lab eled with an ev en t, a condition, and an action. Statec harts are an extension of our STD to enhance the descriptiv e p o w er using hierarc h y of states, orthogonalit y and history connectors. 3.2.2 Timer 3.2.2.1 Con text In an ev en t-driv en system suc h as a comm unications system, an ev en t ma y o ccur later than it is exp ected, or not happ en at all b ecause of transmission dela y lost message, etc. Man y ev en t-driv en systems emplo y timing constrain ts where some action is tak en if an exp ected ev en t do es not o ccur in a giv en amoun t of time. W e are designing the system in CEFSMs. 3.2.2.2 Problem Ho w can w e mo del the timing constrain ts to a v oid un b ounded w aiting for an ev en t? 3.2.2.3 Solution A CEFSM can b e supplemen ted with a timer and timer-related op erations to manipulate the timing constrain ts [ 14 ]. A timer T is an elemen t of v ariable set V with an asso ciated time v alue. It has t w o mo des, active and inactive Initially a timer is inactiv e. The unit of a time v alue dep ends on the con text of an application. There are timer-related op erations, set and r eset whic h are the elemen ts of action list A The op eration set(v,T) allo cates the time v alue v to the timer T and mak es the timer b e in the activ e mo de. Once a timer is set, the timer creates a timer expiration signal after passing the time v alue unless it has b een cancelled b y the reset op eration. The op eration reset(T) stops the timer T and

64 Con trol Message Proto col (ICMP) [ 74 ]. A host sends an ICMP ec ho request, ECHO REQUEST, to a sp ecied destination and sets a timer for it. The default v alue of timeout is 20 seconds. If the request is answ ered with the ECHO REPL Y within the giv en time, the sender prin ts a successful result. Otherwise, it indicates the failure of the request. TCP timer/retransmission and Bo otstrap Proto col (BOOTP) retransmission also use this pattern [ 74 ]. See also. TimerCon trolledRep eat [ 23 ], P AR (P ositiv e Ac kno wledgmen t with Retransmission) [ 73 ], Bounded Retransmission Proto col [ 46 ], Ab ortable In teraction P attern [ 30 ]. This is the end of pattern message transfer. As men tioned b efore, the patterns presen ted in this section are not a complete set. They can b e com bined to obtain more complex and high-lev el patterns. F or example, w e can get a new pattern, conrmed sender-receiv er, a com bination of conrmed sender and conrmed receiv er for negotiation of comm unication. A t an initial state, it sends a request to a p eer, and then w ait for a conrmation suc h as conrmed sender. Then, for the conrmation message, it replies with an ac kno wledge message to guaran tee that the conrmation is agreed up on. This b eha vior is w ell-kno wn as a three-w a y handshak e [ 74 ].

67 with a callee via the lo w er la y er. In the mo deling, atten tion has to b e paid to the in terface with en vironmen ts. The blo c k is in the middle of t w o adjacency blo c ks c al ler and lower There are t w o comm unication paths fr om c al ler and to lower among them. 1 #define BUFFSIZE 2 /* channel capability */ 23 chan from_caller = [BUFFSIZE] of {mtype,DIGIT}; 4 chan to_lower = [BUFFSIZE] of {mtype,DIGITS}; 5 mtype = {dial,conn_req}; 67 proctype nine_digit_dial() {} More detailed issue on comm unication path will b e giv en later. 4.1.1.2 Mo deling b eha vioral design Recall that the CEFSM used in the design description is comp osed of a set of states and transitions. Eac h state is con v erted to a label in Pr omela Mo ving to the next state is implemen ted in goto con trol transfer construct with a target lab el. A transition p erforms a set of actions and output generation for a coming input message. F or the message exc hange on a comm unication path, the send and receiv e statemen ts are used. A decision p oin t with predicates is con v erted to the selection construct if and eac h predicate is con v erted to a corresp onding guard. The rep eated ev en t is mapp ed to the rep etition construct do The source merge is represen ted using if for the selection of a transition from merged transitions. Other merge patterns are implemen ted with goto In the pattern description, the action list is usually comp osed of assignmen t commands and arithmetic op erations. The C-lik e Pr omela syn tax supp orts the actions directly Mean while, the high-lev el abstraction action describ ed in plain English is commen ted in the Pr omela mo del so that the action is to b e designed in later dev elopmen t phases. Pr omela pro vides bit bool short int and unsigned data t yp es as w ell as array and typedef for arra y and user-dened data t yp es. They are usually enough for the data in a pattern.

70 c hannel. Eac h c hannel th us has appropriate elds to store eac h message with its parameters [ 58 ]. 4.1.3 Timer Handling One c hallenging issue in the b eha vioral pattern is the mo deling of a timer. In a comm unication system, a message ma y o ccur later than it is exp ected, or not happ en at all b ecause of a lost message. Th us, timing constrain ts are necessary to con trol the w aiting time of an exp ected message. F or this purp ose, w e in tro duce the timer and timer-related op erations, set and r eset A timer is a comp onen t of the pattern language to generate a timer expiration signal when a time v alue assigned to the timer has b een exceeded [ 14 ]. It has t w o mo des, active and inactive Initially a timer is inactiv e. The op eration set(v,T) allo cates the time v alue v to the timer T and mak es the timer b e in the activ e mo de. Once a timer is set, the timer creates a timer expiration signal after passing the time v alue unless it has b een cancelled b y the reset op eration. The op eration reset(T) stops the timer T and c hanges the timer to the initial inactiv e mo de. T ypically if an exp ected message arriv ed b efore a timer expiration signal, the system resets the timer. Otherwise, the system receiv es the timer expiration signal and then sends an error notication for the lossy message or requests resubmission of the exp ected message. Note that the unit of a time v alue dep ends on the con text of an application. T o v alidate the pattern-based design, it is necessary to translate the timer, timer-related op erations, and timer expiration in a Pr omela mo del. In our mo deling, w e use an abstraction of a timer as in tro duced in Bosnac ki et al. [ 55 ] where a timer is represen ted in a Bo olean v ariable initialized to false. F or the set op eration, the timer v ariable is assigned to true to activ ate the timer. F or the reset op eration, it has false v alue to inactiv ate the timer. The arriv al of a timer expiration signal is sim ulated b y in v estigating the curren t v alue of the timer v ariable. If a timer has true v alue at the in v estigation, this means that the timer w as activ ated sometime b efore. Th us, w e assume that the timer expiration

PAGE 82

71 signal has arriv ed at the time of in v estigation. This metho d abstracts out the real concrete v alue of a timer. The follo wing sho ws the mo deling of timer T in Pr omela timer declaration: bool T = false; set(v,T): T = true; reset(T): T = false; timer expiration: (T == true) As an example the timer mo del, let us consider a comm unication b et w een t w o comm unicating en tities. A sending en tit y transfers a message (D A T A) to a receiving en tit y and w aits for an ac kno wledgmen t (A CK) from it through the c hannel c omm The sender has a timer A CKTimer for the A CK message. /** SENDER **/ bool ACKTimer = false; /* initially inactivated */ comm!DATA; /* send DATA */ ACKTimer = true; /* set operation */ if:: comm?ACK; /* expected message */ ACKTimer = false; /* reset operation */ :: (ACKTimer == true) -> /* timer expiration */ code to handle the timer expiration ... fi;/** RECEIVER **/ comm?DATA; /* receive DATA */ if:: comm!ACK; /* reply with ACK */ :: skip; /* message loss */ fi; This metho d is simple and co v ers all p oten tial situations regardless of the timer v alue. One problem with this metho d is the p ossibilit y of an unreceiv ed message remaining in the c hannel. This happ ens due to either the prematured timer expiration, i.e. a timer is expired ev en though the message is deliv ered in time, or a dela y ed message. Therefore, it is necessary for a pro cess to consume the remaining message. F or instance with the ab o v e example, it is p ossible for the sender to execute the timer expiration part ev en though the receiv er replied with the A CK. As a result, the sender has to consume or receiv e the message from the c hannel c omm sometime later. If there are man y timers in a system, it is hard to

PAGE 83

72 consider all situations of unreceiv ed messages. Moreo v er, the prematured timer expiration is not common in a real situation. As a second metho d to mo del the timer, w e assume that the timer expiration happ ens only due to the message loss. In this situation, w e sim ulate the timer expiration b y in v estigating the status of the mo del as w ell as the timer v ariable. If a timer has true v alue and the mo del is in the deadlo c k state, w e assume that the deadlo c k w as caused b y a message loss. Th us, the co de to handle the timer expiration signal is executed to resolv e the deadlo c k. F or the c hec king of deadlo c k, w e use timeout a Pr omela predened v ariable. It is true if no statemen t is executable in an y activ e pro cess. Otherwise it is false. Consequen tly the timer expiration is sim ulated as follo ws: timer expiration: (T == true) && (timeout) T ypically the usage of timeout for timer expiration is enough in man y cases [ 48 ]. One dra wbac k of this approac h is that a deadlo c k whic h has o ccurred for some other reason, not b y a message loss, can not b e c hec k ed prop erly [ 48 ]. It ma y b e necessary for a mo del to rerect the message loss precisely Th us, in a third metho d, w e in tro duce a sp ecial message that indicates the message loss. A similar tric k is found in D'Argenio et al. [ 46 ]. In this metho d, w e do not ha v e a timer v ariable an ymore. Instead, a message for a message loss is used. Then, an en tit y transfers the message to sim ulate the message loss. As an example of this metho d, the D A T A-A CK example presen ted ab o v e could b e mo deled using the message A CKL oss /** SENDER **/ comm!DATA; /* send DATA */ if:: comm?ACK; /* expected message */ ACKTimer = false; /* reset operation */ :: comm?ACKLoss -> /* timer expiration */ code to handle the timer expiration ... fi;/** RECEIVER **/ comm?DATA; /* receive DATA */ if

74 the desired b eha vior is an imp ortan t issue in the system mo del [ 48 ]. As a high-lev el design do cumen t, the system design description represen ted in STD helps to nd correctness prop erties in a system. The visual sp ecication mak es it easier for a dev elop er to determine the in tended ev en ts and relationship among them. In this section, w e prop ose a prop ert y sp ecication tec hnique from b eha vioral patterns. 4.2.1 Linear T emp oral Logic T emp oral logic [ 37 ] is a logic for statemen ts and reasoning that in v olv e the notion of order in time. It is a useful formalism to sp ecify prop erties of reactiv e and concurren t systems and pro vides a formal and succinct notation for desired system b eha vior o v er time. W e use L TL form ulae in Spin to express prop erties of a mo del. A linear temp oral form ula is constructed from prop ositions to whic h w e apply temp oral and b o olean op erations [ 77 ]. Ev ery prop osition p a statemen t that has either true or false b o olean v alue, is an L TL form ula. F or example, D A T A was sent by a client is a true prop osition if a clien t sen t the message D A T A sometime b efore. Otherwise, it has false v alue. If the prop ositions p and q are temp oral form ulae, then so are : p p p p ^ p p q for logical connectiv es ne gation disjunction c onjunction and implic ation In addition to the b o olean op erators, an L TL form ula con tains temp oral op erators ( always ), ( eventual ly ), U ( until ), and W ( we ak until ). A Pr omela mo del is considered to b e a state transition system. L TL form ulae are used to formally state prop erties concerned with the executions of the mo del. F or instance, (D A T A (A CK )) means that whenev er the ev en t D A T A has o ccurred, the ev en t A CK has to follo w it ev en tually A mo del c hec king to ol can automatically v alidate that the prop ert y is satised with a system.

PAGE 86

75 It is w orth noting that some exp erience is required to write temp oral logic statemen ts, whic h is one of the obstacles to the more widespread usage of mo del c hec king tec hniques [ 7 ]. Dwy er and his colleagues [ 78 79 ] in tro duced a pattern system for prop ert y sp ecication for nite-state v alidation. The pattern system describ es commonly o ccurring prop erties in a nite-state system. P atterns are largely classied for the o ccurrence and order of states and ev en ts. They include absence, univ ersalit y existence, b ounded existence, precedence, resp onse, c hain precedence, and c hain resp onse. By using the patterns, it is p ossible for dev elop ers to express prop erties more easily It exp edites the dev elop ers learning and writing more expressiv e sp ecication. 4.2.2 Prop ert y Extraction from Comm unication P atterns One imp ortan t issue in the v alidation is to iden tify the requiremen ts or the prop erties of a designed system. If suc h prop erties are not pro vided prop erly it is not p ossible to determine whether the system meets the required b eha vior. As a high-lev el design do cumen t, the system design description pro vides the requiremen ts of a system. They are particularly useful to iden tify the existence of an ev en t and order of ev en ts. Eac h pattern has a prop ert y sp ecication section to describ e the prop erties required b y the pattern. Mean while, w e need a metho d to c hec k an ev en t o ccurrence suc h as the message transfer and reception in the Spin v alidation. F or this purp ose, w e asso ciate an ev en t o ccurrence with a con trol lo cation that comes immediately after the ev en t o ccurrence statemen t [ 47 ]. A lab el is used to iden tify a con trol lo cation in a pro cess declaration. By c hec king the reac habilit y of the lab el, w e kno w that the ev en t has really happ ened. F or example, to see the reception of a message A CK in a sending pro cess, w e in tro duce a lab el A CK rcv after the reception statemen t: ...

PAGE 87

76 comm?ACK -> ACK_rcv: skip; /* instrument a control label */ ... Note that a lab el in a Pr omela mo del alw a ys prexes a statemen t and thereb y uniquely iden ties a con trol state corresp onding to the lab eled statemen t [ 41 ]. Then, remote reference in an L TL form ula is used to see the arriv al of the pro cess con trol at the con trol lab el. The remote reference mak es it p ossible to determine the curren t state of an activ e pro cess from an L TL form ula. The remote reference op erator tak es three argumen ts: the rst is the name of a process, the second is an instan tiation n um b er of an executing pro cess of that t yp e, and the third argumen t is the name of a lab el that is dened within the process. The op erator returns a non-zero v alue if and only if the pro cess referred to is curren tly in the state mark ed b y the lab el. F or instance, supp ose a v ariable s pid has an instance n um b er of the sending pro cess. Then, the reference sender[s_pid]@ACK_rcv ev aluates to true when the pro cess instance is at the state referred b y the lab el A CK rcv. Using the remote reference, w e can c hec k that the input ev en t A CK has ev en tually o ccurred.

PAGE 88

CHAPTER 5 CASE STUDIES 5.1 Case Study: Alternate Bit Proto col T o sho w the practical usage of pattern-based dev elopmen t, w e ha v e p erformed sev eral case studies. As a simple one, w e demonstrate a v ariation of alternating bit proto col (ABP) [ 44 73 ] whic h pro vides a simple but reliable message transfer on a lossy lo w er la y er. The follo wing is the requiremen ts sp ecication of the proto col: A sending en tit y transmits a D A T A to a receiving en tit y When the receiving en tit y tak es the D A T A from the sending en tit y it replies with an A CK so that the sender is able to transfer the next D A T A. Th us, eac h D A T A should b e ac kno wledged b efore the next one is sen t. The lo w er la y er could randomly lose messages but not corrupt the con ten t and order of them. 5.1.1 Structural Design The pattern split proto col la y er lo oks suitable for the arc hitecture of ABP In adapting the pattern, it is w orth noting that it is not clear from the requiremen ts whether the ABP la y er has an upp er la y er, whic h is an optional blo c k of the pattern, or not. If an upp er la y er exists, the upp er la y er w ould initiate a D A T A transfer. Otherwise, the ABP la y er is the upp ermost la y er and in ternally generates and consumes the D A T A. F or this example, w e supp ose that there is a user la y er of ABP that uses the messages PUT and GET to initiate and consume the D A T A. Figure 5{1 illustrates the arc hitecture of the proto col. F or the v alidation of proto col, it is necessary to get an outline of Pr omela mo del from the structural pattern. Since the mo del has to b e a closed system, w e need the en vironmen t pro cesses for the upp er and lo w er la y ers. 77

79 L TL: ( p ^ ( p q )) where p and q represen t the reception of PUT and transfer of DATA_req Prop ert y 2 The request DATA_req is alw a ys follo w ed b y either reception of ACK_ind or timeout T. L TL: ( p (( q ^ : r ) ( : q ^ r ))) where p q and r denote the transfer of DATA_req reception of ACK_ind and timeout of timer T, resp ectiv ely Prop ert y 3 Reception of DATA_ind has to o ccur ev en tually L TL: p where p means the reception of DATA_ind Prop ert y 4 If the DATA_ind is receiv ed, the indication is alw a ys follo w ed b y sending of ACK_req and GET L TL: ( p ( q ^ r )) where p q and r represen t the reception of DATA_ind transfer of ACK_req and GET resp ectiv ely Prop ert y 5 As a com bination of the sender and receiv er, the input message PUT is follo w ed b y the output message GET L TL: ( p q ) where p and q represen t the transfer of PUT and reception of GET Prop ert y 6 The messages PUT and GET m ust o ccur alternativ ely L TL: (0 ( n p n g ) 1) where n p and n g denote the n um b ers of o ccurrences of PUT and GET F rom the Pr omela mo del and the prop erties men tioned ab o v e, w e can p erform the v alidation of the initial design. During the v alidation, there is one problem at the receiv er when the mo del is c hec k ed with Prop ert y 3, or the existence of D A T A ind. Spin generates an error trace whic h sho ws that the D A T A req sen t from the sender is lost at the lo w er la y er rep eatedly without an y progress. As a solution for this problem, w e can limit the n um b er of trials of message D A T A req b y replacing the pattern timed conrmed sender with the pattern timed retrial conrmed sender. Th us, when the D A T A is

PAGE 91

80 lost more than N times consecutiv ely the sender giv es up the comm unication. As a result, w e ha v e an up dated Prop ert y 3 sa ying that reception of DATA_ind has to o ccur ev en tually Otherwise, the sender giv es up the comm unication after the N times timeout. Prop ert y 2 is also c hanged that the request DATA_req is alw a ys follo w ed b y either reception of ACK_ind or N times timeout. Another problem o ccurs at the receiv er when w e c hec k the corresp ondence of PUT and GET as in Prop ert y 6. Because of the p ossibilit y of A CK loss at the lo w er la y er, the receiv er could tak e a duplicated D A T A. The receiv er, therefore, has to c hec k the duplication of receiv ed D A T A and ignore a duplicated one although it replies the A CK again. The c hec king can b e ac hiev ed b y app ending one sequen tial bit called alternate bit to the D A T A and insp ecting the bit. The b eha vior is sp ecied b y predicates to examine the alternate bit after receiving a D A T A. After mo difying the mo del and prop erties for the problems, w e can v alidate it again. In this time, the up dated mo del passes all prop erties at the sync hronous comm unication. Nev ertheless, one more problem still remains when the la y er uses async hronous comm unication, i.e., BUFFSIZE is greater than zero. If sender receiv es a timeout signal for a D A T A, it assumes that either a previous D A T A or an A CK for the D A T A is lost at the lo w er c hannel. Th us, it sends the D A T A again. But, this assumption is not alw a ys true b ecause there is a p ossibilit y of message dela y Supp ose the sender had transferred a D A T A with setting the alternate bit zero. Then, it transferred the D A T A again after it receiv ed a timeout signal. Next, the sender receiv ed an A CK for the rst D A T A whic h had b een dela y ed. Since it receiv ed the A CK, the sender transmits the second D A T A whic h happ ens to b e lost at the lo w er c hannel. Mean while, the receiv er sends another A CK for the duplicated D A T A. Unfortunately the sender considers this A CK as an ac kno wledgmen t for the second D A T A whic h w as acciden tally lost. Hence, sender transfers third D A T A in whic h the alternate bit has zero again. The receiv er

85 of the message b y resp onding with a CALL PR OC to indicate that the call is pro ceeding w ell. Then the SETUP message is forw arded to a called part y across the net w ork. Along the w a y eac h net w ork switc h determines if it has enough resources to serv e the connection. If there is a problem within the net w ork or at the called part y the call is rejected b y returning either a REL or a REL COMP message to the calling part y When the SETUP message reac hes the called part y it ma y answ er with a CALL PR OC message to indicate that it is going to start the pro cessing of the connection. The called part y ma y send an ALER T message to imply an alerting has b egun at the called part y Note that b oth CALL PR OC and ALER T messages are optional, though w e assume that these messages exist in our case study Whether to send a CALL PR OC in resp onse to a SETUP is usually a conguration feature of the access switc h. Sending an ALER T is a feature of the end system soft w are [ 65 ]. When the called part y is ready to connect, it sends a CONN message to the calling part y bac kw ards through the net w ork. The message is answ ered with a CONN A CK. A t this p oin t, a connection is established and data can b e exc hanged. T o release the connection, whic h can b e initiated b y a calling part y or a called part y a REL message is sen t to the other side. This message includes the reason of release. The message is ac kno wledged with a REL COMP after releasing the resources allo cated. The connection release of Figure 5{5 is initiated b y the called part y In addition to the message sequence, the proto col manages timing constrain ts of messages. There are man y timers suc h as T303, T310, T301, and T308 for conrmed ac kno wledgmen ts. T ypically if a timer expires, the call to b e connected is cleared. It is imp ortan t to note that eac h side of UNI pro vides a dieren t function, and th us the signaling proto col is dened separately for an A TM end system and

87 call. The in ternal message SETUP .in t is used for this purp ose. The message mak es the MAIN CC create an instance of TERM CC to handle the terminating call. As men tioned earlier, this case study deals with UNI, and th us w e consider only a lo cal call in one A TM switc h. In other w ords, the instances of OR G CC and TERM CC exist in the same switc h. If there are man y switc hes in the net w ork and the call ro ws through the switc hes as a long distance call, the instances w ould need dieren t proto cols suc h as NNI. Note that OR G2TERM and TERM2OR G are used for the in ternal messages suc h as ALER T.in t, CONN.in t and REL.in t. These messages are represen ted in the dotted line in Figure 5{5 Note that the dierence b et w een normal messages and in ternal messages. The normal messages are transmitted through a lo w er la y er of the signaling proto col, whereas the in ternal messages are exc hanged among blo c k instances. 5.2.3 Beha vioral Design 5.2.3.1 Beha vior of MAIN CC As sho wn in Figure 5{6 MAIN CC tak es the role of administrator of the pattern split dynamic handler for the messages SETUP SETUP .in t, and TERMINA TE. It creates instances of OR G CC and TERM CC for the messages SETUP and SETUP .in t. After nishing comm unication, eac h instance informs the MAIN CC of the termination of execution using the message TERMINA TE. The S E T U P / c r e a t e O R G C C s a v e i n s t a n c e i d / S E T U P t o O R G C C m a i n w a i t S E T U P i n t / c r e a t e T E R M C C s a v e i n s t a n c e i d / S E T U P i n t t o T E R M C C m a i n w a i t T E R M I N A T E / d e l e t e i n s t a n c e i d / m a i n w a i t ( a ) ( b ) ( c ) Figure 5{7: MAIN CC as an administrator of split dynamic handler b eha vior is giv en in Figure 5{7 The whole b eha vior of MAIN CC is obtained b y

PAGE 99

88 merging the CEFSMs of Figure 5{7 through the pattern source merge at the state main wait W e can extract the prop erties of MAIN CC b eha vior from the CEFSMs. In the case of Figure 5{7 (a), the input ev en t SETUP has to b e follo w ed b y the transferring of SETUP to the newly created OR G CC. F urthermore, the t w o ev en ts ha v e to o ccur alternativ ely These prop erties are also applicable to the SETUP .in t. Then, TERMINA TE m ust follo w the corresp onding SETUP or SETUP .in t. F or example, if an OR G CC instance w as created once, it has to cease to exist sometime later in an y situations. The prop ert y could b e expressed in L TE as ( S E T U P ( T E R M I N AT E )). 5.2.3.2 Outgoing Call Establishmen t Conrmed receiv er for SETUP The blo c k OR G CC handles an outgoing call from a calling part y at the access switc h. When it receiv es a SETUP message from a calling part y it c hec ks the p ossibilit y of connection rst. If the service is p ossible in the no de, the blo c k allo cates the resources needed for the connection. Then, it ac kno wledges with a message CALL PR OC to the calling part y to indicate that the call is b eing pro cessed prop erly If the connection is failed, it replies with a REL COMP message to notify that the connection is not p ossible and b eing cleared. This b eha vior is w ell-suited for the pattern conrmed receiv er as in Figure 5{8 (a) where the SETUP is conrmed with either CALL PR OC or REL COMP Note that the corresp onding sender of the conrmed receiv er exists at the calling part y Because the b eha vior of the calling part y is not our concern, w e do not presen t it here. Ho w ev er, it is p ossible to design the b eha vior with the pattern timed retrial conrmed sender similarly as the handling of SETUP at the TERM CC whic h is giv en in the incoming call establishmen t. In addition to the comm unication with a calling part y OR G CC has to inform the MAIN CC that there is an incoming call request so that it initiates a TERM CC. This notication

90 of connection release is giv en later. F rom the pattern, w e kno w that CONN.in t has to o ccur ev en tually and CONN subsequen tly follo ws the ev en t. F urthermore, the CONN is resp onded b y one of conrmation messages. The whole b eha vior of OR G CC is obtained using the pattern sequence merge for the CEFSMs designed in Figure 5{8 The state nul l is the initial state of the merged CEFSM. Accordingly w e need to c hec k the prop erties for the nal CEFSM suc h as SETUP m ust o ccur to initiate the op eration and it has to b e follo w ed b y the reception of REL COMP REL, or CONN A CK. 5.2.3.3 Incoming Call Establishmen t Timed retrial conrmed sender for SETUP The connection establishmen t for an incoming call is p erformed b y the blo c k TERM CC. When the blo c k is notied of a new call trial b y SETUP .in t, it sends a SETUP message to the destination called part y and w aits for an ac kno wledgmen t in the timing in terv al set b y the timer T303. The blo c k tries at least t wice for a resp onse. If it receiv es CALL PR OC as an indication of successful pro ceeding, it mo v es to the next step. Ho w ev er, if a REL COMP is resp onded due to the connect rejection, the blo c k resets the timer and clears the call. If the blo c k fails to receiv e an y ac kno wledgmen t in t w o trials, it recognizes this situation as a failure of the request and clears the connection. All b eha vior to handle the SETUP can b e designed b y the pattern timed retrial conrmed sender as sho wn in Figure 5{9 Mean while, the corresp onding called part y uses the pattern conrmed receiv er to handle the message, whic h is similar to the case of SETUP at OR G CC as in Figure 5{8 (a). F rom the pattern, it is p ossible to capture the prop erties of TERM CC suc h as the input ev en t SETUP .in t has to b e follo w ed b y one subsequen t input among CALL PR OC, REL COMP and T303 timeout. Note that T303 cannot happ en more than t wice. Timed receiv er for ALER T. As sho wn in Figure 5{5 an access switc h w aits for an alerting signal ALER T in a timing in terv al set b y T310 after receiving

94 chan TERM2MAIN= [BUFFSIZE] of {mtype, Para}; chan MAIN2TERM= [BUFFSIZE] of {mtype, Para}; chan ORG2TERM = [BUFFSIZE] of {mtype, Para}; chan TERM2ORG = [BUFFSIZE] of {mtype, Para}; chan UNI2ORG = [BUFFSIZE] of {mtype, Para}; chan UNI2TERM = [BUFFSIZE] of {mtype, Para}; chan ORG2UNI = [BUFFSIZE] of {mtype, Para}; chan TERM2UNI = [BUFFSIZE] of {mtype, Para}; /* process declaration */ proctype MAIN_CC() {} proctype ORG_CC() {} proctype TERM_CC() {} proctype Calling_Party() {} /* environment process */ proctype Called_Party() {} /* environment process */ init {} /* initialization process */ The sp ecial pro cess init instan tiates the initial pro cesses of the mo del b y using the run op erator. In this case study the static instance of MAIN CC is created from the pro cess. F or the closeness of the mo del, it is necessary to include a calling part y and a called part y for in teraction with the OR G CC and TERM CC. Th us, w e ha v e t w o en vironmen ts pro cesses, Calling Party and Called Party F rom the mo del outline, w e can acquire a complete Pr omela mo del b y con v erting all CEFSMs dra wn in design phase to the corresp onding Pr omela constructs. App endix B presen ts the complete mo del of the design. 5.2.4.2 Result and Exp erience Deadlo c k and unreac hed co de. As a t ypical pro cedure of Spin v alidation, w e rst c hec k the p ossibilit y of a deadlo c k and the existence of unreac hed co de. One deadlo c k situation happ ens when b oth parties initiate the release of connection at the same time. F or instance, when an instance of OR G CC or TERM CC w aits for a REL COMP from its lo cal end part y it could receiv e a REL instead of REL COMP That is, at the state r ele ase indic ation of Figure 5{11 (b), an instance ha v e requested a connection release to the end part y up on receiving a REL.in t from a remote p eer. Ho w ev er, the end part y has also requested the connection release at the same time. This situation is called a cle ar c ol lision [ 65 ], and w e ha v e not considered this situation at the design phase. W e can solv e it b y in tro ducing one

PAGE 106

95 more transition REL/-/TERMINA TE from the state r ele ase indic ation Another clear collision exists when eac h instances receiv es a REL from its lo cal part y and then transfers it to the p eer using REL.in t. The p eer part y can also send the REL.in t at the same time. This is solv ed b y c hec king and consuming a p ending REL.in t from a p eer b efore and after sending its REL.in t. Another situation of deadlo c k happ ens when b oth parties w ait for a request of connection release from the other part y forev er. T o x the problem, w e c hange the end parties of the mo del so that at least one of them b egins the disconnection. The third situation of deadlo c k o ccurs at the OR G CC blo c k b ecause it do es not pro vide the handling of abnormal connection release request during the connection establishmen t. It is p ossible for an instance of TERM CC to notify the connection failure due to the expiration of timer T310 or T301. The reason for this deadlo c k is that w e missed the handling of the connection failure at the design phase. Spin pinp oin ts the p oten tial deadlo c k exactly The situation is xed b y adding a transition to handle REL.in t at the states outc al l pr o c e e d and c al l deliver e d Iden tication of unreac hable co de is imp ortan t in the system v alidation b ecause the unreac hed co de could ha v e a p oten tial fault. In our case, some Pr omela co de has not reac hed b ecause w e ha v e not fully sim ulated the message loss in the en vironmen t pro cesses. Prop ert y v alidation. After Spin has xed ob vious design ra ws suc h as system deadlo c k and unreac hable co de, the system mo del is v alidated against system prop erties. F rom the patterns used in the design, w e can obtain sev eral prop erties of the A TM UNI signaling proto col as follo w. Prop ert y 1 The input message SETUP has to o ccur ev en tually and it is follo w ed b y the transferring of SETUP to the newly created OR G CC. L TL: S E T U P ^ ( S E T U P ( SETUP to OR G CC )).

98 Prop ert y 17 The input ev en t R E L:int has to o ccur ev en tually and b e resp onded b y REL. L TL: ( R E L:int ^ ( R E L:int R E L )). Prop ert y 18 REL is follo w ed b y either REL COMP or t w o times timeout of T308.L TL: ( R E L ((( T 308 ^ ( c = 2)) ^ : REL COMP ) ( : ( T 308 ^ ( c = 2)) ^ REL COMP ))), where c denotes the n um b er of timeout. Prop ert y 19 After second timeouts, no timeout T308 exists. L TL: ( c 2), where c denotes the n um b er of timeout. Most of the prop erties are satised in the v alidation. One problem is at the prop ert y 2 in whic h an existence of SETUP .in t at the TERM CC is c hec k ed. The reception can not b e p ossible if OR G CC rejects the SETUP request con tin uously Th us, it is necessary to a v oid this situation at the proto col design. It it imp ortan t to note that the prop erties used in this v alidation phase are not only for the v alidation of the design, but also for later dev elopmen t phases. They can b e used, for instance, when an in tegration testing of a whole system is p erformed including the en vironmen t blo c ks of the mo del. These are, therefore, a v aluable do cumen t for the system main tenance. State explosion in m ultiple instances. A t the initial v alidation, w e ha v e v alidated the mo del with one pair of handlers. In other w ords, there w ere one calling part y and one called part y in the mo del. F or the v alidation of proto col with m ultiple handlers, w e increase the n um b er of caller and callee instances. In this situation, w e realized that it is necessary to iden tify the address of eac h instance for prop er comm unication. Additionally the v alidation has reac hed the default memory limitation (64M) immediately Th us, w e need to use compression and a sup ertrace tec hnique as w ell as increase the memory

PAGE 110

CHAPTER 6 CONCLUSION A pattern is a p o w erful artifact for design reuse. It describ es a solution to a problem that recurs sev eral times in similar situations. In this dissertation, w e, rst, suggested a comm unication pattern language for the high-lev el description of comm unication proto cols. Our pattern language is comp osed of structural and b eha vioral patterns. One feature of the pattern description is to use an STD for a CEFSM whic h mak es it easier to represen t a design in a visual notation. Finite state mac hines are commonly used in proto col description and the STD can describ e the b eha vior in states, ev en ts, and actions. Moreo v er, the STD helps to translate the design in to our v alidation language Pr omela systematically Another feature of the pattern language is that the patterns include the SDL implemen tation section whic h assists a dev elop er with usage of the patterns in applications to b e implemen ted in the language. F urthermore, our pattern language has a hierarc hical and expandable pattern framew ork. High-lev el patterns can b e constructed from elemen tary patterns. It is also p ossible to mak e patterns for other domains from the framew ork. Second, w e prop osed a soft w are dev elopmen t metho dology for a comm unication proto col system emphasizing the high-lev el design of a system and the v alidation of that design using a mo del c hec king tec hnique. When a system designer dev elops a proto col, patterns are used for the abstract description of the proto col. The designer is able to devise an arc hitecture of the proto col system with structural patterns. Then, the in teractions of messages among the arc hitectural blo c ks are represen ted with b eha vioral patterns. The system design description 99

PAGE 111

100 acquired at the design step is a go o d main tenance do cumen t for a proto col system. After the pattern-based design, a v alidation on the design is conducted on a Pr omela mo del of the design. The v alidation helps to nd design faults in the early stages of the dev elopmen t. Third, the v alidation using a mo del c hec k er w as describ ed in detail. F or the v alidation of a pattern-based design, it is necessary to construct a v alidation mo del and iden tify the system prop erties. Chec king the correctness and consistency of a design is ac hiev ed b y Spin and Pr omela A Pr omela mo del can b e obtained systematically from the patterns used in the design. Sp ecial atten tion is necessary for the comm unication paths, timer, and en vironmen t pro cesses. One of our con tributions is to presen t the prop erties in the prop ert y sp ecication section in pattern description. As a result, a designer can ensure sev eral correctness prop erties suc h as ev en t o ccurrence, ordering among the ev en ts, corresp ondence or alternativ eness of ev en ts during the design phase. Although the formal v alidation pro vides designers signican t adv an tages, it has not b een widely used in industry b ecause of some practical barriers suc h as dicult y of formal descriptions of system prop erties. The patterns enable non-exp erts to obtain the correctness prop erties from the pattern description. F ourth, to sho w the feasibilit y of our metho dology w e ha v e p erformed sev eral case studies suc h as the alternate bit proto col and A TM UNI signaling proto col. These case studies pro vide a pro of of concept for the usefulness of the pattern language and v alidation tec hnique. W e w ere also able to mine the designs to obtain additional high lev el patterns. Although our metho dology pro vides useful supp ort for proto col dev elopmen t, there are sev eral issues to b e addressed in the future. A pattern language is not a closed set. Our pattern language could b e enhanced b y the addition of more high-lev el patterns. W e can extend the language b y either comp osing the patterns

PAGE 112

101 or sp ecializing the existing ones as w ell as dev eloping new ones. The framew ork of the pattern language will b e v alid for further pattern dev elopmen t. T o ol supp ort is necessary to mak e it p ossible to pro vide automatic creation, selection, and adaptation of patterns. The translation of patterns in to Pr omela co de is also essen tial. F or the to ol supp ort, the concrete syn tax and seman tics for the pattern language need to b e dened. Our approac h to mo del the timer and its op erations pro vides an appro ximate solution to rerect elapsed time in the mo del. In fact, it is a limitation of the curren t Spin v ersion and not trivial to pro vide a concrete solution without c hanging of Spin 's in ternals. As a complemen t to Spin w e can in v estigate other to ols suc h as Upp aal and Kr onos for the design v alidation. As an another approac h, it w ould b e p ossible to represen t our STD in a common represen tation IF [ 89 ]. Th us, w e could use man y to ols that supp ort the format. In this researc h w ork, w e presen ted a pattern language for the high-lev el description of comm unication proto cols and suggested a v alidation mec hanism for the description to nd design error at the early dev elopmen t phase. The system design description will b e a useful main tenance do cumen tation after the dev elopmen t of a proto col b ecause it can sho w the abstract arc hitecture and b eha vior of the proto col in a few patterns. W e also b eliev e that the patterns are applicable to other comm unication areas. Comm unicating blo c ks and nite state mac hines are w ell-kno wn means to describ e these applications.