<%BANNER%>

Pattern-Based Design and Validation of Communication Protocols


PAGE 1

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

PAGE 2

Cop yrigh t 2003 b y Y oung jo on Byun

PAGE 3

T o m y family

PAGE 4

A CKNO WLEDGMENTS I w ould lik e to express m y sincere gratitude to m y advisor, Dr. Bev erly A. Sanders, for her excellen t advice and adv o cacy during the course of this w ork. I w ould also lik e to thank the mem b ers of m y committee, Dr. Jonathan C. Liu, Dr. Stev e M. Thebaut, Dr. Joseph N. Wilson and Dr. Mark C. K. Y ang, for their revision of this w ork and their v aluable suggestions. I am indebted to Dr. Y ann-Hang Lee for his v aluable guidance during the course of m y Ph.D. program. My appreciation and sp ecial thanks go to Dr. Byung Sun Lee, Mr. Chang-Sup Keum and Ms. Ki-So ok Ch ung for the kind commen ts on the case study presen ted in this dissertation. Finally I wish to thank m y wife Y ounji for her supp ort and understanding during all these y ears. iv

PAGE 5

T ABLE OF CONTENTS page A CKNO WLEDGMENTS . . . . . . . . . . . . . . iv LIST OF T ABLES . . . . . . . . . . . . . . . . vii LIST OF FIGURES . . . . . . . . . . . . . . . . viii ABSTRA CT . . . . . . . . . . . . . . . . . . x CHAPTER1 INTR ODUCTION . . . . . . . . . . . . . . . 1 1.1 P attern-based Dev elopmen t Metho dology . . . . . . . 2 1.2 P attern Language Ov erview . . . . . . . . . . 5 1.3 Organization of P atterns . . . . . . . . . . . 7 2 RELA TED W ORK . . . . . . . . . . . . . . . 10 2.1 P atterns in Comm unication Systems . . . . . . . . 10 2.2 Mo del Chec king using Spin and Pr omela . . . . . . 13 2.3 In tro duction to SDL and Mo del Chec king SDL System . . . 18 3 P A TTERN LANGUA GE F OR COMMUNICA TION PR OTOCOLS . 22 3.1 Structural P atterns . . . . . . . . . . . . . 22 3.1.1 Proto col La y er . . . . . . . . . . . . 22 3.1.2 Mux . . . . . . . . . . . . . . . 26 3.1.3 Dynamic Handler . . . . . . . . . . . 27 3.2 Beha vioral P atterns . . . . . . . . . . . . . 32 3.2.1 Comm unicating Extended Finite State Mac hine . . . 32 3.2.2 Timer . . . . . . . . . . . . . . . 47 3.2.3 Rep eated Ev en ts . . . . . . . . . . . . 49 3.2.4 Message T ransfer . . . . . . . . . . . 55 4 MODEL CHECKING P A TTERN-BASED DESIGN . . . . . . 65 4.1 Mo deling P attern-Based Design in Pr omela . . . . . . 65 4.1.1 Mo del Construction from P atterns . . . . . . . 66 4.1.2 Comm unication P ath and Channel Capacit y . . . . 68 4.1.3 Timer Handling . . . . . . . . . . . . 70 4.1.4 En vironmen t Pro cess . . . . . . . . . . 73 v

PAGE 6

4.2 Prop ert y Sp ecication . . . . . . . . . . . . 73 4.2.1 Linear T emp oral Logic . . . . . . . . . . 74 4.2.2 Prop ert y Extraction from Comm unication P atterns . . 75 5 CASE STUDIES . . . . . . . . . . . . . . . 77 5.1 Case Study: Alternate Bit Proto col . . . . . . . . 77 5.1.1 Structural Design . . . . . . . . . . . 77 5.1.2 Beha vioral Design . . . . . . . . . . . 78 5.2 Case Study: A TM UNI Signaling Proto col . . . . . . 82 5.2.1 Proto col Ov erview . . . . . . . . . . . 82 5.2.2 Structural Design . . . . . . . . . . . 86 5.2.3 Beha vioral Design . . . . . . . . . . . 87 5.2.4 V alidation of P attern-based Design . . . . . . . 93 6 CONCLUSION . . . . . . . . . . . . . . . . 99 APPENDIX . . . . . . . . . . . . . . . . . . 102 A MODELING OF AL TERNA TE BIT PR OTOCOL IN PR OMELA . . 102 B MODELING OF A TM UNI SIGNALING PR OTOCOL IN PR OMELA 106 REFERENCES . . . . . . . . . . . . . . . . . 117 BIOGRAPHICAL SKETCH . . . . . . . . . . . . . . 124 vi

PAGE 7

LIST OF T ABLES T able page 1{1 P attern language for comm unication proto cols . . . . . . 5 4{1 Eect of c hannel capabilit y on memory and CPU for ABP . . . 69 vii

PAGE 8

LIST OF FIGURES Figure page 1{1 Ov erview of pattern-based design and v alidation . . . . . . 2 1{2 Organization of pattern language . . . . . . . . . . 7 3{1 A structure of pattern proto col la y er . . . . . . . . . 23 3{2 A structure of pattern split proto col la y er . . . . . . . . 23 3{3 SDL implemen tation of pattern proto col la y er . . . . . . 24 3{4 Example of pattern proto col la y er in SSCF at UNI . . . . . 25 3{5 Structure of ABP using split proto col la y er . . . . . . . 26 3{6 A structure of pattern m ux . . . . . . . . . . . . 27 3{7 SDL implemen tation of pattern m ux . . . . . . . . . 27 3{8 A structure of pattern dynamic handler . . . . . . . . 29 3{9 A structure of pattern split dynamic handler . . . . . . . 30 3{10 SDL implemen tation of pattern dynamic handler . . . . . . 31 3{11 A le transfer serv er using pattern dynamic handler . . . . . 31 3{12 A call con trol blo c k using pattern split dynamic handler . . . . 32 3{13 An example CEFSM represen ted in STD . . . . . . . . 35 3{14 P attern basic CEFSM . . . . . . . . . . . . . 36 3{15 P attern predicate CEFSM . . . . . . . . . . . . 39 3{16 P attern predicate after action . . . . . . . . . . . 40 3{17 Merge patterns com bined from t w o CEFSMs . . . . . . . 41 3{18 SDL fragmen t for pattern basic CEFSM . . . . . . . . 43 3{19 SDL fragmen t for pattern predicate CEFSM . . . . . . . 44 3{20 Example of pattern predicate after action for error detection . . 44 3{21 Example of merge patterns . . . . . . . . . . . . 45 viii

PAGE 9

3{22 P attern timer with the exp ected ev en t e . . . . . . . . 48 3{23 SDL fragmen t for pattern timer . . . . . . . . . . 49 3{24 P attern rep eated ev en ts and its SDL implemen tation . . . . 50 3{25 P attern timed rep eated ev en ts and its SDL implemen tation . . . 52 3{26 P attern timed retrial and its SDL implemen tation . . . . . 53 3{27 Nine-digit dialing using pattern rep eated ev en ts . . . . . . 54 3{28 Proto col la y er as a service pro vider . . . . . . . . . 56 3{29 P atterns unconrmed sender and unconrmed receiv er . . . . 56 3{30 P attern conrmed sender and its example on an SNMP clien t . . 58 3{31 P attern conrmed receiv er in three common cases . . . . . 60 3{32 P atterns timed receiv er and timed retrial receiv er . . . . . 61 3{33 P atterns timed conrmed sender and timed retrial conrmed sender 63 4{1 Mo del c hec king pattern-based system using Spin . . . . . . 65 4{2 Nine-digit dialing in call setup . . . . . . . . . . . 66 5{1 Structure of ABP using split proto col la y er . . . . . . . 78 5{2 Initial description of ABP b eha vior . . . . . . . . . 78 5{3 Final description of ABP b eha vior . . . . . . . . . . 81 5{4 Proto col stac k for signaling in A TM con trol plane . . . . . 82 5{5 Message ro w for connection establishmen t and release . . . . 84 5{6 Arc hitecture of connection con trol blo c k using split dynamic handler 86 5{7 MAIN CC as an administrator of split dynamic handler . . . . 87 5{8 Beha vior of OR G CC for SETUP ALER T, and CONN . . . . 89 5{9 Beha vior of TERM CC for SETUP message . . . . . . . 91 5{10 Beha vior of TERM CC for ALER T and CONN . . . . . . 91 5{11 Call clearing for an A TM connection . . . . . . . . . 92 ix

PAGE 10

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

PAGE 13

2 W e suggest a v alidation tec hnique for a design sp ecication dev elop ed from our patterns. Moreo v er, the prop ert y description in eac h pattern enables designers to capture the system requiremen ts to b e c hec k ed after the design. In summary w e suggest a pattern-based dev elopmen t metho dology for comm unication proto cols whic h aims to supp ort high-lev el design and v alidation of proto cols in the early dev elopmen t phase. 1.1 P attern-based Dev elopmen t Metho dology The classic life-cycle of soft w are engineering is comp osed of sev eral phases suc h as requiremen ts analysis, design, co ding, testing, and main tenance [ 5 6 ]. Our concern lies in the initial design phase for the high-lev el description of a system and its v alidation. Designers in that phase t ypically w an t to capture R e f i n e m e n t a n d F u r t h e r D e v e l o p m e n t s M o d e l i n g i n P R O M E L A R e q u i r e m e n t s P a t t e r n R e p o s i t o r y S P I N f a i l p a s s P a t t e r n b a s e d H i g h l e v e l D e s i g n S y s t e m D e s i g n D e s c r i p t i o n Figure 1{1: Ov erview of pattern-based design and v alidation the essen tial functions rst; for example, ro ws of messages and in teractions with other systems. Then, they build an abstract system b efore the detailed

PAGE 14

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

PAGE 16

5 can b e obtained at the design phase. The prop erties include the o ccurrence of message arriv al, ordering in the message in teraction, and corresp ondence or alternativ eness of messages. If the v alidation fails, it is necessary to nd the reason and x the problem. Then, w e return to the design step or v alidation step. Otherwise, renemen t and further dev elopmen t follo w. In this dissertation, w e sho w the implemen tation of a pattern in SDL (Sp ecication and Description Language). SDL is a formal description language for comm unicating systems recommended b y ITU (In ternational T elecomm unication Union) [ 12 ] and is b ecoming p opular in design and implemen tation of comm unication proto cols [ 13 14 ]. 1.2 P attern Language Ov erview P atterns are rarely standalone. Instead, sev eral related patterns are t ypically used to solv e problems in a sp ecic domain. T able 1{1 presen ts our pattern language to b e used for comm unication proto cols. Detailed description of eac h pattern T able 1{1: P attern language for comm unication proto cols Category P atterns V arian ts or Sp ecialization proto col la y er split proto col la y er structural m ux dynamic handler split dynamic handler predicate CEFSM basic CEFSM predicate after action merge patterns timer rep eated ev en ts timed rep eated ev en ts timed retrial unconrmed sender b eha vioral unconrmed receiv er conrmed sender message transfer conrmed receiv er timed receiv er timed retrial receiv er timed conrmed sender timed retrial conrmed sender

PAGE 17

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

PAGE 19

8 Figure 1{2 sho ws the organization of our patterns. Note that the b eha vioral patterns ha v e an expandable hierarc hical structure. The pattern basic CEFSM is the foundation of b eha vioral sp ecication. It is p ossible to represen t more complex and high-lev el abstraction through merge patterns suc h as source merge, target merge, and sequen tial merge. P atterns can also b e augmen ted with the pattern timer and/or rep eated ev en ts to con trol timing constrain ts and rep etition of ev en ts. Basic CEFSM, timer, and rep eated ev en ts are called elemen tary patterns b ecause other patterns are able to b e made from these patterns. The curren t domain of our pattern language is a comm unication proto col and our concern is concen trated on the b eha vior of message exc hanges b et w een comm unicating blo c ks. The patterns of message transfer are sp ecialization of the elemen tary patterns. F or example, the pattern basic CEFSM has a tuple ( f S s ; S t g ; S s ; f e g [ O ; f < S s ; e; S t ; A; O > g ; V ) whic h means that there are t w o states S s and S t with S s as an initial state. F or an input ev en t e the pattern mo v es to S t after p erforming action A and generating output O There is a set of v ariables V for the action. The formal denition of the pattern is giv en in Section 3.2.1 F rom the pattern, w e can in tro duce a sp ecialized ev en t indic ation instead of a general ev en t e so as to describ e a new pattern unconrmed receiv er. The indication is used to inform a receiving en tit y of the arriv al of a message for a request message from a sender. The result pattern has a tuple ( f S s ; S t g ; S s ; f indication g [ O ; f < S s ; indication; S t ; A; O > g ; V ) whic h represen ts the reception of an indication message from a p eer without needs of resp onse. F urthermore, it is also p ossible to describ e more sp ecic situations b y com bining with other patterns. F or example, b y com bing the pattern unconrmed receiv er with the pattern timer, w e can get a new pattern timed receiv er whic h is a common situation to tak e a message in timing constrain ts. F or the adaptation of patterns in a real system, patterns ha v e to b e instantiated. In other w ords, all states, messages, actions, timers, and predicates ha v e

PAGE 20

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

PAGE 25

14 b eha vior o v er time. The t w o most p opular temp oral logics are linear time temp oral logic (L TL) and computation tree logic (CTL). F ormally a mo del c hec k er v alidates whether M j = holds, where M is a mo del of a system and is a prop ert y to b e required in the system. Mo del c hec king has b een successfully used in hardw are v alidation and proto col comm unication soft w are. There are man y to ols applicable to da y suc h as Smv [ 38 ], Spin Upp aal [ 39 ], Kr onos [ 40 ], etc. W e select Spin (Simple Promela INterpreter) as our mo del c hec k er for the v alidation of pattern-based design. 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 at the Spin w eb site [ 11 ]. A system is describ ed in a mo deling language called Pr omela (PR Ocess MEta LAnguage) [ 41 ]. Giv en a system mo del sp ecied in Pr omela Spin can sim ulate the system's execution. It is also p ossible to generate a C program to p erform an exhaustiv e exploration of a system's state space using a depth-rst searc h algorithm. During the sim ulation and v alidation, Spin can c hec k for absence of deadlo c ks, non-progress cycles, unsp ecied message receptions, unexecutable co de, etc. The mo del is also pro v en the correctness of system in v arian t claims and temp oral claims expressed in next-time free L TL form ulae. If a system mo del violates a correctness prop ert y Spin recognizes this and a trace of violation is generated. T o cop e with the problem of state space explosion, Spin emplo ys sev eral tec hniques suc h as partial-order reduction, state-v ector compression, and bit-state hashing. F or the simple usage of the to ol, a graphic user in terface, Xspin, is also pro vided. Pr omela is a v alidation mo deling language for Spin fo cusing on the abstraction of message exc hange in a system [ 42 43 ]. It has C-lik e syn tax with features

PAGE 26

15 from Dijkstra's guarded commands and comm unication primitiv es from Hoare's CSP The imp ortan t constructs of a Pr omela program are pro cess, message c hannel, and v ariable. Pro cesses execute async hronously whic h means there are no assumptions on the relativ e sp eed of pro cesses and only one pro cess is executed at a particular p oin t. Eac h statemen t in a pro cess is either executable or blo c k ed. If a statemen t is blo c k ed for some reason, the statemen t halts un til it b ecomes executable. Pro cesses in teract either b y message passing via c hannels or memory sharing of global v ariables. Comm unications via message c hannels are either sync hronous (i.e., rendezv ous) or async hronous (i.e., buered). The follo wing example [ 42 ] presen ts a sample Pr omela program to sho w the basic concept of Pr omela It calculates the factorial v alue of a n um b er n at the pro cess fact returning the result through the c hannel p proctype fact(int n; chan p) { int result; if:: (n <= 1) -> p!1 :: (n >= 2) -> chan child = [1] of {int}; run fact(n-1, child); child?result;p!n*result fi }init { int result; chan child = [1] of {int}; run fact(5, child); child?result;printf("result: %d\n", result) } A pro cess is dened b y a proctype with pro cess b eha vior in it. A sp ecial pro cess init usually instan tiates other pro cesses b y using the run op erator. Channels dened b y chan are used to transfer data from one pro cess to another. The statemen t p!1 means the sending of the constan t one through the c hannel p T o receiv e a v alue or a message from the head of a c hannel, a receiv e statemen t

PAGE 27

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.

PAGE 33

CHAPTER 3 P A TTERN LANGUA GE F OR COMMUNICA TION PR OTOCOLS 3.1 Structural P atterns 3.1.1 Proto col La y er 3.1.1.1 Con text W e need to design a complex system suc h as a comm unication proto col. Some parts of the system ma y already exist. 3.1.1.2 Problem Ho w can w e describ e the structure of a comm unication proto col system? 3.1.1.3 F orces The system is to o large and complex to b e understo o d completely W e need tec hniques to help manage the complexit y Decomp osition: W e decomp ose the system in to sev eral subsystems that can b e dealt with more-or-less indep enden tly Abstraction: Eac h subsystem is treated as a blac k b o x and sp ecies the in terfaces with other subsystems. In ternal details are left for later. Reuse: Some of the subsystems ma y already b e a v ailable and th us do not need to b e designed. 3.1.1.4 Solution A comm unication proto col can b e designed in la y ers. Eac h la y er handles problems at a particular lev el of abstraction. A la y er oers services to the higher la y er and uses services from the next lo w er la y er. This structure allo ws a proto col dev elop er to design external in terfaces b efore in ternal functionalit y [ 64 9 ]. 22

PAGE 34

23 First, w e iden tify the blo c ks b elonging to a la y er and determine the comm unication paths b et w een the adjacen t la y ers. The la y ers and comm unication paths are logical ob jects that ma y or ma y not corresp ond directly to ph ysical comp onen ts of net w ork or comm unication links. Second, w e address the messages b et w een la y ers and asso ciate the messages with the comm unication paths. The comm unication paths sho w the list of message t yp es that can b e sen t on the path and the direction of the message ro w. Figure 3{1 sho ws a proto col la y er that includes one blo c k, four comm unication P r o t o c o l L a y e r u p p e r l a y e r l o w e r l a y e r p 1 p 2 p 3 p 4 m e s s a g e s = l i s t a l l m e s s a g e s u s e d i n t h e p a t t e r n ; p a t h s = p 1 : m e s s a g e s p a s s i n g t h r o u g h p 1 ; p 2 : m e s s a g e s p a s s i n g t h r o u g h p 2 ; p 3 : m e s s a g e s p a s s i n g t h r o u g h p 3 ; p 4 : m e s s a g e s p a s s i n g t h r o u g h p 4 ; Figure 3{1: A structure of pattern proto col la y er paths, a message list, and the adjacen t la y ers. The in ternal b eha vior of the proto col la y er blo c k can b e designed using other patterns of this pattern language. 3.1.1.5 V arian t: split proto col la y er Often, a comm unication la y er can b e conceptually split in to t w o related functions suc h as sending and receiving for message transfer [ 65 ]. It ma y b e helpful for the designer to consider the t w o functions separately Figure 3{2 sho ws a O u t g o i n g u p p e r l a y e r l o w e r l a y e r I n c o m i n g p 1 p 2 m e s s a g e s = l i s t a l l m e s s a g e s u s e d i n t h e p a t t e r n ; p a t h s = p 1 : m e s s a g e s p a s s i n g t h r o u g h p 1 ; p 2 : m e s s a g e s p a s s i n g t h r o u g h p 2 ; p 3 : m e s s a g e s p a s s i n g t h r o u g h p 3 ; p 4 : m e s s a g e s p a s s i n g t h r o u g h p 4 ; … p 5 p 6 p 3 p 4 p 7 p 8 Figure 3{2: A structure of pattern split proto col la y er

PAGE 35

24 structure of the pattern split proto col la y er where the Outgoing blo c k initiates a comm unication requested from the upp er la y er and the Inc oming blo c k handles messages coming from the lo w er la y er. 3.1.1.6 Implemen tation The SDL implemen tation can b e obtained directly from the design. SDL has t w o constructs to describ e a system structure: SDL blo c ks and SDL pro cesses. SDL blo c ks are pure structuring mec hanisms that ma y con tain other blo c ks and pro cesses while SDL pro cesses con tain the sp ecication of b eha vior. T ypically the non-leaf blo c ks of the structural patterns are mapp ed to SDL blo c ks and the comm unication paths b et w een them are mapp ed to SDL c hannels. Tw o t yp es of c hannels are p ossible in SDL. One is a dela ying c hannel and another is a non-dela ying c hannel. The selection of the c hannel is dep enden t on the situation. Leaf blo c ks are mapp ed to SDL pro cesses. In this case, the comm unication paths are mapp ed to signal routes whic h connect pro cesses to other pro cesses and to the c hannels of their con taining blo c k. Messages ro wing on comm unication paths that are mapp ed to c hannels or signal routes are called signals in SDL. B L O C K L a y e r P r o t o c o l L a y e r S I G N A L m s g 1 m s g 2 m s g 3 m s g 4 … ; [ m s g 1 … ] c 1 c 2 [ m s g 2 … ] [ m s g 3 … ] c 3 c 4 [ m s g 4 … ] Figure 3{3: SDL implemen tation of pattern proto col la y er Figure 3{3 sho ws an implemen tation of the pattern proto col la y er of Figure 3{1 The Pr oto c ol L ayer of Figure 3{1 is mapp ed to an SDL blo c k Pr otoc ol L ayer Eac h comm unication path is con v erted to a dela ying c hannel suc h as c 1 c 2 c 3 and c 4 The signals corresp ond to the messages ro wing through the c hannel.

PAGE 36

25 3.1.1.7 Examples The example sho ws a part of the Service Sp ecic Co ordination F unction (SSCF) for the User-Net w ork In terface (UNI) in the A TM signaling system [ 66 ]. The SSCF UNI la y er pro vides a mapping function b et w een UNI Signaling la y er and Service Sp ecic Connection Orien ted Proto col (SSCOP) la y er. The basic structure of SSCF UNI is an example of the pattern proto col la y er as Figure 3{4 M E S S A G E S = A A L E S T r e q A A L E S T i n d A A L E S T c o n f A A L R E L r e q A A L R E L i n d A A L R E L c o n f A A L D A T A r e q A A L D A T A i n d A A E S T r e q A A E S T r e s p A A E S T i n d A A E S T c o n f A A R E L r e q A A R E L i n d A A R E L c o n f A A D A T A r e q A A D A T A i n d ; S S C O P 2 S S C F S S C F 2 S S C O P U N I 2 S S C F S S C F 2 U N I P A T H S = U N I I 2 S S C F : A A L E S T r e q A A L R E L r e q A A L D A T A r e q ; S S C F 2 U N I : A A L E S T i n d A A L E S T c o n f A A L R E L i n d A A L R E L c o n f A A L D A T A i n d ; S S C F 2 S S C O P : A A E S T r e q A A E S T r e s p A A R E L r e q A A D A T A r e q ; S S C O P 2 S S C F : A A E S T i n d A A E S T c o n f A A R E L i n d A A R E L c o n f A A D A T A i n d ; U N I S i g n a l i n g S S C F U N I S S C O P Figure 3{4: Example of pattern proto col la y er in SSCF at UNI Three kinds of messages suc h as AAL EST AAL REL and AAL D A T A are exc hanged with the upp er la y er through the comm unication paths UNI2SSCF and SSCF2UNI AAL EST is used to establish a connection from the UNI signaling la y er in the form of a request and a conrmation suc h as AAL EST.r e q and AAL EST.c onf It also informs the upp er la y er that an incoming connection has b een established b y an indication message AAL EST.ind AAL REL is used to release the connection established. AAL D A T A is used b y the upp er la y er to send a data pac k et in a request form AAL D A T A.r e q SSCF UNI hands out a receiv ed pac k et to its user in an indication form suc h as AAL D A T A.ind The lo w er in terface has similar messages whic h uses the comm unication paths SSCF2SSCOP and SSCOP2SSCF As an example of the pattern split proto col la y er, w e demonstrates a v ariation of alternating bit proto col (ABP) [ 67 ] whic h pro vides simple but reliable message

PAGE 37

26 transfer on a lossy lo w er la y er. Figure 3{5 illustrates the arc hitecture of the m e s s a g e s = p u t g e t d a t a r e q d a t a i n d a c k r e q a c k i n d ; p a t h s = u p 2 s n d : p u t ; r c v 2 u p : g e t ; s n d 2 l o : d a t a r e q ; l o 2 r c v : d a t a i n d ; r c v 2 l o : a c k r e q ; l o 2 s n d : a c k i n d ; s e n d e r u p p e r l a y e r l o w e r l a y e r u p 2 s n d s n d 2 l o l o 2 s n d r e c e i v e r r c v 2 u p r c v 2 l o l o 2 r c v Figure 3{5: Structure of ABP using split proto col la y er proto col. The upp er in terface uses t w o messages put and get for a reliable data transmission. The lo w er in terface uses messages data r e q data ind ack r e q and ack ind to send and ac kno wledge messages, allo wing for retransmission if necessary to deal with message loss. 3.1.1.8 See also La y ers [ 1 ], P attern Half Ob ject + Proto col [ 68 ], Proto col Conduit [ 26 ], Service Arc hitecture [ 23 ], Service Pro vider Renemen t [ 23 ], SDL and La y ered Systems [ 69 ] 3.1.2 Mux 3.1.2.1 Con text In a la y ered design, there ma y b e m ultiple blo c ks in an adjacen t la y er and resolving the destination or source of the messages is required. 3.1.2.2 Problem Ho w can w e resolv e the destination or source of a message? 3.1.2.3 Solution Use a table to map an instance of a blo c k to its address. Figure 3{6 describ es the structure of a m ux la y er where the upp er la y er has sev eral blo c ks, while the lo w er la y er has one blo c k. Similarly the pattern is applicable to the rev erse situation.

PAGE 38

27 M u x B l o c k u p p e r b l o c k 2 l o w e r b l o c k u p p e r b l o c k 1 … … n a m e i n s t a n c e a d d r e s s p 1 p 2 p 5 p 6 m e s s a g e s = l i s t a l l m e s s a g e s u s e d i n t h e p a t t e r n ; p a t h s = p 1 : m e s s a g e s p a s s i n g t h r o u g h p 1 ; p 2 : m e s s a g e s p a s s i n g t h r o u g h p 2 ; p 3 p 4 Figure 3{6: A structure of pattern m ux 3.1.2.4 Implemen tation Figure 3{7 sho ws an implemen tation of the pattern m ux where the Mux Blo ck is an SDL pro cess, and comm unication paths suc h as r 1 r 2 r 3 are signal routes. The pro cess arra y Mux T able sho ws a trivial implemen tation of the address resolution. It stores ev ery instance iden tier, PID with the k ey name The signals en umerate the messages ro wing through the signal routes. Note that the signal routes of the upp er in terface are joined in one p oin t to b e connected with the outside c hannel. B L O C K M u x L a y e r M u x B l o c k [ m s g 1 ] r 1 r 2 [ m s g 2 ] [ m s g 5 ] r 5 r 6 [ m s g 6 ] N E W T Y P E M u x T a b l e A R R A Y ( n a m e P I D ) E N D N E W T Y P E ; S Y N T Y P E n a m e c h a r s t r i n g s ; [ m s g 3 ] r 3 r 4 [ m s g 4 ] S I G N A L m s g 1 m s g 2 m s g 3 m s g 4 ; Figure 3{7: SDL implemen tation of pattern m ux 3.1.2.5 See also m ux conduit [ 26 ] 3.1.3 Dynamic Handler 3.1.3.1 Con text A blo c k needs to handle m ultiple comm unications at the same time. The exp ected load will b e v ariable and the system is appropriately sized to handle it.

PAGE 39

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

PAGE 40

29 load is v ariable. Hybrid approac hes com bining asp ects of static and dynamic handling are also p ossible. 3.1.3.4 Solution The con text of this pattern leads us to c ho ose a dynamic approac h. The solution utilizes a single instance of a static blo c k, A dmin (an example of the Singleton P attern [ 2 ]) whic h is created at system startup time. The instance w aits for a comm unication request message from adjacen t la y ers. Up on arriv al of the request message, A dmin serv es as a factory [ 2 ] and dynamically creates an instance of the blo c k Hand ler The Hand ler instance then services that comm unication. After the comm unication has b een serviced, the instance is terminated. The maximal n um b er of instances of Hand ler that can b e created is b ounded b y a xed n um b er N If there are more requests than N A dmin m ust either queue the message, or more t ypically reject the request. N is determined empirically or b y p erformance analysis using the exp ected load on the system. H a n d l e r ( 0 N ) A d m i n ( 1 1 ) p 1 p 3 p 4 p 5 p 6 p 7 p 8 p 9 m e s s a g e s = a l l m e s s a g e s u s e d i n t h e p a t t e r n ; p a t h s = p 1 : m e s s a g e s f o r p 1 ; p 2 : m e s s a g e s f o r p 2 ; p 3 : m e s s a g e s f o r p 3 ; p 2 Figure 3{8: A structure of pattern dynamic handler Figure 3{8 sho ws a structure of the pattern. First, the en tit y A dmin w aits for a request through the comm unication paths either p 2 or p 6 Up on receiving a message, for instance msg2 through p 2 the A dmin creates an instance of Hand ler blo c k giving the necessary information for comm unication, for instance, the address of the requester. The dotted line from A dmin to Hand ler means the creation of an instance. After b eing created, the instance starts comm unication through the paths p 3 p 4 p 8 and p 9 When the comm unication ends, the Hand ler instance informs

PAGE 41

30 the A dmin of termination of service b y sending, for example, a message msg5 and ceases to exist. 3.1.3.5 V arian t: split dynamic handler The pattern dynamic handler considers only one t yp e of handler. In comm unication systems, ho w ev er, it is common to ha v e handlers in pairs suc h as the pattern split proto col la y er. Figure 3{9 describ es a dynamic creation of t w o t yp e handlers, I n c o m i n g H a n d l e r ( 0 N ) O u t g o i n g H a n d l e r ( 0 N ) A d m i n ( 1 1 ) p 8 p 7 p 3 p 5 p 6 m e s s a g e s a n d p a t h s d e c l a r a t i o n p 4 p 1 p 2 p 1 1 p 1 3 p 1 4 p 1 2 p 9 p 1 0 Figure 3{9: A structure of pattern split dynamic handler Outgoing Hand ler and Inc oming Hand ler The blo c k A dmin creates one of them dep ending on the t yp e of a request. All other b eha vior is similar to the pattern dynamic hand ler Note that the t w o handlers ma y need in ternal comm unication b et w een them. 3.1.3.6 Implemen tation F or the implemen tation of pattern dynamic hand ler dev elop ers m ust consider b oth the structure and the b eha vior of the blo c ks in the pattern. Figure 3{10 sho ws the structure of the pattern where t w o pro cesses, A dmin and Hand ler exist with the initial and maxim um n um b er of instances. The pro cess A dmin has one instance during its life span, while the pro cess t yp e Hand ler has no instance at startup time and can ha v e the maxim um N instances. The pro cesses are connected to the b oundary of the blo c k with signal routes whic h will in teract with outside c hannels. The b eha vior of the pattern needs the creation and termination of an SDL pro cess instance.

PAGE 42

31 B L O C K D y n a m i c H a n d l e r [ ] A d m i n ( 1 1 ) H a n d l e r ( 0 N ) [ ] r 1 r 5 [ ] r 2 [ ] r 3 [ ] r 4 [ ] r 6 [ ] r 8 [ ] r 7 [ ] r 9 S I G N A L m s g 1 m s g 2 m s g 3 m s g 4 ; Figure 3{10: SDL implemen tation of pattern dynamic handler 3.1.3.7 Examples Figure 3{11 sho ws a simplied le transfer serv er using the pattern dynamic hand ler In this example, w e do not presen t the in terface with the lo w er la y er for simplicit y The serv er is comp osed of a blo c k FTP A dmin and a blo c k FTP Hand ler When a user tries to do wnload a le, an ev en t FTP c onne ct go es to the blo c k FTP A dmin indicating a le transfer trial. The blo c k creates an instance of FTP Hand ler to mak e it p ossible for the user to do wnload a le from the serv er. The instance sends a message FTP c onne ct ok to indicate that it is ready to receiv e a command. F or the command get with a le name w an ted, the FTP Hand ler pro vides the requested le with the message suc c ess After getting the le, the user sends a disc onne ct message whic h mak es the instance stop after sending the message terminate to the FTP A dmin m e s s a g e s = F T P c o n n e c t F T P c o n n e c t o k t e r m i n a t e d i s c o n n e c t g e t ( f i l e n a m e ) s u c c e s s ( f i l e ) ; p a t h s = p 1 : F T P c o n n e c t ; p 2 : t e r m i n a t e ; p 3 : F T P c o n n e c t o k s u c c e s s ( f i l e ) ; p 4 : g e t ( f i l e n a m e ) d i s c o n n e c t ; F T P H a n d l e r ( 0 N ) F T P A d m i n ( 1 1 ) p 3 p 4 p 2 p 1 Figure 3{11: A le transfer serv er using pattern dynamic handler As an example of split dynamic handler, Figure 3{12 sho ws a simplied v ersion of call con trol blo c k comp osed of Cal l A dmin Outgoing Hand ler and Inc oming Hand ler in a switc hing system. When a calling part y tries a call, a

PAGE 43

32 message H init go es to the blo c k Cal l A dmin indicating that there is a call request from a calling part y The blo c k creates an instance of the blo c k Outgoing Hand ler in order to mak e the instance manage the calling part y After generating a message L init the instance w aits for a call connection from a called part y m e s s a g e s = H i n i t L i n i t L a l e r t H a l e r t H a n s w e r L a n s w e r L c o m p l e t e H c o m p l e t e ; p a t h s = p 1 : H i n i t ; p 2 : L i n i t ; p 3 : L a l e r t ; p 4 : H a l e r t ; p 5 : H a n s w e r ; p 6 : L a n s w e r ; p 7 : L c o m p l e t e ; p 8 : H c o m p l e t e ; I n c o m i n g H a n d l e r ( 0 N ) O u t g o i n g H a n d l e r ( 0 N ) C a l l A d m i n ( 1 1 ) p 8 p 4 p 1 p 5 p 7 p 2 p 3 p 6 Figure 3{12: A call con trol blo c k using pattern split dynamic handler On the other hand, if the blo c k Cal l A dmin receiv es a message L alert implying that there is an incoming call, it creates an instance of the blo c k Inc oming Hand ler to setup a call connection with the called part y A message H alert is used to indicate a new call is coming. When the called part y answ ers, the messages suc h as H answer L answer L c omplete and H c omplete are transferred. 3.1.3.8 See also DynamicEn tit ySet [ 70 ], ConduitF actory [ 26 ], P attern Half Ob ject + Protocol [ 68 ] 3.2 Beha vioral P atterns 3.2.1 Comm unicating Extended Finite State Mac hine 3.2.1.1 Con text Man y comm unication systems react to ev en ts coming from outside en vironmen ts. The systems can b e mo deled b y distinct states and transitions. When a system receiv es an ev en t, it mo v es from its curren t state to a new state while p erforming some actions and pro viding output signals. 3.2.1.2 Problem Ho w can w e describ e the b eha vior of a comm unication system?

PAGE 44

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.

PAGE 45

34 Denition 1 (CEFSM) A CEFSM is a 5-tuple ( S; s 0 ; E ; f ; V ) wher e S is a set of states s 0 is an initial state E is a set of events with their p ar ameter lists f is a state tr ansition r elation V is a set of lo c al variables along with their typ es and initial values, if any. F or a state, an input event, and a pr e dic ate c omp ose d of a subset of V the state tr ansition r elation f has a next state, a set of output events and their p ar ameters, and an action list describing how the lo c al variables ar e up date d. As an example, see the follo wing CEFSM: C E F S M = ( f S 1 ; S 2 ; S 3 ; S 4 g ; S 1 ; f init; e 1 ( p 1 ) ; e 2 ; o 1 ; o 2 ( p 2 ; p 3 ) g ; f ; f x g ) ; wher e f has the four elements f < S 1 ; init; S 2 ; ( x := 0) ; f o 1 g >; < S 2 ; e 1 ( p 1 ) ; S 3 ; ( x := x + p 1 ) ; f o 2 ( x; p 1 ) g >; < S 2 ; e 2 ; S 4 ; (\ enc o ding e 2 ") ; fg >; < S 3 ; e 2 [ x = 8] ; S 4 ; ( ) ; fg > g This CEFSM has four states, v e ev en ts, and one in teger v ariable. The input ev en t e 1 has a parameter p 1 and the output ev en t o 2 has t w o parameters, p 2 and p 3 The four transitions among the states are represen ted b y the relation f F or simplicit y w e do not giv e the t yp es of v ariables and parameters. As an in ternal ev en t, w e assume an init ev en t to indicate the start-up signal of the CEFSM. The tuple elemen t < S 1 ; init; S 2 ; ( x := 0) ; f o 1 g > of relation f denotes a transition that mo v es from S 1 to S 2 while assigning zero to the v ariable x and generating the ev en t o 1 after the initial signal init The action list can include the brief activities during the transition in plain English as w ell as a v ariable up date.

PAGE 46

35 F or example, \enco ding e 2 implies that the mac hine will enco de the e 2 receiv ed. The actions will b e rened in the later dev elopmen t phases. As a precondition of a transition, w e in tro duce a predicate, a b o olean v alued expression of the lo cal v ariables [ 14 ]. Up on receiving an ev en t, the CEFSM ev aluates the predicate. If the predicate holds, the CEFSM executes the transition. Ho w ev er, if the predicate do es not hold, the CEFSM ignores the ev en t and sta ys at the curren t state. An empt y predicate is dened to b e shorthand for true. In the previous example, the transition from S 3 to S 4 has a predicate x = 8. In this pattern language, w e usually represen t a CEFSM with a state transition diagram (STD), a directed graph whose v ertices corresp ond to states and whose edges corresp ond to transitions. Figure 3{13 sho ws an STD of the previous S 2 S 3 e 1 ( p 1 ) / x : = x + p 1 / o 2 ( x p 1 ) i n i t / x : = 0 / o 1 S 1 S 4 e 2 / “ e n c o d i n g e 2 ” / e 2 [ x = 8 ] / / Figure 3{13: An example CEFSM represen ted in STD example. Eac h state is represen ted b y a circle, and the initial state has a double circle. Eac h transition is lab eled with an input ev en t, action list, and output ev en ts. It is denoted b y input(p ar ameters)[pr e dic ate]/actions/outputs(p ar ameters) The `{' sym b ol in a transition indicates that there is no corresp onding eld. T ransitions that do not alter the state are represen ted b y an arc that p oin ts to itself. T ypically a complex comm unication system is designed with a large n um b er of states and transitions. A CEFSM can b e expanded b y merging with other CEFSMs.

PAGE 47

36 Denition 2 (Merge of CEFSMs) L et M 1 = ( S 1 s 1 E 1 f 1 O 1 V 1 ) and M 2 = ( S 2 s 2 E 2 f 2 O 2 V 2 ) b e two CEFSMs. M 1 M 2 mer ge of the two CEFSMs, cr e ates a new CEFSM ( S s 0 E f O V ) such that S = S 1 [ S 2 S is a union of S 1 and S 2 s 0 = s 1 the initial state of M 1 E = E 1 [ E 2 f = f 1 [ f 2 O = O 1 [ O 2 V = V 1 [ V 2 The merge is formed b y using the union op eration b et w een sets. 3.2.1.5 P attern: basic CEFSM This is the basis of the pattern language and is comp osed of a source state and a target state. The transition relation f has only one elemen t suc h as b asic CEFSM = f < S s ; e; S t ; A; O > g Note that the source state S s and target state S t could b e the same state. Figure 3{14 sho ws the STD of the pattern basic CEFSM. ( b ) S t e / A / O ( a ) e / A / O S s S s Figure 3{14: P attern basic CEFSM Prop ert y sp ecication. In the pattern basic CEFSM dra wn in Figure 3{14 (a), the input ev en t e has to o ccur ev en tually to initiate the transition. In the case of Figure 3{14 (b), it is necessary for the input ev en t to o ccur innitely often to rep eat the transition.

PAGE 48

37 Prop ert y: The input ev en t e has to o ccur ev en tually L TL: e Prop ert y: The input ev en t e o ccurs innitely often. L TL: e After the o ccurrence of the input ev en t, the output ev en t O has to resp onse to the input so that the transition completes. Prop ert y: The input ev en t e is follo w ed b y the o ccurrence of output ev en t O L TL: ( e O ) It is imp ortan t to note that the latter prop ert y do es not consider the corresp ondence b et w een the input and output ev en ts. Usually one needs input and output ev en ts to alternate. This prop ert y can b e captured b y in tro ducing a global v ariable n c initialized to zero to measure the n um b er of ev en ts happ ened [ 47 ]. The coun ter is increased when an input ev en t e happ ens, whereas it is decreased if an output ev en t O o ccurs. Prop ert y: The input ev en t e and output ev en t O o ccur alternativ ely L TL: (0 n c 1), where n c initialized to zero is increased after e and decreased after O Mean while, if the state S s is the initial state of a whole system, the input ev en t e is the rst ev en t to ha v e happ ened in the system. Accordingly other ev en ts cannot pro ceed the ev en t. Prop ert y: The ev en t e pro ceeds all other ev en ts e o None of the a v ailable ev en ts can happ en b efore e L TL: ( : e o ) ( : e o U e ) Un til no w, the prop erties sp ecied ab o v e apply to the en tire computation. Ho wev er, w e can constrain t the p erio d in whic h the prop erties w ould apply F or example, in Figure 3{14 (a), the input ev en t e m ust happ en b et w een the state S s and S t

PAGE 49

38 Prop ert y: The ev en t e m ust o ccur b et w een the states S s and S t L TL: (( S s ^ : S t ) ( : S t U (( e ^ : S t ) : S t ))) In addition to the existence prop ert y it is also p ossible to sp ecify the absence prop ert y of an ev en t. Prop ert y: The ev en t e m ust not happ en b efore the state S s and also after the state S t L TL: ( S s ( : e U S s )) ^ ( ( S t ( : e ))) Since ev ery pattern of our pattern language is based on the pattern basic CEFSM, the prop erties men tioned in this pattern are also applicable to other patterns. It is w orth noting that the prop erties presen ted in this section are not a complete set of prop erties p ossible in the pattern. The k ey idea is to capture and deduce the prop erties required in a system from the visual pattern. 3.2.1.6 V arian t: predicate CEFSM As w e men tioned at the denition, a CEFSM can ha v e predicates to con trol the b eha vior of the CEFSM [ 14 ]. The predicate indicates under what condition the action will b e tak en. By adding a predicate to the pattern basic CEFSM, w e can get the v arian t predicate CEFSM. Mean while, an input ev en t usually has sev eral predicates as a decision p oin t. W e, therefore, dene the pattern ha ving sev eral predicates. pr e dic ate CEFSM = f < S s ; e [ pr edicate 1 ] ; S t 1 ; A 1 ; O 1 > < S s ; e [ pr edicate 2 ] ; S t 2 ; A 2 ; O 2 > :::< S s ; e [ pr edicate n ] ; S tn ; A n ; O n > g Note that the source state S s and target states could b e the same state. If the predicates are m utually exclusiv e, then the CEFSM is deterministic. Figure 3{15 sho ws the STD of the pattern predicate CEFSM.

PAGE 50

39 S t 1 e [ p r e d i c a t e 1 ] / A 1 / O 1 S t n e [ p r e d i c a t e n ] / A n / O n S s Figure 3{15: P attern predicate CEFSM Prop ert y sp ecication. The input ev en t e has to o ccur ev en tually and at least one of the predicates m ust hold at that time to initiate the transition. Prop ert y: The input ev en t e happ ens ev en tually and at least one of the predicates holds. L TL: ( e ^ ( pr edicate 1 _ pr edicate n )) F urthermore, the output ev en t corresp onding to the holding predicate has to resp ond to the input ev en t. Prop ert y: The predicate pr edicate i whic h holds at ev en t e is follo w ed b y a corresp onding output ev en t O i where 1 i n L TL: ((( e ^ pr edicate 1 ) O 1 ) _ (( e ^ pr edicate n ) O n )) In addition to these t w o prop erties, it will also b e necessary to consider the prop erties presen ted at the pattern basic CEFSM from whic h the new prop erties are deducible. 3.2.1.7 V arian t: predicate after action A t the pattern predicate CEFSM, an input ev en t is follo w ed b y predicates to decide the next transition. Ho w ev er, in some cases decisions need to b e made after p erforming some actions. In other w ords, after p erforming a sequence of actions for an input, an instance decides its next transition based on the result of the actions.

PAGE 51

40 The instance therefore needs predicates after the actions. pr e dic ate after action = f < S s ; e; S 0 s ; A s ; O s > < S 0 s ; [ pr edicate 1 ] ; S t 1 ; A 1 ; O 1 > < S 0 s ; [ pr edicate 2 ] ; S t 2 ; A 2 ; O 2 > :::< S 0 s ; [ pr edicate n ] ; S tn ; A n ; O n > g Note that the transitions from S 0 s do not ha v e ev en t elds. Figure 3{16 sho ws the STD of the pattern predicate after action. In fact, this pattern is a sequen tial S s ¢ e / A s / O s S t 1 [ p r e d i c a t e 1 ] / A 1 / O 1 S t n [ p r e d i c a t e n ] / A n / O n S s Figure 3{16: P attern predicate after action merge b et w een the transition from S s to to S 0 s and the predicate CEFSM. Refer to the pattern sequen tial merge. Prop ert y sp ecication. First, the input ev en t e m ust o ccur. Then at least one of the predicates has to hold in the future. Prop ert y: The input ev en t e m ust happ en ev en tually and at least one of the predicates has to hold after the ev en t. L TL: ( e ^ ( pr edicate 1 _ pr edicate n )) Another prop ert y of the CEFSM is an o ccurrence of an output ev en t follo wing the input and holding predicate.

PAGE 52

41 Prop ert y: The input ev en t e is follo w ed b y a holding predicate pr edicate i and the corresp onding output ev en t O i L TL: ( e (( pr edicate 1 ^ O 1 ) _ ( pr edicate n ^ O n ))) 3.2.1.8 V arian ts: sequen tial, source, and target merges T ypically a complex comm unication proto col is made b y comp osing sev eral CEFSMs to fulll the required functionalit y There are three common t yp es of merge: sequen tial merge, source merge, and target merge. T o in tro duce these patterns, w e classify a state in a CEFSM in to either a terminal state or a non terminal state. A state is called a terminal state if it is not used as a source state in a transition of the CEFSM. Otherwise, it is a non terminal state. A sequen tial merge is a merging of a terminal state of a CEFSM with a non terminal state of another CEFSM. Figure 3{17 (a) sho ws the merging of states S 2 and S 3 The com bined CEFSM go es to state S 4 through the state S 23 This situation is common when a system handles a sequen tial input from the en vironmen t. S 2 e 1 / A 1 / O 1 S 4 e 2 / A 2 / O 2 + S 2 3 e 1 / A 1 / O 1 S 4 e 2 / A 2 / O 2 S 1 S 3 S 1 ( a ) S 2 e 1 / A 1 / O 1 S 4 e 2 / A 2 / O 2 S 1 3 S 2 4 S 1 e 1 / A 1 / O 1 S 3 e 2 / A 2 / O 2 ( b ) ( c ) Figure 3{17: Merge patterns com bined from t w o CEFSMs The pattern source merge com bines eac h non terminal state of t w o CEFSMs. In Figure 3{17 (b), the initial states, S 1 and S 3 are com bined, and the resulting CEFSM has three states and t w o transitions. This b eha vior commonly o ccurs in a state receiving sev eral p oten tial input ev en ts.

PAGE 53

42 The pattern target merge is obtained b y com bining eac h terminal state of a CEFSM. This is usual when t w o transitions w an t to sta y at the same state after eac h transition. Figure 3{17 (c) sho ws a t ypical example. Prop ert y sp ecication. The pattern sequen tial merge is a com bination of t w o basic CEFSMs in sequence. Th us, the input ev en ts happ en in order. Prop ert y: The input ev en t e 1 has to o ccur ev en tually to initiate the CEFSM. L TL: e 1 Prop ert y: The input ev en t e 1 is follo w ed b y the ev en ts O 1 e 2 and O 2 L TL: ( e 1 ( O 1 ^ ( e 2 ^ O 2 ))) F requen tly it is sucien t to c hec k that the initial input e 1 is follo w ed b y the nal output O 2 suc h as Prop ert y: The input ev en t e 1 is follo w ed b y the output ev en t O 2 L TL: ( e 1 O 2 ) F urthermore, the input e 2 cannot happ en b efore the input e 1 b ecause e 1 is the rst ev en t of the CEFSM. Prop ert y: The ev en t e 1 pro ceeds the ev en t e 2 L TL: e 1 ( : e 2 U e 1 ) Note that the second prop ert y do es not consider the corresp ondence b et w een eac h ev en t. These ev en ts ha v e to happ en alternativ ely This prop ert y can b e captured b y in tro ducing the global v ariables n 1 n 2 and n 3 whic h are initialized to zero. The v ariables coun t the n um b er of ev en ts happ ened [ 47 ]. The coun ters are increased when the ev en ts e 1 O 1 and e 2 happ en, while they are decreased if the ev en ts O 1 e 2 and O 2 o ccur. Prop ert y: The ev en ts e 1 O 1 e 2 and O 2 o ccur sequen tially and alternativ ely L TL: ((0 n 1 1) ^ (0 n 2 1) ^ (0 n 3 1)), where the coun ters are increased when the ev en ts e 1 O 1 and e 2 happ en and decreased when the ev en ts O 1 e 2 and O 2 o ccur.

PAGE 54

43 F or the case of pattern source merge, the t w o inputs ha v e to o ccur to c hec k b oth the cases. Prop ert y: The input ev en ts e 1 and e 2 ha v e to o ccur ev en tually to initiate the CEFSM. L TL: e 1 ^ e 2 3.2.1.9 Implemen tation The basic CEFSM is implemen ted in SDL b y a mec hanical one-to-one mapping from its STD. Figure 3{18 sho ws an SDL diagram fragmen t for the basic CEFSM of Figure 3{14 (a). Eac h state of the CEFSM is con v erted to the corresp onding e S s AS t O S t e / A / O S s Figure 3{18: SDL fragmen t for pattern basic CEFSM SDL state. A transition is represen ted b y an input signal, a task for the action, and an output signal. When an instance of the pattern receiv es an input ev en t e with its parameters in the state S s it p erforms the task A and generates output signal O Note that if the transition expresses an initialization with the init in ternal ev en t, the source state has to b e translated to a start sym b ol. The in ternal ev en t is not sho wn at the SDL implemen tation. The implemen tation of pattern predicate CEFSM leads to an SDL decision sym b ol. Figure 3{19 sho ws an SDL diagram fragmen t for Figure 3{15 where there are n predicates for an ev en t e Up on receiving an ev en t e the CEFSM c hec ks the predicates and then p erforms actions for a true predicate. The pattern predicate after action is similarly implemen ted as Figure 3{19 with a decision sym b ol after

PAGE 55

44 the actions. It it imp ortan t to note that the state S 0 s of Figure 3{16 is not sho wn in the SDL diagram. ( p r e d i c a t e 1 ) ( p r e d i c a t e n ) S t 1 e [ p r e d i c a t e 1 ] / A 1 / O 1 S t n e [ p r e d i c a t e n ] / A n / O n S s e S s A 1 S t 1 O 1 A n S t n O n Figure 3{19: SDL fragmen t for pattern predicate CEFSM The implemen tation of merge patterns can b e obtained b y straigh tforw ard mapping of the resulting STDs. W e omit the SDL implemen tation of the patterns. 3.2.1.10 Example As an example of the pattern predicate after action, Figure 3{20 sho ws an error detection metho d whic h p erforms the c hec ksum for an input msg(data). If [ r s t = 0 ] / “ d e c o d i n g ” / m s g ( o k ) w a i t d a t a m s g ( d a t a ) / r s t : = c h e c k s u m ( d a t a ) / [ r s t = 0 ] / / m s g ( n o k ) w a i t d a t a ¢ p r o c e e d e r r o r Figure 3{20: Example of pattern predicate after action for error detection the result of the action pro cedure has zero v alue, whic h means that there is no error in the receiv ed message, the CEFSM p erforms the deco ding and generates the output message msg(ok). Otherwise, the input message has an error, and an error notication message msg(nok) is sen t. Note that the predicates rst = 0 and rst != 0 are ev aluated dep ending on the previous action c hec ksum().

PAGE 56

45 F rom the prop ert y sp ecication of the pattern, w e can get the follo wing requiremen ts of the CEFSM. Prop ert y: The input ev en t msg(data) has to happ en ev en tually and the che cksum will ha v e zero or non-zero v alue for the data L TL: (msg(data) ^ ((rst!=0) (rst=0))) Prop ert y: The input ev en t msg(data) is follo w ed b y one of output ev en ts msg(nok) or msg(ok) dep ending on the result of predicates. L TL: (msg(data) (((rst!=0) ^ msg(nok) ) ((rst=0) ^ msg(ok) ))) As an another example, let us supp ose w e are designing a system that uses the connection orien ted comm unication with other systems. The system handles connection establishmen t and release requests to setup a connection with a p eer system and to release the connection. Figure 3{21 (a) sho ws the connection setup scenario using the pattern basic CEFSM. After receiving a connection e s t a b l i s h e d w a i t e s t a b l i s h E S T r e q / c o n n e c t / E S T c o n f ( a ) w a i t r e l e a s e r e l e a s e d R E L r e q / d i s c o n n e c t / R E L c o n f ( b ) E S T r e q / c o n n e c t / E S T c o n f R E L r e q / d i s c o n n e c t / R E L c o n f w a i t m s g ( c ) ( d ) E S T r e q / c o n n e c t / E S T c o n f R E L r e q / d i s c o n n e c t / R E L c o n f r e l e a s e d r e l e a s e d e s t a b l i s h e d e s t a b l i s h e d w a i t e s t a b l i s h Figure 3{21: Example of merge patterns request EST.req, the CEFSM p erforms action \connect". Then, it noties the p eer that the connection is set up b y using the message EST.conf. Similarly the disconnection step is also ac hiev ed in the pattern basic CEFSM as Figure 3{21 (b).

PAGE 57

46 In fact, it is p ossible to handle the t w o requests at one state. Note that the CEFSMs for connection setup and release ha v e dieren t state names. Before merging the CEFSMs, w e rename b oth wait establish and wait r ele ase to wait msg The merged CEFSM is describ ed in Figure 3{21 (c), and it is an example of pattern source merge. On the other hand, a connection can b e disconnected only after the connection is setup. Figure 3{21 (d) sho w that the connection CEFSM is sequen tially merged with the disconnection CEFSM. The state wait r ele ase w as renamed to establishe d b efore the merging. The state r ele ase d can b e reac hed through the state establishe d The requiremen ts of the result CEFSM can b e obtained as follo ws: Prop ert y: Ev en tually the input ev en t EST.r e q has to o ccur to initiate the connection. L TL: EST.req Prop ert y: The input ev en t EST.r e q is follo w ed b y the ev en t EST.c onf REL.r e q and REL.c onf in sequence. In other w ords, b efore the request of connection release REL.r e q the connection w as established b y EST.c onf L TL: (EST.req (EST.conf ^ (REL.req ^ REL.conf ))) Prop ert y: The ev en t EST.r e q pro ceeds the ev en t REL.r e q In other w ords, b efore the connection release request, the connection m ust b e established b y EST.r e q L TL: EST.req ( : REL.req U EST.req ) ce. Prop ert y: The ev en ts EST.r e q EST.c onf REL.r e q and REL.c onf m ust happ en alternativ ely L TL: ((0 n 1 1) ^ (0 n 2 1) ^ (0 n 3 1))

PAGE 58

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

PAGE 59

48 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 all these time concepts come from SDL [ 14 ]. S 1 T / A 2 / O 2 S 2 e / r e s e t ( T ) A 3 / O 3 e 0 / s e t ( v T ) A 1 / O 1 S 3 S 0 Figure 3{22: P attern timer with the exp ected ev en t e Figure 3{22 sho ws an STD of the pattern timer. First, a timer T should b e set b efore using it. In the diagram, the transition happ ens up on the ev en t e 0 On timer expiration for T the CEFSM mo v es to the state S 2 If the CEFSM receiv es the exp ected ev en t e it resets the timer and p erforms the remaining transition. 3.2.2.4 Prop ert y sp ecication First, the input ev en t e 0 m ust o ccur ev en tually to initiate the CEFSM. Prop ert y: The initial input ev en t e 0 m ust happ en ev en tually L TL: e 0 Then, either the in tended ev en t e or time expiration T has to follo w the input ev en t e 0 Prop ert y: The input ev en t e 0 is follo w ed b y either an ev en t e or a time expiration T L TL: ( e 0 (( e ^ : T ) ( : e ^ T )))

PAGE 60

49 There is a p ossibilit y to arriv e at the in tended ev en t e after T is tak en due to the dela y of the ev en t. If the dela y ed deliv ery of an ev en t is not allo w ed in the system, w e also ha v e to describ e this prop ert y using the absence prop ert y Prop ert y: After a timeout T no e o ccurs. L TL: ( T ( : e )) 3.2.2.5 Implemen tation A timer v ariable in the CEFSM maps to an SDL Timer ob ject. The Timer ob ject m ust b e declared lik e an y other v ariable in SDL. In addition, the time v alue is giv en as part of the declaration. The op erations on the Timer ob ject are set(Timer) and reset(Timer). Since the time v alue is giv en in the declaration, it is not sp ecied in the set op eration. Figure 3{23 sho ws the SDL implemen tation of the t ypical timer pattern discussed ab o v e. T i m e r T : = v ; S 1 T / A 2 / O 2 S 2 e / r e s e t ( T ) A 3 / O 3 e 0 / s e t ( v T ) A 1 / O 1 S 3 S 0 e S 1 A 2 S 2 O 2 A 3 S 3 O 3 e 0 S 0 s e t ( T ) S 1 O 1 A 1 r e s e t ( T ) T Figure 3{23: SDL fragmen t for pattern timer 3.2.3 Rep eated Ev en ts 3.2.3.1 Con text In an ev en t-driv en system, a single ev en t ma y not b e sucien t to initiate a reaction: an ev en t m ust o ccur sev eral times. F or example, if a message is transmitted in sev eral pac k ets, all pac k ets m ust arriv e b efore the further message handling.

PAGE 61

50 3.2.3.2 Problem Ho w do es a comm unication system handle the rep eated ev en ts? 3.2.3.3 F orces Timing c onstr aints : It is necessary to imp ose timing constrain ts for the rep eated ev en ts. There are t w o kinds of timing constrain ts suc h as for the individual ev en t and for all ev en ts. Numb er of r ep etitions : In some cases, the n um b er of rep etitions is kno wn in adv ance. In other cases, it is not. Ev en when the n um b er is not kno wn in adv ance, there still ma y b e an upp er b ound on the n um b er of rep etitions. 3.2.3.4 Solution This pattern is a sp ecialization of the pattern predicate CEFSM. First, the CEFSM has an in teger v ariable c whic h is initialized to one to coun t the n um b er of o ccurrences of an ev en t. Predicates c < N and c = N determine the next transition where N is the n um b er of times the ev en t should b e rep eated. If c is less than N, then c is incremen ted and the state unc hanged. Otherwise, the state c hanges to the the next state and an y sp ecied output ev en ts are generated. Figure 3{24 sho ws the solution and its SDL implemen tation. S 1 e [ c = N ] / A 2 / O 2 S 2 e [ c < N ] / c : = c + 1 A 1 / O 1 ( < N ) ( = = N ) D C L c i n t e g e r : = 1 ; N i n t e g e r : = M A X ; c A 2 S 2 O 2 e S 1 c : = c + 1 O 1 A 1 Figure 3{24: P attern rep eated ev en ts and its SDL implemen tation

PAGE 62

51 3.2.3.5 Prop ert y sp ecication The input ev en t e has to o ccur to initiate the CEFSM and the coun ter c should b e one at that time. Prop ert y: The input ev en t e has to happ en ev en tually and the coun ter c is one at that time. L TL: ( e ^ ( c = 1)), where c k eeps the n um b er of o ccurrences of ev en t e Then, the ev en t happ ens (N-1) times more and then it is follo w ed b y an output ev en t O 2 Prop ert y: The input ev en t e and predicate (c = 1) is follo w ed b y (N-1) times e and O 2 L TL: (( e ^ ( c = 1)) (( e ^ ( c = N )) ^ O 2 )) Moreo v er, the ev en t e should not happ en after the N-th o ccurrence. Prop ert y: The input ev en t e cannot happ en more than N times. L TL: (1 c N ) 3.2.3.6 V arian t: timed rep eated ev en ts In this v arian t, w e add timers to enforce timing constrain ts. This pattern can th us b e considered as a com bination of the patterns of rep eated ev en ts and timer. Tw o timers T 1 and T 2 are used in the pattern. Timer T 1 is used for the individual o ccurrences of ev en t e while T 2 is used for all of the ev en ts together. Figure 3{25 sho ws the resulting CEFSM and its SDL implemen tation. A t the state S 1 the CEFSM receiv es the ev en t e un til it has all ev en ts needed. If the n um b er of ev en ts is less than N the mac hine increases the c and sets the timer T 1 again. If the timer T 1 or T 2 expires, the mac hine mo v es to the corresp onding state to handle this exceptional case. Note that either timer could b e omitted but not b oth. Then only the total or single ev en t timing constrain ts w ould b e c hec k ed.

PAGE 63

52 D C L c i n t e g e r : = 1 ; N i n t e g e r : = M A X ; T i m e r T 1 : = v 1 ; T 2 : = v 2 ; c : = c + 1 s e t ( T 1 ) r e s e t ( T 1 ) r e s e t ( T 2 ) e 0 S 0 s e t ( T 1 ) S 1 O 1 s e t ( T 2 ) A 1 ( < N ) ( = = N ) c A 3 S 2 O 3 e O 2 A 2 S 1 T 1 S 3 O 4 A 4 T 2 S 4 O 5 A 5 e 0 / s e t ( v 1 T 1 ) c : = 1 s e t ( v 2 T 2 ) A 1 / O 1 e [ c = N ] / r e s e t ( T 1 ) r e s e t ( T 2 ) A 3 / O 3 e [ c < N ] / c : = c + 1 s e t ( v 1 T 1 ) A 2 / O 2 T 1 / r e s e t ( T 2 ) A 4 / O 4 T 2 / r e s e t ( T 1 ) A 5 / O 5 S 1 S 3 S 4 S 2 S 0 Figure 3{25: P attern timed rep eated ev en ts and its SDL implemen tation Prop ert y sp ecication. This pattern is a com bination of the pattern rep eated ev en ts with the pattern timer. Therefore, w e can deduce the prop erties of this pattern from their ones. Prop ert y: The initial input ev en t e 0 m ust happ en ev en tually L TL: e 0 Then, the ev en t is follo w ed b y one of the three p ossible ev en ts. Prop ert y: The input ev en t e 0 is follo w ed b y one of three input ev en ts e T 1 and T 2 L TL: ( e 0 ((( e ^ ( c = N )) ^ : T 1 ^ : T 2 ) ( : ( e ^ ( c = N )) ^ T 1 ^ : T 2 ) ( : ( e ^ ( c = N )) : ^ T 1 ^ T 2 ))) Prop ert y: The subsequen t input ev en ts are follo w ed b y eac h corresp onding output ev en t. L TL: ((( e ^ ( c = N )) O 3 ) ^ ( T 1 O 4 ) ^ ( T 2 O 5 )) As a simplied prop ert y of the ab o v e prop erties, w e ma y c hec k that the initial input ev en t e 0 is follo w ed b y one of three output ev en ts O 3 O 4 and O 5 3.2.3.7 V arian t: timed retrial In the previous patterns, the n um b er of rep etitions of an ev en t b efore the system mo v ed to a dieren t state w as kno wn in adv ance. This v arian t considers the

PAGE 64

53 case where the n um b er of rep etitions is not kno wn in adv ance (and ma y b e 0), but the maxim um n um b er is b ounded. A t ypical scenario w ould b e where the rep eated c D C L c i n t e g e r : = 1 ; N i n t e g e r : = M A X ; T i m e r T : = v ; e 0 S 0 s e t ( T ) S 1 O 1 A 1 S 1 c : = c + 1 s e t ( T ) ( < N ) ( = = N ) A 4 S 3 O 4 T O 2 A 2 e S 2 O 3 A 3 r e s e t ( T ) S 1 S 3 S 2 e 0 / s e t ( v T ) A 1 / O 1 T [ c = N ] / A 4 / O 4 T [ c < N ] / c : = c + 1 s e t ( v T ) A 2 / O 2 e / r e s e t ( T ) A 3 / O 3 S 0 Figure 3{26: P attern timed retrial and its SDL implemen tation ev en t is the expiration of a timer set. F or example, a message is transmitted and the timer is set. If an ac kno wledgmen t is not receiv ed b efore the timer expires, the message is retransmitted. The message will b e transmitted a maxim um of N times b efore the system mo v es to an error state. Figure 3{26 sho ws the solution where the rep eated ev en t is the expiration of the timer. Prop ert y Sp ecication. The pattern timed retrial has a similar state transition diagram as the pattern time d r ep e ate d events It needs the initial input e 0 whic h will b e resp onded b y either the target ev en t e or N -th expiration. Prop ert y: The input ev en t e 0 has to o ccur ev en tually L TL: e 0 Prop ert y: The input ev en t e 0 is follo w ed b y either the target ev en t e or N times timeout. L TL: ( e 0 (( e ^ : ( T ^ ( c = N ))) ( : e ^ ( T ^ ( c = N ))))) Prop ert y: After N-th expiration, no timeout T exists. L TL: (1 c N )

PAGE 65

54 3.2.3.8 Example Figure 3{27 (a) describ es a part of a call setup soft w are. It receiv es a telephone n um b er comp osed of nine digits from a caller. After receiving the ev en t dial nine times, the CEFSM generates an output c onn r e q to request a call connection with a callee of the n um b er. The example can b e expanded with a timer T to a v oid d i a l ( d i g i t ) [ c = 9 ] / “ s t o r e d i g i t ” / c o n n r e q ( d i g i t s ) c o n n e c t i n g d i a l ( d i g i t ) [ c < 9 ] / “ s t o r e d i g i t ” c : = c + 1 ; / d i a l i n g F T P r e q / c : = 1 s e t ( 5 T ) / F T P c o n n e c t T [ c = N ] / / F T P f a i l T [ c < 1 0 ] / c : = c + 1 s e t ( 5 T ) / F T P c o n n e c t c o n n e c t o k / r e s e t ( T ) / F T P r e a d y w a i t c o n n e c t i n g c o n n e c t e d c o n n e c t e r r o r ( a ) ( b ) Figure 3{27: Nine-digit dialing using pattern rep eated ev en ts unlimited w aiting. If a caller do es not push a digit in a giv en time b ound, the mac hine noties the caller that time is o v er b y giving a sp ecial b eep. This case is implemen ted b y adding a transition for the timer expiration. The follo wing are the part of prop erties obtainable from the patterns used. Prop ert y: A call connection request needs nine digits. L TL: (( dial ( dig it ) ^ c = 1) (( dial ( dig it ) ^ ( c = 9)) ^ c onn r e q )) Prop ert y: A call connection needs nine digits in the timing constrain ts T L TL: (( dial ( dig it ) ^ c = 1) (((dial ^ ( c = 9)) ^ : T ) ( : (dial ^ ( c = 9)) ^ T ))) As an example of the pattern timed retrial, Figure 3{27 (b) sho ws an FTP clien t that receiv es an FTP request from a user and try to connect to an FTP serv er. The follo wing are the prop erties obtainable from the example. L TL: FTP req L TL: (FTP req ((connect OK ^ : ( T ^ ( c = 9))) ( : connect OK ^ ( T ^ ( c = 9)))))

PAGE 66

55 3.2.3.9 See also P attern TimerCon trolledRep eat [ 70 ] rep eats a message transmission to a v oid message loss during data transfer. If a sender en tit y do es not receiv e an exp ected ac kno wledgmen t in the giv en expiration time from a receiv er en tit y the message is rep eated b y the sender. This pattern is considered as an instan tiation of the pattern timed retrial. 3.2.4 Message T ransfer 3.2.4.1 Con text In a comm unication net w ork, t w o comm unicating en tities in the same la y er w an t to in teract to transfer messages through their lo w er la y er. 3.2.4.2 Problem Ho w do t w o comm unicating p eers in teract in a la y ered proto col? 3.2.4.3 F orces R ole of inter action : In the comm unication, one part y initiates comm unication and another reacts to it. Th us, it is imp ortan t to iden tify the role of en tit y b efore comm unication. 3.2.4.4 Solution Conceptually a la y er pro vides a set of services to its users. Th us, the users consider the lo w er la y er as a service pro vider [ 64 73 ]. They comm unicate with the service pro vider through service access p oin ts (SAP). The service pro vider co ordinates and manages comm unications b et w een users b y using four t yp es of primitiv es, request, indication, resp onse, and conrm, as sho wn in Figure 3{28 The user A initiates a message transfer with the p eer B b y in v oking the primitiv e request to the lo w er la y er. The p eer of the initiator is informed b y the lo w er la y er using the primitiv e indication. The resp onden t replies to the indication b y in v oking the primitiv e resp onse to the lo w er la y er. The lo w er la y er noties the initiator of

PAGE 67

56 U S E R A c o n f i r m r e q u e s t S e r v i c e P r o v i d e r i n d i c a t i o n r e s p o n s e L o g i c a l C o m m u n i c a t i o n s S A P S A P m e s s a g e s U S E R B Figure 3{28: Proto col la y er as a service pro vider the resp onse from the p eer using the primitiv e conrm. Dep ending on the proto col, the name of eac h primitiv e migh t b e dieren t. T ypically there are t w o kinds of comm unication b et w een p eers suc h as conrmed transfer and unconrmed transfer. If an initiator needs an ac kno wledgmen t from a p eer, it uses a conrmed transfer with the four primitiv es. Ho w ev er if this is not the case, the initiator sends a message without exp ecting an ac kno wledgmen t. F or example, a connection establishmen t alw a ys uses a conrmed transfer b ecause a p eer m ust agree to establish a connection with its initiator. A data transfer, on the other hand, uses either conrmed or unconrmed transfer dep ending on proto col [ 73 ]. 3.2.4.5 V arian t: unconrmed sender The pattern unconrmed sender giv en in Figure 3{29 (a) initiates a simple but unconrmed message transfer. It do es not care ab out the progress and result of message transfer once it has b een initiated. S 4 r e c e i v e r i n d i c a t i o n / A 2 / O 2 S 2 s e n d e r e / A 1 / r e q u e s t O 1 S 1 S 3 Figure 3{29: P atterns unconrmed sender and unconrmed receiv er

PAGE 68

57 Prop ert y sp ecication. If a system is designed with this pattern, it is necessary to c hec k the follo wing prop erties, but are not limited. Prop ert y: The input ev en t e has to o ccur ev en tually and it m ust b e follo w ed b y an o ccurrence of request. L TL: e ^ ( e r eq uest ) Prop ert y: The ev en ts e and request o ccur alternativ ely L TL: (0 n er 1), where n er initialized to zero is increased after e and decreased after request. Example. An IP datagram sending at In ternet Proto col (IP) uses an unreliable, b est-eort, connectionless pac k et deliv ery system [ 74 ]. As a user's p oin t of view, the transfer of an e-mail is also the unconrmed transfer of a message. See also. Push In teraction P attern [ 30 ], SendReceiv e [ 23 ] 3.2.4.6 V arian t: unconrmed receiv er The pattern unconrmed receiv er tak es a message from a sending part y in the form of indication as sho wn in Figure 3{29 (b). It do es not reply to the sending part y It is imp ortan t to consider a receiving part y with a sending part y sim ultaneously b ecause a message transfer is t ypically p erformed in pairs. If the pattern unconrmed receiv er comm unicates with the pattern unconrmed sender, the indication corresp onds to the request of unconrmed sender. Prop ert y sp ecication. Since this pattern has a similar STD suc h as the pattern unconrmed sender, the prop erties sp ecied at the pattern are also applicable here. Prop ert y: The input ev en t indication has to o ccur ev en tually and it m ust b e follo w ed b y O 2 if the output exists. L TL: indication ^ ( indic ation O 2 ) Prop ert y: The ev en ts indication and O 2 o ccur alternativ ely

PAGE 69

58 L TL: (0 n io 1), where n io initialized to zero is increased after the o ccurrences of indication and decreased after O 2 Moreo v er, it ma y b e necessary to c hec k the corresp ondence of indication to the request if b oth unconrmed sender and unconrmed receiv er are used in pair. Prop ert y: The indication m ust alw a ys follo w the request and eac h ev en t has to happ en alternativ ely L TL: (( r eq uest indication ) ^ (0 n r i 1)) Example. Reception of an IP datagram uses the unconrmed receiv e. As a user's p oin t of view, the reception of an e-mail is also the unconrmed receiv e. See also. Push In teraction P attern [ 30 ], SendReceiv e [ 23 ] 3.2.4.7 V arian t: conrmed sender T o initiate a conrmed message transfer, the pattern conrmed sender starts a message transfer with a primitiv e request. Then, it w aits for a conrmation from its p eer. The primitiv e conrm w ould con tain the result of request, for instance, successful transfer of request, request refusal due to resource insucien t, etc. Figure 3{30 (a) depicts the t ypical b eha vior of the pattern where the transition lab eled with request is sequen tially merged with the transitions that ha v e sev eral conrmation messages. r e q u e s t e r S 2 e 1 / A 1 / r e q u e s t O 1 S 3 2 S 1 S 3 1 c o n f i r m 1 / A 2 1 / O 2 1 c o n f i r m 2 / A 2 2 / O 2 2 … … ( a ) S N M P g e t r e q u e s t e r S 2 e 1 / A 1 / G e t R e q u e s t P D U S 3 S 1 R e s p o n s e P D U / A 2 / O 1 ( b ) Figure 3{30: P attern conrmed sender and its example on an SNMP clien t

PAGE 70

59 Prop ert y sp ecication. Prop ert y: The input ev en t e 1 has to o ccur ev en tually and the request follo ws the ev en t. L TL: ( e 1 ^ ( e 1 r eq uest )) Prop ert y: The request is follo w ed b y one of conrmations. L TL: ( r eq uest (( conf ir m 1 ^ : conf ir m 2 ^ ^ : conf ir m n ) _ ( : conf ir m 1 ^ : conf ir m 2 ^ ^ conf ir m n ))) Moreo v er, it is also necessary to c hec k the corresp ondence b et w een the request and conrmation messages. Example. A net w ork managemen t proto col allo ws a net w ork manager to monitor and debug the no des attac hed to the net w ork. A clien t of the Simple Net w ork Managemen t Proto col (SNMP), a standard TCP/IP net w ork managemen t proto col, needs a v alue of a host to c hec k the status of the mac hine [ 75 ]. Figure 3{30 (b) presen ts an abstract b eha vior of the clien t whic h asks a v alue of a v ariable in a system using the message GetRequest-PDU. Then, it receiv es the result in the message Resp onse-PDU. If the v alue w as accessible at the remote mac hine, v alue eld is set to the corresp onding v alue. Otherwise, error status eld has a non-zero v alue whic h indicates that an error o ccurred during the request handling. Connection establishmen t request at t w o-w a y handshak e, status query and resource reserv ation request also use this pattern. See also. Pull In teraction P attern [ 30 ], Blo c kingRequestReply [ 23 ] 3.2.4.8 V arian t: conrmed receiv er After receiving a request from its p eer, a conrmed receiv er pro cesses the request and then replies with an appropriate resp onse message. There are three common w a ys to handle the b eha vior. In Figure 3{31 (a), a receiv er tak es an indication from a p eer. Then, it decides an appropriate resp onse after p erforming action A 1 The resp onse message includes the information that indicates the t yp e

PAGE 71

60 of resp onse suc h as success, remote host do wn, illegal address, etc. Another case is to reply with one of p ossible resp onse messages whic h holds a predicate after action A 1 as in Figure 3{31 (b). There are man y dieren t names for eac h resp onse in this case. As a last case, a receiv er w aits for another ev en t whic h indicates the result of request handling. i n d i c a t i o n / A 1 / r e s p o n s e O 1 S 2 S 1 ( a ) ( b ) i n d i c a t i o n / A 1 / S 2 S 1 S 3 1 [ p r e d 1 ] / A 2 1 / r e s p o n s e 1 O 2 1 [ p r e d 2 ] / A 2 2 / r e s p o n s e 2 O 2 2 S 3 2 ( c ) i n d i c a t i o n / A 1 / O 1 S 2 S 1 S 3 1 e 2 1 / A 2 1 / r e s p o n s e 1 O 2 1 e 2 2 / A 2 2 / r e s p o n s e 2 O 2 2 S 3 2 Figure 3{31: P attern conrmed receiv er in three common cases Prop ert y sp ecication. Since the STDs giv en in Figure 3{31 ha v e the same form as in basic CEFSM, predicate after action, and conrmed sender, w e can infer the prop erties of this pattern from them. The follo wing are the prop erties applicable to Figure 3{31 (a). Prop ert y: The input ev en t indication has to o ccur ev en tually and it is follo w ed b y the o ccurrence of resp onse. L TL: indication ^ ( indication r esponse ) Prop ert y: The ev en ts indication and resp onse o ccur alternativ ely L TL: (0 n ir 1) where n ir initialized to zero is increased after the o ccurrences of indication and decreased after resp onse. In the case of Figure 3{31 (b) and (c), w e can also infer the follo wing prop ert y Prop ert y: The input ev en t indication is follo w ed b y one of resp onse messages. L TL: ( indication (( r esponse 1 ^ : r esponse 2 ^ ^ : r esponse n ) _ ( : r esponse 1 ^ : r esponse 2 ^ ^ r esponse n )))

PAGE 72

61 Example. As a corresp onding receiv er of SNMP proto col whic h is giv en in the example of conrmed sender, a remote host receiving GetRequest-PDU pro cesses the v ariable binding to pro duce a Resp onse-PDU. If the binding fails, a Resp onse-PDU is replied with an error status eld set. Man y serv ers in the clien t-serv er mo del use this pattern to handle a request from clien ts. F or example, a time-of-da y serv er returns the curren t time when it receiv es a time request from a clien t [ 74 ]. See also. Pull In teraction P attern [ 30 ], Blo c kingRequestReply [ 23 ] 3.2.4.9 V arian t: timed receiv er and timed retrial receiv er The pattern timed receiv er w aits for an in tended message, indication, after setting a timer. If the timer expires b efore receiving the message, the pattern considers it as an error case. This pattern is a com bination of an unconrmed receiv er with a timer. As a general case of this pattern, w e can try to receiv e the S 1 T / A 2 / O 2 S 2 i n d i c a t i o n / r e s e t ( T ) A 3 / O 3 e 0 / s e t ( v T ) A 1 / O 1 S 3 S 0 t i m e d r e c e i v e r S 1 T [ c = N ] / A 3 / O 3 S 2 i n d i c a t i o n / r e s e t ( T ) A 4 / O 4 e 0 / s e t ( v T ) c : = 1 A 1 / O 1 S 3 S 0 t i m e d r e t r i a l r e c e i v e r T [ c < N ] / c : = c + 1 A 2 / O 2 Figure 3{32: P atterns timed receiv er and timed retrial receiv er in tended ev en t sev eral times, whic h is called timed retrial receiv er. Figure 3{32 represen ts the patterns. Note that it is also p ossible to ha v e patterns timed conrmed receiv er and timed conrmed retrial receiv er for conrmed message reception in timing constrain ts. Prop ert y sp ecication. The follo wing is a prop ert y applicable to the pattern timed receiv er.

PAGE 73

62 Prop ert y: The initial input ev en t e 0 m ust happ en ev en tually and it has to b e follo w ed b y either an in tended ev en t indication or a timeout T. L TL: e 0 ^ ( e 0 (( indication ^ : T ) ( : indication ^ T ))) In some cases, the indication could arriv e after T b ecause of ev en t dela y If a dela y ed deliv ery of an ev en t is not allo w ed in a system, w e can describ e this prop ert y using an absence prop ert y Prop ert y: After a timeout T, no indication can o ccur. L TL: ( T : indication ) or equiv alen tly ( T ( : indication )) F or the pattern timed retrial receiv er, w e ha v e to c hec k the n um b er of o ccurrences of timeout in addition to the ev en t existence and resp ondence. Prop ert y: The input ev en t e 0 is follo w ed b y either the ev en t indication or N times timeout. L TL: e 0 ^ ( e 0 (( indication ^ : ( T ^ ( c = N ))) ( : indication ^ ( T ^ ( c = N ))))) Prop ert y: After N-th timeouts, no timeout T exists. L TL: (1 c N ) or equiv alen tly (( T ^ ( c = N )) : T ) Example. In the A TM signaling proto col, an access switc h w aits for an ALER T message from a called part y in 10 seconds. If it fails to receiv e the message, it assumes that there is some problem with the called part y and pro ceeds to clear the call connection. See also. P attern Timer [ 76 ] 3.2.4.10 V arian t: timed conrmed sender and timed retrial conrmed sender In the pattern timed conrmed sender, a CEFSM requests a message transfer. Then it w aits for a conrmation message from its p eer within a certain time in terv al. If a timer expires b efore the reception, the sender considers it as an error or abnormal case. As a general case of this pattern, the sender retries the request

PAGE 74

63 un til it receiv es the conrmation or reac hes the maxim um n um b er of rep etition. The timed retrial conrmed sender retransmits the request at most N times. t i m e d c o n f i r m e d s e n d e r S 2 e 1 / s e t ( v T ) A 1 / r e q u e s t O 1 S 3 1 S 1 S T S 3 n T / A T / O T c o n f i r m 1 / r e s e t ( T ) A 2 1 / O 2 1 T [ c < N ] / c : = c + 1 s e t ( v T ) A 2 / r e q u e s t O 2 t i m e d r e t r i a l c o n f i r m e d s e n d e r S 2 e 1 / s e t ( v T ) c : = 1 A 1 / r e q u e s t O 1 S 3 1 S 1 S T S 3 n T [ c = N ] / A T / O T c o n f i r m 1 / r e s e t ( T ) A 2 1 / O 2 1 Figure 3{33: P atterns timed conrmed sender and timed retrial conrmed sender Prop ert y sp ecication. Prop ert y: The input ev en t e 1 has to o ccur ev en tually and the request follo ws the ev en t. L TL: ( e 1 ^ ( e 1 r eq uest )) Prop ert y: The request is alw a ys follo w ed b y one of the conrmation messages or timeout T. L TL: ( r eq uest (( T ^ ^ : conf ir m n ) _ ( : T ^ ^ conf ir m n ))) In the case of pattern timed retrial conrmed sender, w e also need to c hec k the n um b er of o ccurrences of timeout. Prop ert y: The request is follo w ed b y either one of conrmations or N times timeout. L TL: ( r eq uest (( T ^ ( c = N )) ^ ^ : conf ir m n ) _ ( : ( T ^ ( c = N )) ^ ^ conf ir m n )) Prop ert y: After N-th timer expiration, no timeout T exists. L TL: (1 c N ) or equiv alen tly (( T ^ ( c = N )) : T ) Example. As an example of timed conrmed sender, w e can consider ping command in UNIX whic h tests reac habilit y of a host using the In ternet

PAGE 75

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 ].

PAGE 76

CHAPTER 4 MODEL CHECKING P A TTERN-BASED DESIGN 4.1 Mo deling P attern-Based Design in Pr omela In our dev elopmen t metho dology the pattern-based design is follo w ed b y the v alidation of design sp ecication to nd errors in the design phase. The formal v alidation using Spin needs to construct a mo del for the design sp ecication and v alidate the mo del against the prop erties to b e satised in the design. Figure 4{1 sho ws an o v erview of Spin mo del c hec king for a pattern-based system. After R e q u i r e m e n t s A n a l y s i s a n d H i g h l e v e l D e s i g n p a s s C o u n t e r E x a m p l e M o d e l i n g i n P R O M E L A S P I N f a i l P r o p e r t i e s i n L T L Figure 4{1: Mo del c hec king pattern-based system using Spin the high-lev el designing, w e can construct the Pr omela mo del and obtain the correctness prop erties of the nal system. In this section, w e presen t a mo del construction mec hanism from the system design description and issues arising in the construction. 65

PAGE 77

66 A mo del that is consisten t with the design is essen tial to the subsequen t v alidation results b ecause an y violation in the mo del has to exactly rerect the same fault of the design. The corresp ondence b et w een our patterns and Pr omela mak es it simple to build a consisten t mo del of the design. The patterns are comp osed of blo c ks, comm unication paths, messages, dynamic creation of blo c k instance, states, transitions, predicates, rep etition, action list, state merge, timers, etc. Most comp onen ts of the patterns ha v e direct coun terparts in Pr omela By con v erting eac h comp onen t in to the corresp onding Pr omela construct, w e can build a mo del. A t the design phase, w e separate the mo deling in t w o steps for arc hitectural design and b eha vioral design. 4.1.1 Mo del Construction from P atterns 4.1.1.1 Mo deling arc hitectural design The main task in this step is to construct an outline of a mo del from arc hitectural comp onen ts. A blo c k is mapp ed to a pro cess declaration in proctype and an instance of the blo c k can b e created dynamically in the run op erator. A comm unication path b et w een blo c ks is implemen ted in a Pr omela c hannel chan that carries messages and their parameters. All input and output messages are dened b y sym b olic constan ts in mtype As an example of the mo del construction, w e d i a l ( d i g i t ) [ c = 9 ] / s t o r e d i g i t / c o n n r e q ( d i g i t s ) c o n n e c t i n g d i a l ( d i g i t ) [ c < 9 ] / s t o r e d i g i t c : = c + 1 ; / d i a l i n g ( b ) M E S S A G E S = d i a l c o n n r e q ; t o l o w e r f r o m c a l l e r P A T H S = f r o m c a l l e r : d i a l ; t o l o w e r : c o n n r e q ; c a l l e r n i n e d i g i t d i a l l o w e r ( a ) n i n e d i g i t d i a l Figure 4{2: Nine-digit dialing in call setup presen t a fragmen t of Pr omela co de for the arc hitecture of the nine-digit dialing as in Figure 4{2 (a). The blo c k nine digit dial reads a telephone n um b er comp osed of nine digits from an upp er la y er c al ler Then, it requests a connection c onn r e q

PAGE 78

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.

PAGE 79

68 The follo wing co de sho ws the nalized mo del of Figure 4{2 1 #define BUFFSIZE 2 /* channel capability */ 2 #define N 9 /* repetition number */ 3 #define DIGIT byte 4 typedef DIGITS {DIGIT ch[9];} 56 chan from_caller = [BUFFSIZE] of {mtype,DIGIT}; 7 chan to_lower = [BUFFSIZE] of {mtype,DIGITS}; 8 mtype = {dial,conn_req}; 9 10 proctype nine_digit_dial() 11 { 12 int c = 1; 13 DIGIT digit; 14 DIGITS digits; 1516 dialing: 17 from_caller?dial( di git ) -> 18 if 19 :: (c < N) -> 20 digits.ch[c-1] = digit; /* store digit */ 21 c = c + 1; 22 goto dialing; 2324 :: (c == N) -> 25 digits.ch[c-1] = digit; /* store the last digit */ 26 to_lower!conn_req (di gi ts ); 27 goto connecting; 28 fi; 29 connecting: skip; 30 } The mo deling is straigh tforw ard from the pattern-based design. Curren tly the mo deling is p erformed man ually Ho w ev er, it is b eliev ed that the con v ersion could b e p erformed automatically 4.1.2 Comm unication P ath and Channel Capacit y Channels dened b y chan are used to transfer data from one pro cess to another. A pro cess transfers data to other pro cesses through message c hannels. F or example, chan UNI2MAIN=[8] of f mtype,int,byte g declares a c hannel named UNI2MAIN that is able to store up to eigh t messages consisting of mtype int and byte elds.

PAGE 80

69 The c hannel capacit y is one of the imp ortan t issues in mo deling. Comm unication via a c hannel is either sync hronous (i.e., rendezv ous) or async hronous (i.e., buered) dep ending on the c hannel capacit y When w e sp ecify a comm unication path in design phase, w e did not care ab out the size of message queue. W e assumed that it has an unlimited size. In a Pr omela mo del, ho w ev er, a c hannel can store a nite n um b er of messages. F urthermore, increasing the c hannel capacit y could increase the state space dramatically T able 4{1 sho ws the memory and CPU usages for the dieren t buer size of the Pr omela mo del describ ed in Chapter 5.1 Note that the memory (1024M) reac hes its limit at the small c hange of c hannel T able 4{1: Eect of c hannel capabilit y on memory and CPU for ABP 1 7 : 3 6 5 ( s t o p p e d ) o v e r t h e l i m i t ( 1 0 2 4 M ) 5 7 5 8 9 2 e + 0 6 ( s t o p p e d ) 4 6 5 7 5 4 2 ( s t o p p e d ) 1 4 4 1 3 7 3 1 4 2 1 7 2 5 8 0 8 4 2 2 3 4 5 d e p t h r e a c h e d 1 2 0 1 0 4 8 0 8 0 s t a t e v e c t o r ( b y t e ) 7 : 5 9 3 5 9 7 4 3 9 2 8 9 6 9 2 e + 0 6 4 7 7 5 6 4 4 8 8 2 5 4 2 t o t a l m e m o r y ( M ) 4 6 5 1 8 0 0 r e a l t i m e ( s e c ) 3 9 7 3 5 1 2 4 3 1 1 5 4 s t a t e s s t o r e d 4 3 2 1 0 c h a n n e l s i z e size. A t ypical approac h w e ha v e used regarding the c hannel capacit y is to c hec k b oth sync hronous and async hronous comm unication all the times if it is p ossible. The results are quite dieren t in man y cases. W e start with the c hannel size zero for sync hronous comm unication and then increase it gradually When the v alidation cannot b e p erformed due to the state space explosion, w e use other tec hniques suc h as state-v ector compression and bit-state hashing. When a pro cess transfers a message, message elds sp ecied in a send or receiv e statemen t m ust ha v e the same n um b er of elds and eac h eld has to b e compatible with data t yp e as in c hannel declaration. One problem in implemen ting a comm unication path is that sev eral messages with dieren t denitions could b e passed through a single comm unication c hannel. As a simple solution of this problem, a c hannel can b e declared to b e wide enough to carry all messages on the

PAGE 81

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

PAGE 84

73 :: comm!ACK; /* reply with ACK */ :: skip -> comm!ACKLoss; /* indicate the message loss */ fi; 4.1.4 En vironmen t Pro cess A mo del to b e v alidated with Spin should b e a closed system. As a result, w e ha v e to pro vide an y missing parts of a whole system as w ell as the v alidation mo del itself [ 56 ]. If w e ha v e already dev elop ed these parts, this w ould pro vide a complete set for v alidation. Otherwise, w e ha v e to build them. F requen tly the abstracted en vironmen t is m uc h dicult than the mo del b ecause it is not w ell-designed and a dev elop er ma y not ha v e enough information for the en vironmen t. Moreo v er, it is necessary to iden tify whether an error has o ccurred in the mo del or in the en vironmen t. In our case, w e extract the exp ected b eha vior of the en vironmen t pro cesses from the design sp ecication to mak e the mo del. The follo wing presen ts one p ossible scenario of the en vironmen t pro cess for the example of nine-digit dial describ ed in Figure 4{2 1 proctype ENV () 2 { 3 byte count; 4 count = 1; 5 DIGITS callee_num; 67 do 8 :: (count < N) -> from_caller!dial (c oun t) ; 9 count = count + 1 10 :: (count == N) -> from_caller!dial (c oun t) ; 11 to_lower?conn_re q( cal le e_n um ); 12 break 13 od; 14 } 4.2 Prop ert y Sp ecication After Spin has c hec k ed ob vious initial design ra ws suc h as system deadlo c ks and unreac hable co de and these problems ha v e b een corrected, the system mo del is v eried against system requiremen ts [ 44 ] sp ecied using temp oral logic. One imp ortan t issue in this stage is to iden tify requiremen ts or prop erties to b e v eried. If suc h requiremen ts sp ecication is not clear or do es not exist, it is dicult or imp ossible to determine the prop erties to b e c hec k ed. Th us, the iden tication of

PAGE 85

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

PAGE 89

78 m e s s a g e s = P U T ( d ) G E T ( d ) D A T A r e q ( d ) D A T A i n d ( d ) A C K r e q A C K i n d ; L O 2 S N D S N D 2 L O U P 2 S N D p a t h s = U P 2 S N D : P U T ; R C V 2 U P : G E T ; S N D 2 L O : D A T A r e q ; L O 2 R C V : D A T A i n d ; R C V 2 L O : A C K r e q ; L O 2 S N D : A C K i n d ; L O 2 R C V R C V 2 L O R C V 2 U P s e n d e r u p p e r l a y e r l o w e r l a y e r r e c e i v e r Figure 5{1: Structure of ABP using split proto col la y er 5.1.2 Beha vioral Design In this section, w e describ e the execution of the blo c ks presen ted at the structural design. Note that this section illustrates the pro cess of using Spin step b y step. The conrmation for a D A T A transfer in the ABP la y er mak es the blo c ks sender and receiv er to b e describ ed in the patterns conrmed sender and conrmed receiv er. One immediate problem that one can meet from the design is that the sender can w ait for an A CK forev er if a message is lost at the lo w er la y er. T o a v oid the un b ounded w aiting, a timer is added to the sender so that it can b e implemen ted in the pattern timed conrmed sender. Figure 5{2 presen ts the initial b eha vior of the proto col. F rom the patterns, w e can construct the b eha vior part s e n d e r w a i t a c k A C K i n d / r e s e t ( T ) / r e a d y r e c e i v e r D A T A i n d ( d ) / / A C K r e q G E T ( d ) w a i t d a t a P U T ( d ) / s e t ( v T ) / D A T A r e q ( d ) T / s e t ( v T ) / D A T A r e q ( d ) Figure 5{2: Initial description of ABP b eha vior of Pr omela mo del and capture sev eral correctness requiremen ts to b e c hec k ed for the proto col. The follo wing is the list of the prop erties: Prop ert y 1 The ev en t PUT has to b e receiv ed ev en tually and DATA_req follo ws it.

PAGE 90

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

PAGE 92

81 ignores the message b ecause the alternate bit is not what it exp ects. Th us, this situation results in consecutiv e loss of t w o D A T A messages. T racing of this error is quite long and hard to nd, but Spin mak es it p ossible to nd this kind of error. T o x the problem, the sender has to w ait for an A CK that con tains the same bit as the alternate bit b eing sen t. If the sender receiv es the w an ted A CK, it rips the alternate bit and sends the next D A T A. The c hec king for the con trol bit of A CK can also b e ac hiev ed b y in tro ducing predicates to insp ect the bit. The up dated description of ABP b eha vior is sho wn in Figure 5{3 where d, a, e, b, c means data, alternate bit, exp ected bit, con trol bit, and coun ter, resp ectiv ely s e n d e r w a i t a c k A C K i n d ( b ) [ a = b ] / a : = a r e s e t ( T ) / r e a d y r e c e i v e r D A T A i n d ( d a ) [ a = e ] / e : = e / A C K r e q ( a ) G E T ( d ) w a i t d a t a P U T ( d ) / s e t ( v T ) / D A T A r e q ( d a ) T [ c < N ] / s e t ( v T ) c : = c + 1 / D A T A r e q ( d a ) D A T A i n d ( d a ) [ a = e ] / / A C K r e q ( a ) A C K i n d ( b ) [ a = b ] / s e t ( v T ) / D A T A r e q ( d a ) f i n i s h e d T [ c = N ] / e r r o r / Figure 5{3: Final description of ABP b eha vior V alidation for the up dated mo del sho ws that the design is error-free for the correctness prop erties. W e, therefore, can go to the next dev elopmen t phase. App endix A presen ts the Pr omela mo del of Figure 5{1 and Figure 5{3 It also includes the prop erties c hec k ed at the nal v alidation. Mean while this case study sho ws the p ossibilit y of a new pattern construction from the curren t pattern language. Actually the ABP is a common proto col at the comm unication systems. Therefore, w e register the CEFSMs describ ed in Figure 5{3 as new patterns with the names of ABP sender and ABP r e c eiver

PAGE 93

82 5.2 Case Study: A TM UNI Signaling Proto col 5.2.1 Proto col Ov erview A TM signaling [ 65 80 81 ] is a connection-orien ted proto col and dynamic b eha vior for connection setup and release is ac hiev ed b y signaling, an exc hange of con trol information in a comm unication net w ork. It is broadly classied b y t w o in terfaces: User-Net w ork In terface (UNI) and Net w ork-No de In terface (NNI). UNI signaling sp ecies in teractions b et w een an A TM end system and an A TM access switc h, while NNI is used b et w een switc hes within an A TM net w ork. Our case study is dev oted to the dev elopmen t of UNI signaling, but the metho d can b e similarly used for NNI signaling. There are man y standards for A TM UNI signaling suc h as Q.2931 [ 82 ], Q.2971 [ 83 ], UNI 3.1 [ 84 ], and UNI 4.0 [ 85 ] from the ITU-T and the A TM-F orum. The standards dene a set of capabilities, messages, and pro cedures for user connections. Stiller [ 86 ] surv ey ed commonalities and dierences b et w een the standards. Our case study is based on the ITU-T's Q.2931. Figure 5{4 depicts the A TM signaling proto col stac k [ 81 ]. The stac k consists of S i g n a l i n g L a y e r 3 S A A L A A L S S C F S S C O P A T M L a y e r P h y s i c a l L a y e r Figure 5{4: Proto col stac k for signaling in A TM con trol plane the signaling la y er 3 or signaling proto col la y er, the signaling A TM adaptation la y er (SAAL), the A TM la y er, and the ph ysical la y er. The signaling la y er 3 has dieren t functions dep ending on the in terface o v er whic h it is b eing used. The UNI signaling proto col la y er establishes, main tains, and releases user connections for incoming

PAGE 94

83 and outgoing calls. Either user applications or switc h functions suc h as routing, call admission con trol and managemen t can b e lo cated on top of the la y er [ 65 ]. SAAL pro vides reliable transfer of signaling messages b et w een instances of signaling la y er 3. It adapts the proto col data unit of a signaling la y er to A TM cells. The la y er has sev eral subla y ers suc h as service sp ecic co ordination function (SSCF), service sp ecic connection orien ted proto col (SSCOP), and A TM adaptation la y er (AAL). The SAAL functions are accessed b y the signaling la y er 3 through AAL service access p oin ts. SSCF supplies a mapping function b et w een SSCOP and signaling la y er 3. It simplies the upp er la y er in terface of SAAL with regard to SSCOP There are t w o kinds of SSCF, an SSCF at UNI [ 66 ] and an SSCF at NNI [ 87 ], b ecause the needs of signaling la y er 3 are dieren t at eac h in terface. SSCOP [ 88 ] implemen ts a reliable transp ort proto col whic h sends signaling messages using sequence n um b ers, ac kno wledgmen ts, and retransmissions to ensure an error-free sequence deliv ery The AAL subla y er is used b y SSCOP to send and receiv e AAL messages to the A TM la y er. T ypically this la y er is implemen ted in hardw are for p erformance reason. Both A TM la y er and ph ysical la y er are also implemen ted in hardw are. The SSCOP and SSCF la y ers are usually in soft w are and are often referred to as SAAL [ 81 ]. Recall that an A TM connection has three phases: establishmen t, data transfer, and release. During the establishmen t phase, an end system negotiates connection c haracteristics with a net w ork. The connection is cleared during the release phase after data is exc hanged. Figure 5{5 sho ws a t ypical message ro w for an A TM connection [ 65 81 ]. T o establish a connection, a calling part y sends out an SETUP message to an A TM net w ork. The message con tains lo w er la y er parameters, called part y address, qualit y of service requiremen ts, and other information needed for the connection. The message is receiv ed at an access switc h of an A TM net w ork. After c hec king the a v ailabilit y of resources, the switc h ma y ac kno wledge the reception

PAGE 95

84 C a l l i n g P a r t y A T M N e t w o r k S E T U P S E T U P C A L L P R O C C A L L P R O C C O N N C O N N C O N N A C K C O N A C K R E L R E L R E L C O M P R E L C O M P A L E R T A L E R T T 3 0 3 T 3 1 0 T 3 0 1 T 3 0 8 C a l l e d P a r t y Figure 5{5: Message ro w for connection establishmen t and release

PAGE 96

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

PAGE 97

86 an A TM access switc h. In this case study w e consider only the switc h side of the proto col. Ho w ev er, the b eha vior of an end system can b e similarly obtained. 5.2.2 Structural Design An A TM access switc h has t w o distinct functions to deal with a calling part y and a called part y This separation of functionalit y leads the switc h to b e designed in the pattern split dynamic handler as sho wn in Figure 5{6 The blo c k con tains M A I N C C ( 1 1 ) O R G C C ( 0 N ) T E R M C C ( 0 N ) P A T H S = U N I 2 M A I N : S E T U P ; O R G 2 M A I N : S E T U P i n t T E R M I N A T E ; M A I N 2 O R G : S E T U P ; T E R M 2 M A I N : T E R M I N A T E ; M A I N 2 T E R M : S E T U P i n t ; O R G 2 T E R M : R E L i n t ; T E R M 2 O R G : A L E R T i n t C O N N i n t R E L i n t ; U N I 2 O R G : C O N N A C K R E L R E L C O M P ; U N I 2 T E R M : C A L L P R O C A L E R T C O N N R E L R E L C O M P ; O R G 2 U N I : C A L L P R O C A L E R T C O N N R E L R E L C O M P ; T E R M 2 U N I : S E T U P C O N N A C K R E L R E L C O M P ; U N I 2 M A I N M A I N 2 T E R M T E R M 2 M A I N T E R M 2 U N I U N I 2 T E R M U N I 2 O R G O R G 2 U N I M A I N 2 O R G O R G 2 M A I N O R G 2 T E R M T E R M 2 O R G M E S S A G E S = S E T U P C A L L P R O C A L E R T C O N N C O N N A C K R E L R E L C O M P T E R M I N A T E S E T U P i n t A L E R T i n t C O N N i n t R E L i n t ; Figure 5{6: Arc hitecture of connection con trol blo c k using split dynamic handler three in ternal blo c ks: MAIN CC to administrate calls, OR G CC to handle outgoing calls or originating calls, and TERM CC to handle incoming calls or terminating calls. The pattern also needs the denition of comm unication paths and messages b et w een the blo c ks. A static instance MAIN CC creates instances of OR G CC and TERM CC dep ending on the messages receiv ed. When a calling part y tries a new call, the SETUP request comes to the MAIN CC from the lo w er la y er through the path UNI2MAIN. Up on receiving the message, MAIN CC creates an instance of OR G CC to handle the originating call. The signaling messages b et w een a calling part y and the instance ro ws through the comm unication paths UNI2OR G and OR G2UNI via the lo w er la y er of the proto col. T o connect the call to a called part y it is necessary for the instance to inform the called part y of the arriv al of a new

PAGE 98

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

PAGE 100

89 is p erformed using the SETUP .in t. F rom the pattern used in the design, w e are S E T U P / s t a t u s : = c h e c k a v a i l a b i l i t y / c a l l i n i t i a t e d n u l l o u t c a l l p r o c e e d [ s t a t u s = O K ] / r e s o u r c e a l l o c / C A L L P R O C S E T U P i n t [ s t a t u s = N O K ] / / R E L C O M P T E R M I N A T E A L E R T i n t / / A L E R T o u t c a l l p r o c e e d c a l l d e l i v e r e d ( a ) C O N N i n t / / C O N N ( b ) C O N N A C K / / c a l l d e l i v e r e d a c t i v e c a l l d e l i v e r e d ¢ ( c ) R E L / r e l r s c / R E L C O M P R E L i n t T E R M I N A T E Figure 5{8: Beha vior of OR G CC for SETUP ALER T, and CONN able to capture the prop erties to b e c hec k ed in v alidation phase. The input ev en t SETUP has to b e follo w ed b y either CALL PR OC or REL COMP Moreo v er, other ev en ts in the blo c k cannot pro ceed SETUP b ecause it is the rst ev en t to ha v e happ ened in the blo c k. Unconrmed sender for ALER T. After handling the message SETUP the blo c k OR G CC w aits for an in ternal message ALER T.in t from a TERM CC from whic h it kno ws that a called part y is b eing alerted. Then, it transfers the message ALER T to the calling part y This b eha vior can b e designed in unconrmed sender. The corresp onding calling part y uses timed receiv er to handle it. Figure 5{8 (b) represen ts the b eha vior. W e can extract an existence and resp onse prop ert y of ALER T from the pattern prop ert y section. Conrmed sender for CONN. After the ALER T message, the called part y noties the connection establishmen t using the in ternal message CONN.in t. F or the ev en t, OR G CC transfers the message CONN to the calling part y and then it w aits for a resp onse from the calling part y There are t w o p ossibilities, either CONN A CK or REL, from the part y This b eha vior can b e ac hiev ed using the pattern conrmed sender, whereas the calling part y uses timed conrmed receiv er to handle it. Figure 5{8 (c) sho ws the b eha vior. The detailed description

PAGE 101

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

PAGE 102

91 S E T U P i n t / s e t ( 4 T 3 0 3 ) c : = 1 / S E T U P T 3 0 3 [ c < 2 ] / c : = c + 1 s e t ( 4 T 3 0 3 ) / S E T U P T 3 0 3 [ c = = 2 ] / r e s o u r c e r e l e a s e / R E L i n t T E R M I N A T E C A L L P R O C / r e s o u r c e a l l o c a t i o n r e s e t ( T 3 0 3 ) / c a l l p r e s e n t i n c a l l p r o c e e d R E L C O M P / r e s e t ( T 3 0 3 ) r e s o u r c e r e l e a s e / R E L i n t T E R M I N A T E n u l l Figure 5{9: Beha vior of TERM CC for SETUP message the CALL PR OC. If the blo c k fails to receiv e the exp ected ev en t ALER T in the giv en time in terv al, it releases the connection and clears the call to w ards b oth the calling and called parties. The pattern timed receiv er is a go o d candidate for the b eha vior as sho wn in Figure 5{10 (a). Note that the initialization of the timer m ust b e done prior to the state inc al l pr o c e e d The initialization is p erformed during the transition from c al l pr esent to inc al l pr o c e e d b ecause it is a unique transition coming to the state. T 3 1 0 / c a l l c l e a r s e t ( 3 0 T 3 0 8 ) c : = 1 / R E L R E L i n t A L E R T / r e s e t ( T 3 1 0 ) / A L E R T i n t c a l l r e c e i v e d r e l e a s e i n d i c a t i o n / s e t ( 1 0 T 3 1 0 ) / c a l l p r e s e n t i n c a l l p r o c e e d T 3 0 1 / c a l l c l e a r s e t ( 3 0 T 3 0 8 ) c : = 1 / R E L R E L i n t C O N N / r e s e t ( T 3 0 1 ) / C O N N A C K C O N N i n t a c t i v e r e l e a s e i n d i c a t i o n / s e t ( 1 8 0 T 3 0 1 ) / i n c a l l p r o c e e d c a l l r e c e i v e d ( a ) ( b ) Figure 5{10: Beha vior of TERM CC for ALER T and CONN Timed conrmed receiv er for CONN. The blo c k TERM CC turns on the timer T301 to measure the reception of the message CONN after the ALER T. When the called part y is ready to connect the call, it sends a connection

PAGE 103

92 message CONN to the calling side. Up on receiving the CONN, TERM CC stops T301 and replies to the called part y with CONN A CK. Then, it forw ards the in ternal message CONN.in t to OR G CC to indicate that the connection is accepted. If the blo c k fails to receiv e the exp ected ev en t CONN in the giv en time in terv al, it releases the connection and clears the call. This b eha vior can b e implemen ted in the pattern timed conrmed receiv er as giv en in Figure 5{10 (b). The corresp onding called part y uses timed conrmed sender to handle these messages. The blo c k has the prop ert y that it has to resp onse with CONN A CK or T301 for the CONN message. T o get an en tire b eha vior of TERM CC, the CEFSMs of Figure 5{9 and 5{10 should b e comp osed with sequen tial merge as OR G CC. As a result, the blo c k has to tak e an input ev en t SETUP .in t and then cease to exist b y timers or REL COMP message. Otherwise, it m ust sta y at the active state after handling CONN. 5.2.3.4 Call/Connection Release F or the connection release, eac h blo c k of OR G CC and TERM CC has the same functionalit y There are t w o cases in the connection release. Conrmed receiv er for lo cal part y REL. Up on receiving a REL message initiated from a lo cal part y the access switc h releases resource allo cated for the call and replies with REL COMP to the part y This is an instan tiation of the pattern a c t i v e R E L / r e l e a s e r e s o u r c e / R E L C O M P R E L i n t T E R M I N A T E T 3 0 8 [ c = = 2 ] / / T E R M I N A T E r e l e a s e i n d i c a t i o n R E L C O M P / r e s e t ( T 3 0 8 ) / T E R M I N A T E R E L i n t r e l e a s e r e s o u r c e s e t ( 3 0 T 3 0 8 ) c : = 1 / R E L T 3 0 8 [ c < 2 ] / c : = c + 1 s e t ( 3 0 T 3 0 8 ) / R E L r e q a c t i v e ( a ) ( b ) Figure 5{11: Call clearing for an A TM connection

PAGE 104

93 conrmed receiv er. Figure 5{11 (a) sho ws the handling of connection release at OR G CC and TERM CC. Subsequen tly the instance informs the remote part y that the call is released using the in ternal message REL.in t. The remote part y uses timed retrial conrmed sender to handle it as presen ted b elo w. F rom the design w e can extract the prop ert y that REL is follo w ed b y REL COMP and terminates after it. Timed retrial conrmed sender for remote part y REL. Figure 5{11 (b) sho ws the situation where the ev en t REL.in t happ ens from the remote instance. The net w ork side initiates call clearing b y sending REL to the lo cal part y and starts timer T308. Then, it w aits for REL COMP from the part y If it receiv es the message, the net w ork instance stops the timer and completes the connection. F or the timer expiration, it can try again. F or the secondary expiration, the net w ork places the connection in a main tenance condition and terminates it [ 80 ]. This b eha vior is an instance of pattern timed retrial conrmed sender. F rom the design, w e can extract the prop ert y that the REL is follo w ed b y either REL COMP or T308 at most t wice. 5.2.4 V alidation of P attern-based Design In this subsection, w e presen t the mo del construction and v alidation of the A TM UNI signaling proto col design. 5.2.4.1 Mo del Construction in Pr omela By con v erting the arc hitectural design of Figure 5{6 to the corresp onding Promela constructs, w e can obtain an outline of the v alidation mo del as follo ws: #define BUFFSIZE 2 /* Channel size. Changeable. */ /* message declaration */ mtype = {SETUP, CALL_PROC, ALERT, CONN, CONN_ACK, REL, REL_COMP, TERMINATE, SETUP_int, ALERT_int, CONN_int, REL_int}; /* channel declaration */ chan UNI2MAIN = [BUFFSIZE] of {mtype, Para}; chan ORG2MAIN = [BUFFSIZE] of {mtype, Para}; chan MAIN2ORG = [BUFFSIZE] of {mtype, Para};

PAGE 105

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 )).

PAGE 107

96 Prop ert y 2 The in ternal ev en t SETUP .in t has to o ccur ev en tually and it is follo w ed b y the transferring of SETUP .in t to the newly created TERM CC. L TL: S E T U P :int ^ ( S E T U P :int ( SETUP.int to TERM CC )). Prop ert y 3 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 situation. L TL: ( S E T U P ( T E R M I N AT E )). Prop ert y 4 The ev en t SETUP has to o ccur ev en tually to initiate the b eha vior and b e follo w ed b y either CALL PR OC or REL COMP L TL: S E T U P ^ ( S E T U P (( CALL PR OC ^ : REL COMP ) ( : CALL PR OC ^ REL COMP ))). Prop ert y 5 Because the SETUP is the rst ev en t to ha v e happ ened in the blo c k, other ev en ts cannot pro ceed it in this blo c k. L TL: ( : e o ) ( : e o U S E T U P ), where e o means all other ev en ts of the blo c k except SETUP Prop ert y 6 The in ternal ev en t ALER T.in t has to exist and ALER T follo ws it. L TL: ALE R T :int ^ ( ALE R T :int ALE R T ). Prop ert y 7 CONN.in t has to o ccur ev en tually and CONN subsequen tly follo ws the ev en t. L TL: ( C O N N :int ^ ( C O N N :int C O N N )). Prop ert y 8 CONN resp onds b y one of the conrmation messages REL or CONN A CK. L TL: ( C O N N (( R E L ^ : CONN A CK ) ( : R E L ^ CONN A CK ))). Prop ert y 9 SETUP has to b e follo w ed b y reception of REL COMP REL, or CONN A CK.

PAGE 108

97 L TL: ( S E T U P (( REL COMP ^ : R E L ^ : CONN A CK ) ( : REL COMP ^ R E L ^ : CONN A CK ) ( : REL COMP ^ : R E L ^ CONN A CK ))). Prop ert y 10 The input ev en t S E T U P :int has to o ccur ev en tually and b e resp onded b y SETUP L TL: ( S E T U P :int ^ ( S E T U P :int S E T U P )). Prop ert y 11 SETUP is follo w ed b y one of conrmations or t w o times timeout of T303.L TL: ( S E T U P ((( T 303 ^ ( c = 2)) ^ : REL COMP ^ : CALL PR OC ) ( : ( T 303 ^ ( c = 2)) ^ REL COMP ^ : CALL PR OC ) ( : ( T 303 ^ ( c = 2)) ^ : REL COMP ^ CALL PR OC ))), where c denotes the n um b er of timeout. Prop ert y 12 After second timeouts, no timeout T303 exists. L TL: ( c 2), where c denotes the n um b er of timeout. Prop ert y 13 CALL PR OC has to b e follo w ed b y either the in tended message ALER T or a timeout T310. L TL: ( CALL PR OC (( ALE R T ^ : T 310) ( : ALE R T ^ T 310))). Prop ert y 14 ALER T has to b e follo w ed b y either the in tended message CONN and CONN A CK or a timeout T301. L TL: ( ALE R T (( C O N N ^ : T 301) ( : C O N N ^ T 301))). Prop ert y 15 F or the SETUP .in t, the blo c k TERM CC cease to exist or sta y at the active state after handling CONN. L TL: ADDME L TL HERE! Prop ert y 16 The input ev en t REL has to o ccur ev en tually and it is follo w ed b y the o ccurrence of REL COMP L TL: R E L ^ ( R E L REL COMP ).

PAGE 109

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.

PAGE 113

APPENDIX A MODELING OF AL TERNA TE BIT PR OTOCOL IN PR OMELA #define BUFFSIZE 1 #define N 3 /* number of iteration for timeout retrial */ #define MAX 4 /* maximum sequence number for DATA */ #define message byte #define timer bool /* message declarations */ mtype = {PUT, GET, DATA_req, DATA_ind, ACK_req, ACK_ind}; /* channel declaration */ chan SND2LO = [BUFFSIZE] of {mtype, byte, bit}; /* DATA_req */ chan LO2RCV = [BUFFSIZE] of {mtype, byte, bit}; /* DATA_ind */ chan RCV2LO = [BUFFSIZE] of {mtype, bit}; /* ACK_req */ chan LO2SND = [BUFFSIZE] of {mtype, bit}; /* ACK_ind */ chan UP2SND = [BUFFSIZE] of {mtype, byte}; /* PUT */ chan RCV2UP = [BUFFSIZE] of {mtype, byte}; /* GET */ /* PID of processes which are used for validation */ byte P_sender; byte P_receiver; byte P_UPPER; proctype sender() { message d; /* DATA field */ bit a; /* alternate bit */ bit b; /* control bit for ACK */ timer T = false; /* timer. Initially deactivated. */ byte c; /* counter for iteration */ wait_data:end: if:: UP2SND?PUT(d) -> PUT_rcv: /* label for validation */ T = true; c = 1; SND2LO!DATA_req(d ,a ); DATA_req_snt: /* label for validation */ goto wait_ack; fi; wait_ack: if 102

PAGE 114

103 :: LO2SND?ACK_ind(b ) -> if:: a == b -> /* expected ACK */ ACK_ind_rcv: /* label for validation */ a = !a; /* toggle the alternate bit for next DATA*/ T = false; /* timer reset() */ goto wait_data; :: a != b -> T = true; /* timer set again */ SND2LO!DATA_req (d, a) ; goto wait_ack; fi; :: T -> /* timer expiration */ if:: c < N -> c = c + 1; T = true; SND2LO!DATA_req (d, a) ; goto wait_ack :: c == N -> T_rcv: /* N times timeout */ printf ("ERROR: SO MANY DATA LOST\n"); fi; fi; } /* end of "sender()" */ proctype receiver() { bit e = 0; /* expected bit */ bit a; /* alternate bit */ message d; /* DATA field */ ready:end: LO2RCV?DATA_ind(d ,a ) -> if:: (a == e) -> DATA_ind_rcv: /* label for property validation */ e = !e; RCV2LO!ACK_req( a); ACK_req_snt: /* label for property validation */ RCV2UP!GET(d); GET_snt: /* label for property validation */ goto ready; :: (a != e) -> /* duplicated DATA */ RCV2LO!ACK_req( a); goto ready; fi; } /* end of "receiver()" */ proctype UPPER()

PAGE 115

104 { message s; /* sending DATA */ message r; /* receiving DATA */ message e; /* expected DATA */ idle:end: do:: atomic { UP2SND!PUT(s); PUT_snt: /* label for validation */ s = (s+1) % MAX } :: atomic { RCV2UP?GET(r); GET_rcv: /* label for validation */ assert (r == e); /* checking the alternativity of Property 6 */ e = (e+1) % MAX } od } /* end of "UPPER()" */ proctype LOWER() { message d; bit a; bit b; idle:end: do:: SND2LO?DATA_req( d,a ) -> if:: LO2RCV!DATA_ind( d,a ); /* proper DATA transfer */ :: skip; /* lost DATA */ fi :: RCV2LO?ACK_req(b ) -> if:: LO2SND!ACK_ind(b ); /* proper ACK transfer */ :: skip; /* lost ACK */ fi od } /* end of "LOWER()" */ init{ atomic{ P_sender = run sender(); P_receiver = run receiver(); P_UPPER = run UPPER(); run LOWER() } }

PAGE 116

105 The follo wing en umerates the prop erties c hec k ed during the v alidation step for the Pr omela mo del. Prop ert y 1 The ev en t PUT has to b e receiv ed ev en tually and DATA_req follo ws it. 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 with (a = b) or N times timeout. L TL: ( p (( q ^ : r ) ( : q ^ r ))) where p q and r denote the transfer of DATA_req reception of ACK_ind with (a = b), and N times timeout of timer T, resp ectiv ely Prop ert y 3 Reception of DATA_ind has to o ccur ev en tually or N times timeout should happ en. L TL: ( p q ) where p and q means the reception of DATA_ind and N times timeout. Prop ert y 4 If the DATA_ind is receiv ed and a is equal to e at that time, 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 with (a = e), 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

PAGE 117

APPENDIX B MODELING OF A TM UNI SIGNALING PR OTOCOL IN PR OMELA #define BUFFSIZE 4 /* Size of message buffer */ #define timer bool /* Symbols */ #define OK 1 #define NOK 0 /* message declarations */ mtype = {SETUP, CALL_PROC, ALERT, CONN, CONN_ACK, REL, REL_COMP, TERMINATE, SETUP_int, ALERT_int, CONN_int, REL_int}; /* parameter repository. All parameters are included in the structure */ typedef Para { byte calling_addr; /* keep the calling party address */ byte called_addr; /* keep the called party address */ byte org_addr; /* keep the ORG_CC address */ byte term_addr; /* keep the TERM_CC address */ }/* Channel Declaration. */ chan UNI2MAIN = [BUFFSIZE] of {mtype, Para}; chan ORG2MAIN = [BUFFSIZE] of {mtype, Para}; chan MAIN2ORG = [BUFFSIZE] of {mtype, byte, Para}; chan TERM2MAIN= [BUFFSIZE] of {mtype, Para}; chan MAIN2TERM= [BUFFSIZE] of {mtype, byte, Para}; chan ORG2TERM = [BUFFSIZE] of {mtype, byte, Para}; chan TERM2ORG = [BUFFSIZE] of {mtype, byte, Para}; chan UNI2ORG = [BUFFSIZE] of {mtype, byte, Para}; chan UNI2TERM = [BUFFSIZE] of {mtype, byte, Para}; chan ORG2UNI = [BUFFSIZE] of {mtype, byte, Para}; chan TERM2UNI = [BUFFSIZE] of {mtype, byte, Para}; byte ADDR = 1; /* Used for a unique number generation for addressing */ /* Used for property validation. Keep the PID of each instance. */ byte P_MAIN_CC; byte P_ORG_CC; byte P_TERM_CC; /* Main Call Control Block */ proctype MAIN_CC() { Para para; 106

PAGE 118

107 main_wait:end_MAIN_CC: do:: UNI2MAIN?SETUP(p ara ) -> SETUP_rcv: /* label for property check */ d_step { /* distribute a unique address */ para.org_addr = ADDR; ADDR = ADDR + 1; }P_ORG_CC = run ORG_CC(para.org_ ad dr ); /** save instance id **/ MAIN2ORG!SETUP(p ara .o rg _ad dr para); :: ORG2MAIN?SETUP_i nt( pa ra ) -> SETUP_int_rcv: /* label for property check */ d_step { para.term_addr = ADDR; ADDR = ADDR + 1; }P_TERM_CC = run TERM_CC(para.term _a ddr ); /** save instance id **/ MAIN2TERM!SETUP_ int (p ar a.t er m_a dd r, para); :: ORG2MAIN?TERMINA TE( pa ra ); TERMINATE_rcv: /* label for property check */ /** delete instance id **/ skip; :: TERM2MAIN?TERMIN ATE (p ar a); T_TERMINATE_rcv: /* label for property check */ /** delete instance id **/ skip; od; } /* end of "MAIN_CC()" */ /* Originating Call Control Block */ proctype ORG_CC(byte org_addr) { Para para; bit status; byte c; timer T308 = false; null: MAIN2ORG?SETUP(ev al (or g_ ad dr) para); O_SETUP_rcv: /* status := "check availability" random selection of status value in the model */ if:: status = OK;

PAGE 119

108 :: status = NOK; fi; call_initiated: if:: (status == NOK) -> ORG2UNI!REL_COMP (pa ra .c all in g_a dd r, para); O_REL_COMP_snt: skip; /* label for property check */ ORG2MAIN!TERMINA TE( pa ra ); O_TERM1_snt: skip; /* label for property check */ goto finished; :: (status == OK) -> /** resource allocation **/ /* CALL_PROC to the calling party */ ORG2UNI!CALL_PRO C(p ar a. cal li ng_ ad dr para); O_CALL_PROC_snt: skip;/* label for property check */ /* SETUP_int to MAIN_CC. */ ORG2MAIN!SETUP_i nt( pa ra ); goto outcall_proceed; fi; outcall_proceed: if:: /* ALERT_int from TERM_CC */ TERM2ORG?ALERT_i nt( ev al (or g_ add r) para); /* ALERT to calling party */ ORG2UNI!ALERT(pa ra. ca ll ing _a ddr para); O_ALERT_snt: skip;/* label for property check */ goto call_delivered; :: /* connection release due to T310 */ TERM2ORG?REL_int (ev al (o rg_ ad dr) para); /** release resource **/ T308 = true; c = 1; /* REL to calling party */ ORG2UNI!REL(para .ca ll in g_a dd r, para); goto release_indicati on ; fi; call_delivered: if:: /* CONN_int from TERM_CC */ TERM2ORG?CONN_in t(e va l( org _a ddr ), para); /* CONN to calling party */

PAGE 120

109 ORG2UNI!CONN(par a.c al li ng_ ad dr, para); O_CONN_snt: goto call_delivered_p ri me; :: /* connection release due to T301 */ TERM2ORG?REL_int (ev al (o rg_ ad dr) para); /** release resource **/ T308 = true; c = 1; /* REL to calling party */ ORG2UNI!REL(para .ca ll in g_a dd r, para); goto release_indicati on ; fi; call_delivered_p ri me: if:: /* connection release from calling party */ UNI2ORG?REL(eval (or g_ ad dr) para); /** release resource **/ /* REL_COMP to calling party */ ORG2UNI!REL_COMP (pa ra .c all in g_a dd r, para); /* REL_int to TERM_CC. Need to check a clear collision. */ if:: TERM2ORG?REL_int (e va l(o rg _ad dr ), para); :: timeout -> ORG2TERM!REL_int( pa ra .te rm _ad dr para); fi;/* finishing */ ORG2MAIN!TERMINA TE( pa ra ); goto finished; :: /* CONN_ACK from calling party */ UNI2ORG?CONN_ACK (ev al (o rg_ ad dr) para); O_CONN_ACK_rcv: skip; /* label for property check */ goto call_active; fi; call_active: if:: /* REL from calling party */ UNI2ORG?REL(eval (or g_ ad dr) para); /** release resource **/ /* REL_COMP to calling party */ ORG2UNI!REL_COMP (pa ra .c all in g_a dd r, para); /* REL_int to TERM_CC. Need to check a clear collision. */ if:: TERM2ORG?REL_int (e va l(o rg _ad dr ), para); :: timeout -> ORG2TERM!REL_int( pa ra .te rm _ad dr para); fi;

PAGE 121

110 /* finishing */ ORG2MAIN!TERMINA TE( pa ra ); goto finished; :: TERM2ORG?REL_int (ev al (o rg_ ad dr) para); /** release resource **/ T308 = true; c = 1; /* REL to calling party */ ORG2UNI!REL(para .ca ll in g_a dd r, para); goto release_indicati on ; fi; release_indicati on : if:: /* T308 handling */ (T308 == true) && (timeout) -> if:: (c < 2) -> c = c+1; T308 = true; /* the timer set again. */ goto release_indicat ion ; :: (c == 2) -> ORG2MAIN!TERMIN ATE (p ara ); goto finished; fi; :: UNI2ORG?REL_COMP (ev al (o rg_ ad dr) para); T308 = false; ORG2MAIN!TERMINA TE( pa ra ); :: /* Handle the clear collision */ UNI2ORG?REL(eval (or g_ ad dr) para); ORG2MAIN!TERMINA TE( pa ra ); goto finished; fi; finished: skip; } /* end of "ORG_CC()" */ /* Terminating Call Control Block */ proctype TERM_CC(byte term_addr) { Para para; byte c; timer T303 = false; timer T310 = false; timer T308 = false; timer T301 = false;

PAGE 122

111 null: MAIN2TERM?SETUP_i nt (ev al (t erm _a ddr ), para); T_SETUP_int_rcv: skip; /* for property check */ /* create a corresponding called party here */ d_step { para.called_add r = ADDR; ADDR = ADDR + 1; }run Called_Party(pa ra. ca ll ed_ ad dr) ; T303 = true; c = 1; /* SETUP to called party to initiate connection */ TERM2UNI!SETUP(pa ra .ca ll ed _ad dr para); */ goto call_present; call_present: if:: (T303 == true) && (timeout) -> if:: (c < 2) -> c = c+1; T303 = true; goto call_present; :: (c == 2) -> /** release resource **/ TERM2ORG!REL_in t(p ar a.o rg _a ddr para); TERM2MAIN!TERMI NAT E( par a) ; goto finished; fi; :: UNI2TERM?REL_COM P(e va l( ter m_ add r) para); T308 = false; /** release resource **/ TERM2ORG!REL_int (pa ra .o rg_ ad dr, para); TERM2MAIN!TERMIN ATE (p ar a); goto finished; :: UNI2TERM?CALL_PR OC( ev al (te rm _ad dr ), para); /** resource allocation **/ T303 = false; T310 = true; goto incall_proceed; fi; incall_proceed: if:: (T310 == true) && (timeout) -> /** release resource **/

PAGE 123

112 T308 = true; c = 1; TERM2UNI!REL(par a.c al le d_a dd r, para); TERM2ORG!REL_int (pa ra .o rg_ ad dr, para); goto release_indicati on ; :: UNI2TERM?ALERT(e val (t er m_a dd r), para); T310 = false; T301 = true; TERM2ORG!ALERT_i nt( pa ra .or g_ add r, para); goto call_received; fi; call_received: if:: (T301 == true) && (timeout) -> /** release resource **/ T308 = true; c = 1; TERM2UNI!REL(par a.c al le d_a dd r, para); TERM2ORG!REL_int (pa ra .o rg_ ad dr, para); goto release_indicati on ; :: UNI2TERM?CONN(ev al( te rm _ad dr ), para); T301 = false; TERM2UNI!CONN_AC K(p ar a. cal le d_a dd r, para); TERM2ORG!CONN_in t(p ar a. org _a ddr para); goto call_active; fi; call_active: /* Note: "active" is a keyword of Promela */ if:: /* REL from called party */ UNI2TERM?REL(eva l(t er m_ add r) para); /** release resource **/ /* REL_COMP to called party */ TERM2UNI!REL_COM P(p ar a. cal le d_a dd r, para); /* REL_int to ORG_CC. Need to check a clear collision */ if:: ORG2TERM?REL_int (e va l(t er m_a dd r) para); :: timeout -> TERM2ORG!REL_int( pa ra .or g_ add r, para); fi;

PAGE 124

113 /* finishing */ TERM2MAIN!TERMIN ATE (p ar a); goto finished; :: ORG2TERM?REL_int (ev al (t erm _a ddr ), para); /** release resource **/ T308 = true; c = 1; /* REL to called party */ TERM2UNI!REL(par a.c al le d_a dd r, para); goto release_indicati on ; fi; release_indicati on : if:: (T308 == true) && (timeout) -> if:: (c < 2) -> c = c+1; T308 = true; goto release_indicat ion ; :: (c == 2) -> TERM2MAIN!TERMI NAT E( par a) ; goto finished; fi; :: UNI2TERM?REL_COM P(e va l( ter m_ add r) para); T308 = false; TERM2MAIN!TERMIN ATE (p ar a); goto finished; :: /* Handle the clear collision */ UNI2TERM?REL(eva l(t er m_ add r) para); TERM2MAIN!TERMIN ATE (p ar a); goto finished; fi; finished: skip; } /* end of "TERM_CC()" */ /* an environment process for calling party */ proctype Calling_Party() { Para para; /* assign the caliing party address */

PAGE 125

114 d_step { para.calling_ad dr = ADDR; ADDR = ADDR + 1; }UNI2MAIN!SETUP(pa ra ); if:: /* reject from ORG_CC because service is not possible now. */ ORG2UNI?REL_COMP (ev al (p ara .c all in g_ add r) para); goto finished; :: /* due to T303 timer expiration */ ORG2UNI?REL(eval (pa ra .c all in g_a dd r) para); if:: UNI2ORG!REL_COMP (p ar a.o rg _ad dr para); :: skip; /* no response for REL_COMP */ fi;goto finished; :: ORG2UNI?CALL_PRO C(e va l( par a. cal li ng _ad dr ), para); fi;if:: /* due to T310 timer expiration */ ORG2UNI?REL(eval (pa ra .c all in g_a dd r) para); if:: UNI2ORG!REL_COMP (p ar a.o rg _ad dr para); :: skip; /* no response for REL_COMP */ fi;goto finished; :: ORG2UNI?ALERT(ev al( pa ra .ca ll ing _a dd r), para); fi;if:: /* due to T301 timer expiration */ ORG2UNI?REL(eval (pa ra .c all in g_a dd r) para); if:: UNI2ORG!REL_COMP (p ar a.o rg _ad dr para); :: skip; /* no response for REL_COMP */ fi;goto finished; :: ORG2UNI?CONN(eva l(p ar a. cal li ng_ ad dr ), para); fi;if:: UNI2ORG!CONN_ACK (pa ra .o rg_ ad dr, para); :: /* unsatisfy to the CONN */ UNI2ORG!REL(para .or g_ ad dr, para); ORG2UNI?REL_COMP (ev al (p ara .c all in g_ add r) para); goto finished; fi;

PAGE 126

115 if:: /* initiate the call clearing from this party */ UNI2ORG!REL(para .or g_ ad dr, para); if:: ORG2UNI?REL_COMP (e va l(p ar a.c al li ng_ ad dr) para); :: /* in case of clear collision */ ORG2UNI?REL(eval (p ar a.c al lin g_ ad dr) para); fi; :: /* get a connection release request from network */ skip;ORG2UNI?REL(eval (pa ra .c all in g_a dd r) para); if:: UNI2ORG!REL_COMP (p ar a.o rg _ad dr para); :: skip; /* no response for REL_COMP */ fi; fi; finished: skip; } /* end of "Calling_Party() */ /* an environment process for called party */ proctype Called_Party(byte called_addr) { Para para; TERM2UNI?SETUP(ev al (ca ll ed _ad dr ), para); if:: skip; /* first loss of CALL_PROC */ if:: skip; /* second loss of CALL_PROC */ goto finished; :: UNI2TERM!CALL_PR OC (p ara .t erm _a dd r, para); :: UNI2TERM!REL_COM P( pa ra. te rm_ ad dr para); goto finished; fi; :: UNI2TERM!CALL_PR OC( pa ra .te rm _ad dr para); :: UNI2TERM!REL_COM P(p ar a. ter m_ add r, para); goto finished; fi;if:: UNI2TERM!ALERT(p ara .t er m_a dd r, para); :: skip; /* simulate no sending the ALERT */ TERM2UNI?REL(eva l(c al le d_a dd r), para); if:: UNI2TERM!REL_COM P( pa ra. or g_a dd r, para); :: skip; /* no response for REL_COMP */ fi;

PAGE 127

116 goto finished; fi;if:: UNI2TERM!CONN(pa ra. te rm _ad dr para); TERM2UNI?CONN_AC K(e va l( cal le d_a dd r) para); :: skip; /* simulate no sending the CONN */ TERM2UNI?REL(eva l(c al le d_a dd r), para); if:: UNI2TERM!REL_COM P( pa ra. or g_a dd r, para); :: skip; /* no response for REL_COMP */ fi;goto finished; fi;if:: /* initiate the call clearing from this party */ UNI2TERM!REL(par a.t er m_ add r, para); if:: TERM2UNI?REL_COM P( ev al( ca lle d_ ad dr) para); :: /* in case of clear collision */ TERM2UNI?REL(eva l( ca lle d_ add r) para); fi; :: /* get a call clearing from network */ /* skip; */ /* commented to avoid deadlock which occurs for each party to wait a release request from other side */ TERM2UNI?REL(eva l(c al le d_a dd r), para); if:: UNI2TERM!REL_COM P( pa ra. te rm_ ad dr para); :: skip; /* no response for REL_COMP */ fi; fi; finished: skip; } /* end of "Called_Party()" */ init{ atomic{ P_MAIN_CC = run MAIN_CC(); run Calling_Party(); /* start one connection */ run Calling_Party(); /* start another connection */ } }

PAGE 128

REFERENCES [1] F. Busc hmann, R. Meunier, H. Rohnert, P Sommerlad, and M. Stal, PatternOriente d Softwar e A r chite ctur e: A System of Patterns John Wiley & Sons, New Y ork, NY, 1996. [2] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of R eusable Obje ct-Oriente d Softwar e Addison{W esley Reading, MA, 1994. [3] D. Sc hmidt, M. Stal, H. Rohnert, and F. Busc hmann, Pattern-Oriente d Softwar e A r chite ctur e, V olume 2, Patterns for Concurr ent and Networke d Obje cts John Wiley & Sons, New Y ork, NY, 2000. [4] L. Rising, Design Patterns in Communic ation Softwar e Cam bridge Univ ersit y Press, Cam bridge, UK, 2001. [5] R. S. Pressman, Softwar e engine ering: a pr actitioner's appr o ach McGra w{Hill, Inc., New Y ork, NY, third edition, 1992. [6] I. Sommerville, Softwar e Engine ering Addison-W esley Longman Publishing Co., Inc., Boston, MA, sixth edition, 2001. [7] B. Berard, M. Bidoit, A. Fink el, P Sc hno eb elen, and L. P etrucci, Systems and Softwar e V eric ation: Mo del-Che cking T e chniques and T o ols Springer, Berlin, German y 2001. [8] E. M. Clark e, O. Grum b erg, and D. P eled, Mo del Che cking MIT Press, Cam bridge, MA, 2000. [9] G. J. Holzmann, Design and V alidation of Computer Pr oto c ols Pren tice{Hall, Englew o o d Clis, NJ, 1991. [10] G. J. Holzmann, \The mo del c hec k er SPIN," IEEE T r ansactions on Softwar e Engine ering v ol. 23, no. 5, pp. 279{295, 1997. [11] Spin Homepage, \On-the-ry L TL mo del c hec king with Spin ," http://spinroot.com/spi n/ /. [12] ITU-T Recommendation Z.100 (11/99), Sp e cic ation and Description L anguage (SDL) In ternational T elecomm unication Union (ITU), 1999. [13] L. Doldi, SDL Il lustr ate d: Visual ly Design Exe cutable Mo dels L. Doldi, T oulouse, F rance, 2001. 117

PAGE 129

118 [14] J. Ellsb erger, D. Hogrefe, and A. Sarma, SDL: F ormal Obje ct-Oriente d L anguage for Communic ating Systems Pren tice{Hall PTR, New Y ork, NY, 1997. [15] J. Rum baugh, M. Blaha, W. Premerlani, F. Eddy and W. Lorensen, Obje ctOriente d Mo deling and Design Pren tice{Hall, Inc., Englew o o d Clis, NJ, 1991. [16] J. Rum baugh, I. Jacobson, and G. Bo o c h, The Unie d Mo deling L anguage R efer enc e Manual Addison{W esley Reading, MA, 1998. [17] C. W. Krueger, \Soft w are reuse," A CM Computing Surveys v ol. 24, no. 2, pp. 131{183, June 1992. [18] T. J. Biggersta and C. Ric h ter, \Reusabilit y framew ork, assessmen t, and directions," IEEE Softwar e v ol. 4, no. 2, pp. 41{49, 1987. [19] F. Casati, S. Castano, M. G. F ugini, I. Mirb el, and B. P ernici, \Using patterns to design rules in w orkro ws," IEEE T r ansactions on Softwar e Engine ering v ol. 26, no. 8, pp. 760{785, 2000. [20] C. Alexander, S. Ishik a w a, M. Silv erstein, M. Jacobson, I. Fiksdahl-King, and S. Angel, A Pattern L anguage: T owns, Buildings, Construction Oxford Univ ersit y Press, New Y ork, NY, 1977. [21] The Hillside Group, \P atterns home page," http://hillside.net/pat tern s/ Octob er 2001. [22] B. Gepp ert and F. R o ler, \The SDL pattern approac h { a reuse-driv en SDL design metho dology ," Computer Networks v ol. 35, no. 6, pp. 627{645, 2001. [23] R. Gotzhein, \The SDL P attern Po ol, Proto col Engineering (SoSe 2002), Computer Net w orks Group, Univ ersit y of Kaiserslautern," h ttp://rn.informatik.unikl.de/lo cal/lehre/PESoSe02/F olien/SDLP atternP o ol.PESoSe02.2on1.p df, 2002. [24] S. Budk o wski and P Dem binski, \An in tro duction to estelle: A sp ecication language for distributed systems," Computer Networks and ISDN Systems v ol. 14, no. 1, pp. 3{23, 1987. [25] L. Logripp o, M. F aci, and M. Ha j-Hussein, \An in tro duction to LOTOS: Learning b y examples," Computer Networks and ISDN Systems v ol. 23, no. 5, pp. 325{342, 1991. [26] H. Huni, R. E. Johnson, and R. Engel, \A framew ork for net w ork proto col soft w are," in Pr o c e e dings OOPSLA '95, A CM SIGPLAN Notic es 1995, pp. 358{369.

PAGE 130

119 [27] J. P arssinen and M. T urunen, \P atterns for proto col system arc hitecture," in Pr o c e e dings of the 7th Confer enc e on Pattern L anguages of Pr o gr ams Mon ticello, Illinois, h ttp://jerry .cs.uiuc.edu/ plop/plop2k/pro ceedings/pro ceedings.h tml (7/28/03), August 2000. [28] S. M. Y acoub and H. H. Ammar, \Finite state mac hine patterns," in Pattern L anguages of Pr o gr am Design 4 N. Harrison, B. F o ote, and H. Rohnert, Eds. Addison{W esley Reading, MA, 2000. [29] D. Harel, \Statec harts: A visual formalism for complex systems," Scienc e of Computer Pr o gr amming v ol. 8, no. 3, pp. 231{274, June 1987. [30] T. F aison, \In teraction patterns for comm unicating pro cesses," in Pr o c e e dings of the 1998 Pattern L anguages of Pr o gr ams Mon ticello, Illinois, August 1998. [31] M. Adams, J. Coplien, R. Gamok e, R. Hanmer, F. Keev e, and K. Nico dem us, \F ault-toleran t telecomm unication system patterns," in Pattern L anguages of Pr o gr am Design 2 J. M. Vlissides, J. O. Coplien, and N. L. Kerth, Eds. Addison{W esley Reading, MA, 1996. [32] J. Adams, S. Koushik, G. V asudev a, and G. Galam b os, Patterns for ebusiness: A Str ate gy for R euse IBM Press, Carlsbad, CA, 2001. [33] M. F o wler, D. Rice, M. F o emmel, E. Hieatt, R. Mee, and R. Staord, Patterns of Enterprise Applic ation A r chite ctur e Addison{W esley Boston, MA, 2002. [34] M. P on t, Patterns for Time-T rigger e d Emb e dde d Systems: Building R eliable Applic ations with the 8051 F amily of Micr o c ontr ol lers Addison{W esley Reading, MA, 2001. [35] L. Rising (A guest editor), \Design patterns in comm unications soft w are," IEEE Communic ations Magazine v ol. 37, no. 4, pp. 32{33, 1999. [36] J.-P Kato en, \Concepts, algorithms and to ols for mo del c hec king: Lecture notes," http://www.cs.auc.dk/~kgl/V ERI FICA TION 99/k atoe n2. ps 1999. [37] A. Pn ueli, \The temp oral logic of programs," in Pr o c e e dings of the 18th IEEE Symp osium F oundations of Computer Scienc e 1977, pp. 46{57. [38] K. L. McMillan, Symb olic Mo del Che cking Klu w er Academic Publishers, Boston, MA, 1993. [39] K. Larsen, P P ettersson, and W. Yi, \UPP AAL in a n utshell," International Journal on Softwar e T o ols for T e chnolo gy T r ansfer v ol. 1, no. 1-2, pp. 134{152, 1997.

PAGE 131

120 [40] M. Bozga, C. Da ws, O. Maler, A. Oliv ero, S. T ripakis, and S. Y o vine, \Kronos: A mo del-c hec king to ol for real-time systems," in Pr o c e e dings of 10th International Confer enc e on Computer A ide d V eric ation A. J. Hu and M. Y. V ardi, Eds., V ancouv er, Canada, 1998, v ol. 1427, pp. 546{550, Springer-V erlag. [41] Spin Online Do cumen tation, \ Pr omela language reference," http://spinroot.com/spi n/Ma n/pr omel a.h tml [42] Spin Online Do cumen tation, \Basic Spin man ual," http://spinroot.com/spi n/Ma n/Ma nual .ht ml [43] Spin Online Do cumen tation, \Concise Pr omela reference," http://spinroot.com/spi n/Ma n/Qu ick. htm l [44] G. J. Holzmann, \Design and v alidation of proto cols: A tutorial," Computer Networks and ISDN Systems v ol. 25, no. 9, pp. 981{1017, 1993. [45] J. Hatcli, M. Dwy er, and Robb y \Sp ecication and v erication of reactiv e systems (cis 842): Lecture notes," http://www.cis.ksu.edu/ ~hat clif f/84 2/ 2002. [46] P .R. D'Argenio, J.-P Kato en, T.C. Ruys, and J. T retmans, \The b ounded retransmission proto col m ust b e on time!," in To ols and Algorithms for the Construction and Analysis of Systems E. Brinksma, Ed., Ensc hede, The Netherlands, 1997, pp. 416{432, Springer{V erlag, LNCS 1217. [47] M. Kamel and S. Leue, \F ormalization and v alidation of the general in ter-orb proto col (giop) using promela and spin," International Journal on Softwar e T o ols for T e chnolo gy T r ansfer v ol. 2, no. 4, pp. 394{409, 2000. [48] T. C. Ruys and R. Langerak, \V alidation of b osc h' mobile comm unication net w ork arc hitecture with spin ," in Pr o c e e dings of Thir d SPIN Workshop Tw en te Univ., The Netherlands, April 1997. [49] M. Calder and A. Miller, \Analysing a basic call proto col using pr omela / xspin ," in Pr o c e e dings of F ourth SPIN Workshop P aris, F rance, No v em b er 1998. [50] J. Garcia-F anjul, J. T uy a, and J. A. Corrales, \F ormal v erication and sim ulation of the netbill proto col using spin ," in Pr o c e e dings of F ourth SPIN Workshop P aris, F rance, No v em b er 1998. [51] S. Leue and G. Holzmann, \v-Promela: A visual, ob ject-orien ted language for Spin ," in Pr o c e e dings of the Se c ond IEEE International Symp osium on Obje ct-Oriente d R e al-Time Distribute d Computing Sain t Malo, F rance, Ma y 1999. [52] E. Mikk, Y. Lakhnec h, M. Siegel, and G. J. Holzmann, \Implemen ting statec harts in Pr omela / Spin ," in Pr o c e e dings of the Se c ond IEEE Workshop

PAGE 132

121 on Industrial Str ength F ormal Sp e cic ation T e chniques Bo ca Raton, Florida, Octob er 1998. [53] SDL F orum So ciet y \SDL forum so ciet y home page," http://www.sdlforum.or g/ [54] R. Reed, \Metho dology for real time systems," Computer Networks and ISDN Systems v ol. 28, no. 12, pp. 1685{1701, 1996. [55] D. Bosnac ki, D. Dams, L. Holenderski, and N. Sidoro v a, \Mo del c hec king SDL with Spin ," in T o ols and A lgorithms for Construction and A nalysis of Systems Berlin, German y 2000, pp. 363{377, Springer. [56] G. J. Holzmann and J. P atti, \V alidating SDL sp ecications: An exp erimen t," in Pr o c. 9th Int. Conf on Pr oto c ol Sp e cic ation, T esting, and V eric ation, INWG/IFIP C. Vissers and E. Brinksma, Eds., Tw en te, The Netherlands, June 1989, pp. 317{326. [57] N. Sidoro v a and M. Steen, \V erifying large SDL-sp ecications using mo del c hec king," in 10th International SDL F orum R. Reed and J. Reed, Eds., New Y ork, NY, 2001, v ol. 2078 of L e ctur e Notes in Computer Scienc e pp. 403{420, Springer{V erlag. [58] H. T uominen, \Em b edding a dialect of SDL in Pr omela ," in 6th Int. SPIN Workshop, LNCS 1680 1999, pp. 245{260. [59] M. Bozga, S. Graf, and L. Mounier, \Automated v alidation of distributed soft w are using the IF en vironmen t," in Pr o c e e dings of the IEEE International Symp osium on Network Computing and Applic ations Cam bridge, MA, Octob er 2001, pp. 268{275. [60] H. Gara v el, F. Lang, and R. Mateescu, \An o v erview of CADP 2001," Eur op e an Asso ciation for Softwar e Scienc e and T e chnolo gy (EASST) Newsletter v ol. 4, pp. 13{24, August 2002. [61] J.-C. F ernandez, C. Jard, T. Jeron, and C. Viho, \An exp erimen t in automatic generation of test suites for proto cols with v erication tec hnology ," Scienc e of Computer Pr o gr amming v ol. 29, no. 1{2, pp. 123{146, 1997. [62] A. Prigen t, F. Cassez, P Dhaussy and O. Roux, \Extending the translation from SDL to pr omela ," in Mo del Che cking Softwar e: 9th International SPIN Workshop D. Bosnac ki and S. Leue, Eds., New Y ork, NY, 2002, n um b er 2318 in Lecture Notes in Computer Science, pp. 79{94. [63] T. W orm, Softwar e A r chite ctur e for T ele c ommunic ations Pr oto c ols Ph.D. dissertation, Univ ersit y of Southern Denmark, Odense Univ ersit y 2000. [64] U. Blac k, OSI: A Mo del for Computer Communic ations Standar ds Pren tice{ Hall, Englew o o d Clis, NJ, 1991.

PAGE 133

122 [65] H. Brandt and C. Hapk e, A TM Signal ling: Pr oto c ols and Pr actic e John Wiley & Sons, New Y ork, NY, 2001. [66] ITU-T Recommendation Q.2130, B-ISDN A TM A daptation L ayer Servic e Sp e cic Co or dination F unction for Supp ort of Signaling at the User-Network Interfac e (SSCF at UNI) In ternational T elecomm unication Union (ITU), July 1994. [67] W. C. Lync h, \Reliable full-duplex le transmission o v er half-duplex telephone lines," Communic ations of the A CM v ol. 11, no. 6, pp. 407{410, 1968. [68] G. Meszaros, \P attern: Half-ob ject + proto col," in Pattern L anguages of Pr o gr am Design J. Coplien and D. Sc hmidt, Eds., pp. 129{132. Addison{ W esley Reading, MA, 1994. [69] R. Arthaud, \SDL and la y ered systems: Prop osed extensions to SDL to b etter supp ort the design of la y ered systems," in 10th International SDL F orum (SDL 2001) R. Reed and J. Reed, Eds., New Y ork, NY, 2001, n um b er 2078 in Lecture Notes in Computer Science, Springer. [70] B. Gepp ert and F. R o ler, \P attern-based conguring of a customized resource reserv ation proto col with SDL," T ec h. Rep. 19/96, Computer Science Departmen t, Univ ersit y of Kaiserslautern, German y 1996. [71] J. E. Hop croft and J. D. Ullman, Intr o duction to A utomata The ory, L anguages, and Computation Addison{W esley Reading, MA, 1979. [72] F. Dietric h and J.-P Hubaux, \F ormal metho ds for comm unication services," T ec h. Rep. SSC/1999/023, Institute for Computer Comm unications and Applications, Swiss F ederal Institute of T ec hnology CH-1015 Lausanne, 1999. [73] A. S. T anen baum, Computer Networks Pren tice Hall, Upp er Saddle Riv er, NJ, fourth edition, 2002. [74] D. Comer, Internetworking with TCP/IP V ol.1: Principles, Pr oto c ols, and A r chite ctur e Pren tice Hall, Upp er Saddle Riv er, NJ, fourth edition, 2002. [75] R. Presuhn (Editor), \RF C 3416: V ersion 2 of the proto col op erations for the simple net w ork managemen t proto col (SNMP)," Decem b er 2002. [76] Y. Byun, B. A. Sanders, and K. Ch ung, \A pattern language for comm unication proto cols," in Pr o c e e dings of the 9th Confer enc e on Pattern L anguages of Pr o gr ams Mon ticello, Illinois, Septem b er 2002. [77] Z. Manna and A. Pn ueli, The T emp or al L o gic of R e active and Concurr ent Systems: Sp e cic ation Springer{V erlag, New Y ork, NY, 1991. [78] M. B. Dwy er, G. S. Avrunin, and J. C. Corb ett, \Prop ert y sp ecication patterns for nite-state v erication," in Pr o c. 2nd Workshop on F ormal

PAGE 134

123 Metho ds in Softwar e Pr actic e (FMSP-98) M. Ardis, Ed., New Y ork, NY, 1998, pp. 7{15, A CM Press. [79] M. Dwy er, G. Avrunin, and J. Corb ett, \A Sp ecication P attern System," http://www.cis.ksu.edu/ sant os/s pecpat tern s/ 1998. [80] R. O. On vural and R. Cherukuri, Signaling in A TM Networks Artec h House, Norw o o d, MA, 1997. [81] T rillium Digital Systems, Inc., \T rillium A TM Signaling White P ap er, W eb V ersion 1082001.13," http://www.trillium.com/ April 1996. [82] ITU-T Recommendation Q.2931, Br o adb and Inte gr ate d Servic e Digital Network (B-ISDN) Digital Subscrib er Signaling Systems No. 2 User-Network Interfac e (UNI) layer 3 sp e cic ation for b asic c al l/c onne ction c ontr ol In ternational T elecomm unication Union (ITU), F ebruary 1995. [83] ITU-T Recommendation Q.2971, Br o adb and Inte gr ate d Servic e Digital Network (B-ISDN) Digital Subscrib er Signaling System No. 2 (DSS2) User-Network Interfac e layer 3 sp e cic ation for p oint-to-multip oint c al l/c onne ction c ontr ol In ternational T elecomm unication Union (ITU), Octob er 1995. [84] A TM F orum, A TM User-Network Interfac e Sp e cic ation, V ersion 3.1 A TM F orum, Septem b er 1994. [85] A TM F orum, A TM User-Network Interfac e Signaling Sp e cic ation, V ersion 4.0 A TM F orum, July 1996. [86] B. Stiller, \A surv ey of UNI signaling systems and proto cols for A TM net w orks," A CM SIGCOMM Computer Communic ation R eview v ol. 25, no. 2, April 1995. [87] ITU-T Recommendation Q.2140, B-ISDN A TM A daptation L ayer Servic e Sp e cic Co or dination F unction for Signal ling at the Network No de Interfac e (SSCF at NNI) In ternational T elecomm unication Union (ITU), F ebruary 1995. [88] ITU-T Recommendation Q.2110, B-ISDN A TM A daptation L ayer Servic e Sp e cic Conne ction Oriente d Pr oto c ol (SSCOP) In ternational T elecomm unication Union (ITU), July 1994. [89] M. Bozga, J.C. F ernandez, L. Ghirvu, S. Graf, J.P Krimm, L. Mounier, and J. Sifakis, \IF: An in termediate represen tation for SDL and its applications," in Pr o c e e dings of the Ninth SDL F orum R. Dssouli, G.V. Bo c hmann, and Y. Laha v, Eds., New Y ork, NY, 1999, Elsevier.

PAGE 135

BIOGRAPHICAL SKETCH Y oung jo on Byun receiv ed his B.E. degree in computer engineering from Kyungp o ok National Univ ersit y T aegu, Korea, in 1991 and his M.S. degree in computer science from the Korea Adv anced Institute of Science and T ec hnology T aejon, Korea, in 1993. Bet w een 1993 and 1998, he w ork ed for the Electronics and T elecomm unications Researc h Institute, T aejon, Korea, as a mem b er of the researc h sta. His researc h areas include design patterns for comm unication systems, soft w are analysis and v erication, soft w are dev elopmen t en vironmen ts and to ols, and real-time systems. He is a studen t mem b er of the Asso ciation for Computing Mac hinery and the IEEE Computer So ciet y 124


Permanent Link: http://ufdc.ufl.edu/UFE0001253/00001

Material Information

Title: Pattern-Based Design and Validation of Communication Protocols
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0001253:00001

Permanent Link: http://ufdc.ufl.edu/UFE0001253/00001

Material Information

Title: Pattern-Based Design and Validation of Communication Protocols
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0001253:00001


This item has the following downloads:


Full Text











PATTERN-BASED DESIGN AND VALIDATION
OF COMMUNICATION PROTOCOLS















By

YOUNGJOON BYUN


A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY

UNIVERSITY OF FLORIDA


2003

































Copyright 2003

by

Youngjoon Byun




































To my family















ACKNOWLEDGMENTS

I would like to express my sincere gratitude to my advisor, Dr. Beverly A.

Sanders, for her excellent advice and advocacy during the course of this work. I

would also like to thank the members of my committee, Dr. Jonathan C. Liu,

Dr. Steve M. Thebaut, Dr. Joseph N. Wilson and Dr. Mark C. K. Yang, for their

revision of this work and their valuable --,.' -htl ii1-

I am indebted to Dr. Yann-Hang Lee for his valuable guidance during the

course of my Ph.D. program. My appreciation and special thanks go to Dr. Byung

Sun Lee, Mr. Chang-Sup Keum and Ms. Ki-Sook Chung for the kind comments on

the case study presented in this dissertation.

Finally, I wish to thank my wife Younji for her support and understanding

during all these years.















TABLE OF CONTENTS


ACKNOW LEDGMENTS .............................

LIST O F TABLES . . . . . . . . .

LIST OF FIGURES ................................

A B ST R A C T . . . . . . . . .

CHAPTER

1 INTRODUCTION ..............................

1.1 Pattern-based Development Methodology ..............
1.2 Pattern Language Overview .....................
1.3 Organization of Patterns .......................

2 RELATED W ORK ..............................

2.1 Patterns in Communication Systems ................
2.2 Model Checking using SPIN and PROMELA .............
2.3 Introduction to SDL and Model Checking SDL System ......

3 PATTERN LANGUAGE FOR COMMUNICATION PROTOCOLS ..

3.1 Structural Patterns . . . . . . .
3.1.1 Protocol Layer . . . . . . .
3.1.2 M ux . . . . . . . .
3.1.3 Dynamic Handler .......................
3.2 Behavioral Patterns ..........................
3.2.1 Communicating Extended Finite State Machine ......
3.2.2 Tim er . . . . . ...... .
3.2.3 Repeated Events ........................
3.2.4 M message Transfer .. ...................

4 MODEL CHECKING PATTERN-BASED DESIGN .............

4.1 Modeling Pattern-Based Design in PROMELA ............
4.1.1 Model Construction from Patterns ..............
4.1.2 Communication Path and Channel Capacity .. ......
4.1.3 Tim er Handling . ... .. .. .. .. ... .. .. ..
4.1.4 Environment Process .. .................


page









4.2 Property Specification .................. .... .. 73
4.2.1 Linear Temporal Logic ...... . . .. 74
4.2.2 Property Extraction from Communication Patterns . 75

5 CASE STUDIES .................. .......... .. .. 77

5.1 Case Study: Alternate Bit Protocol ................ .. 77
5.1.1 Structural Design .................. .. 77
5.1.2 Behavioral Design .................. .. 78
5.2 Case Study: ATM UNI Signaling Protocol . . ..... 82
5.2.1 Protocol Overview .................. .. 82
5.2.2 Structural Design .................. .. 86
5.2.3 Behavioral Design .................. ...... 87
5.2.4 Validation of Pattern-based Design . . ..... 93

6 CONCLUSION .................. ............. .. 99

APPENDIX ................... ..... .... ....... 102

A MODELING OF ALTERNATE BIT PROTOCOL IN PROMELA .... 102

B MODELING OF ATM UNI SIGNALING PROTOCOL IN PROMELA 106

REFERENCES .................. ................ .. 117

BIOGRAPHICAL SKETCH .................. ......... .. 124















LIST OF TABLES
Table page

1-1 Pattern language for communication protocols ..... . 5

4-1 Effect of channel capability on memory and CPU for ABP ...... ..69















LIST OF FIGURES
Figure page

1-1 Overview of pattern-based design and validation . . ... 2

1-2 Organization of pattern language . . . ........ 7

3-1 A structure of pattern protocol layer ................. .. 23

3-2 A structure of pattern split protocol layer ............... ..23

3-3 SDL implementation of pattern protocol layer ............ ..24

3-4 Example of pattern protocol layer in SSCF at UNI . .... 25

3-5 Structure of ABP using split protocol layer .............. ..26

3-6 A structure of pattern mux .................. ..... .. 27

3-7 SDL implementation of pattern mux ................ 27

3-8 A structure of pattern dynamic handler ................ ..29

3-9 A structure of pattern split dynamic handler ............. ..30

3-10 SDL implementation of pattern dynamic handler . ..... 31

3-11 A file transfer server using pattern dynamic handler . ... 31

3-12 A call control block using pattern split dynamic handler . ... 32

3-13 An example CEFSM represented in STD ............... ..35

3-14 Pattern basic CEFSM .................. ....... .. 36

3-15 Pattern predicate CEFSM .................. .... .. 39

3-16 Pattern predicate after action .................. ..... 40

3-17 Merge patterns combined from two CEFSMs ............. ..41

3-18 SDL fragment for pattern basic CEFSM ............... ..43

3-19 SDL fragment for pattern predicate CEFSM ............. ..44

3-20 Example of pattern predicate after action for error detection . 44

3-21 Example of merge patterns .................. .... .. 45









3-22 Pattern timer with the expected event e ............... ..48

3-23 SDL fragment for pattern timer .................. .. 49

3-24 Pattern repeated events and its SDL implementation . ... 50

3-25 Pattern timed repeated events and its SDL implementation . 52

3-26 Pattern timed retrial and its SDL implementation .......... ..53

3-27 Nine-digit dialing using pattern repeated events ........... ..54

3-28 Protocol layer as a service provider .................. .. 56

3-29 Patterns unconfirmed sender and unconfirmed receiver . ... 56

3-30 Pattern confirmed sender and its example on an SNMP client . 58

3-31 Pattern confirmed receiver in three common cases .......... ..60

3-32 Patterns timed receiver and timed retrial receiver .......... ..61

3-33 Patterns timed confirmed sender and timed retrial confirmed sender .63

4-1 Model checking pattern-based system using SPIN . ..... 65

4-2 Nine-digit dialing in call setup .................. ..... 66

5-1 Structure of ABP using split protocol layer .............. ..78

5-2 Initial description of ABP behavior .................. .. 78

5-3 Final description of ABP behavior ................ 81

5-4 Protocol stack for signaling in ATM control plane .......... ..82

5-5 Message flow for connection establishment and release . ... 84

5-6 Architecture of connection control block using split dynamic handler 86

5-7 MAIN_CC as an administrator of split dynamic handler . ... 87

5-8 Behavior of ORG_CC for SETUP, ALERT, and CONN . ... 89

5-9 Behavior of TERM_CC for SETUP message ............. ..91

5-10 Behavior of TERM_CC for ALERT and CONN ........... ..91

5-11 Call clearing for an ATM connection ................. 92















Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy

PATTERN-BASED DESIGN AND VALIDATION
OF COMMUNICATION PROTOCOLS

By

Youngjoon Byun

August 2003

Chair: Beverly A. Sanders
Major Department: Computer and Information Science and Engineering

Patterns help to improve software quality and reduce development cost by

reusing the experience of experts for recurring problems. In this dissertation,

we apply the pattern concept to the development of communication protocols,

particularly focusing on the description and validation of message interaction in the

protocols. Typically, it is important for designers to capture essential functions of a

system at the initial design phase and uncover design errors as early as possible to

prevent the errors from affecting later phases. There are many useful patterns for

communication systems, but to date they are mainly concentrated on the object-

oriented design and implementation. There is little research on the patterns for

message interaction and the validation of pattern-based design. We hypothesize

that many communication protocols can be developed using a few recurring

patterns.

In this pattern-based methodology, we propose a set of patterns to describe the

architectural and behavioral specification of communication protocols. A complex

protocol can be obtained by composing such patterns. To provide confidence in

the design, we -1-'- .t 4a validation method for the design using the SPIN model









checker. The validation is composed of model construction for the design and

identification of desired properties of the system. Then, the model is checked

against the properties. The most difficult part of using tools such as SPIN is

obtaining the appropriate properties of a system in a formal way against which to

check the design. An innovative feature of our patterns is a section that helps the

designer obtain the properties in linear temporal logic.

To show the usefulness of our methodology, we perform several case studies.

From the methodology, protocol designers can abstract a system in several patterns

and uncover design errors before the detailed design and implementation.















CHAPTER 1
INTRODUCTION

When programmers develop software systems, they often find situations

similar to those that have arisen in previous developments. A design pattern is a

written document providing a generic solution for a recurring problem in a certain

context [1, 2]. A design solution that has worked well in a particular situation can

be used again in similar situations in the future. Design patterns, therefore, help to

improve software quality and reduce development cost through predefined solutions

and their reuse.

Patterns are considered to be useful in many types of software systems because

they provide generic solutions for common problems. However, it is not always

easy for a domain specific designer to find and use the generic solution in a specific

application. The solution may be unsuitable for a particular area. Thus, it is

frequently useful to have a set of patterns for a specific domain. In this disserta-

tion, we present several patterns for the development of communication protocols.

Actually, research and usage of patterns in communication systems are increasing

as an emerging area in the design patterns community [3, 4]. Much of the work

focuses on the structure of communicating blocks or objects and the relationship

among them. Although the patterns are valuable in system developments, our main

concern exists in the message exchanges among communicating blocks because

those exchanges provide the principles of protocol operation.

Another problem that we handle in this dissertation is the correctness and

validation of pattern-based design. Currently, many patterns are concentrated

on the design and implementation of software development without consideration

of other aspects, for example, patterns for requirements analysis and testing [1].









We -itz.' -4 a validation technique for a design specification developed from our

patterns. Moreover, the property description in each pattern enables designers to

capture the system requirements to be checked after the design.

In summary, we -'--2.' -t a pattern-based development methodology for

communication protocols which aims to support high-level design and validation of

protocols in the early development phase.

1.1 Pattern-based Development Methodology

The classic life-cycle of software engineering is composed of several phases

such as requirements analysis, design, coding, t. -tit- and maintenance [5, 6].

Our concern lies in the initial design phase for the high-level description of a

system and its validation. Designers in that phase typically want to capture


Figure 1-1: Overview of pattern-based design and validation

the essential functions first; for example, flows of messages and interactions

with other systems. Then, they build an abstract system before the detailed









design and implementation. For the specification of the abstract system, we

propose a pattern language, a collection of patterns that work together to solve

problems in a specific domain. The pattern language is categorized in two groups,

structural patterns and behavioral patterns, to address overall architecture and

common behavior of a protocol system. Figure 1-1 illustrates the pattern-based

development methodology. The patterns are contained in the pattern repository

that has an expandable structure with pattern specialization and instantiation.

After analyzing the requirements of a protocol, we devise the architecture

of the protocol with structural patterns. The architecture is composed of several

blocks along with communication paths between them. A block is an architectural

building element of a developing system and can contain other blocks. At this

point, blocks are considered to be black boxes. The external interfaces such as

communication paths and messages are defined, but the internal details are not.

The execution of the abstract system is acquired in behavioral patterns after

the architectural design. The behavioral patterns provide common behavior of a

protocol system, focusing on the interaction between blocks. They assist developers

in describing the internal behavior of blocks. Each block instance has a state

that may change to another state in response to a message input. The response

may also trigger additional events such as the generation of output messages.

We use a communicating extended finite state machine (CEFSM) to formally

describe the behavior. Predicates and timers may be used to describe conditional

behavior and timing constraints. Note that we use the event, signal, and message

interchangeably in this dissertation.

Protocol designers complete the abstract design of a protocol system by

composing the structural and behavioral patterns. It may be necessary to revise

the requirements during the design step to fix any unclear requirements. As

a result of the design, we have a system design description which sketches an









abstract system of a protocol focusing on message exchanges. The description is

a combination of instantiated blocks, communication paths, messages, and other

components of patterns used.

After the pattern-based high-level design, we perform a validation of the

specified system to validate the correctness and consistency of the design. It is

important to uncover them as early as possible to prevent the errors from affecting

the later phases. In this dissertation, we -i-'-L. t a model checking technique for

the validation of the design. Model checking is an automatic technique to verify

properties of a system by investigating a model of the system [7, 8]. We selected

SPIN (Simple Promela INterpreter) as our model checking tool. It was developed

at Bell Labs for the analysis and validation of distributed systems, especially of

communication protocols [9, 10, 11]. Furthermore, it is freely available from the

SPIN web site [11].

For the SPIN model checking, we first build a model of the system design

description in PROMELA, an input language of SPIN, and identify requirements or

properties to be checked from the description. Then, the model is simulated and

verified against the properties using SPIN. Usually, the construction of a model is

a challenging practice in formal validation because it is crucial to validation result

and it must reflect the system to be developed exactly. We provide a translation

mechanism to build a model from a pattern-based design specification. The

translation is simple because of the correspondence between the pattern elements

and PROMELA constructs.

Meanwhile, it is important to identify the properties of a system in the design

phase so that they can be used for later testing and maintenance of the system as

well as for the design validation. For this purpose, each pattern of our pattern lan-

guage provides a property specification section to help to describe some properties

from the pattern. Consequently properties to be checked at the validation phase









can be obtained at the design phase. The properties include the occurrence of

message arrival, ordering in the message interaction, and correspondence or alter-

nativeness of messages. If the validation fails, it is necessary to find the reason and

fix the problem. Then, we return to the design step or validation step. Otherwise,

refinement and further development follow.

In this dissertation, we show the implementation of a pattern in SDL (Spec-

ification and Description Language). SDL is a formal description language for

communicating systems recommended by ITU (International Telecommunication

Union) [12] and is becoming popular in design and implementation of communica-

tion protocols [13,14].

1.2 Pattern Language Overview

Patterns are rarely standalone. Instead, several related patterns are typically

used to solve problems in a specific domain. Table 1-1 presents our pattern lan-

guage to be used for communication protocols. Detailed description of each pattern

Table 1-1: Pattern language for communication protocols

Category Patterns Variants or Specialization
protocol layer split protocol layer
structural mux
dynamic handler split dynamic handler
predicate CEFSM
basic CEFSM predicate after action
merge patterns
timer
repeated events timed repeated events
timed retrial
unconfirmed sender
behavioral unconfirmed receiver
confirmed sender
message transfer confirmed receiver
timed receiver
timed retrial receiver
timed confirmed sender
timed retrial confirmed sender









is given in Section 3.1 and 3.2. Structural patterns are used to represent the ab-

stract architecture of a protocol system which is a combination of communicating

blocks, communication paths, and messages. One pattern is able to depict a hier-

archical structure by nesting other patterns. In addition to the static architecture

expressed in the pattern protocol layer or mux, block instances can be created

dynamically using the pattern dynamic handler.

Behavioral patterns help a designer describe internal behavior of blocks

identified in structural patterns. We use CEFSM to describe the behavior. One

feature of the behavioral patterns is that a state transition diagram (STD) is used

to represent the CEFSM. There is no standard notation for pattern description,

although for object-oriented systems the Unified Modeling Language (UML) and

Object Modeling Technique (OMT) are common [15, 16]. We use STD because it is

easy to understand and translate into our validation language PROMELA.

A pattern is represented in a particular form to describe the design problem

and its solution. There are many variants in the form, but most forms typically

have name, context, problem, solution, and example sections. We follow a tradi-

tional pattern description form fi. -I.1 in Buschmann et al. [1], but our form

exploits SDL as an implementation language and additionally presents the property

specification section to aid validation of a system developed using the pattern. The

following enumerates each section of the form:

Name: The name of the pattern. A meaningful word or phrase has to be used

to intuitively present the main purpose of the pattern.

Context: A situation in which the problem of the pattern arises.

Problem: General description of problem's essence.

Force: Various viewpoints and aspects of the problem that should be con-

sidered when solving the problem. It describes requirements that must









be considered in the solution, constraints of the problem or context, and

desirable properties of the solution.

Solution: The generic solution to the problem. We use diagrams and CEF-

SMs to illustrate the static and dynamic aspects of the solution.

Property specification: Properties that can be captured from the pattern

when it is used in a system design.

Implementation: Guidelines or -.'-' -tH1m, to transform the solution into

SDL. It is usually obtained by one-to-one mapping of pattern elements.

Example: Any known usages of the pattern in real applications.

Variants: Slightly different solutions for similar problems or more specific

situations.

See also: Any related or similar patterns.

1.3 Organization of Patterns

Software reuse is a powerful discipline to create a new software system from

existing ones [17]. Although the concept is simple, it is not easy to find a reusable

artifact that provides high-level abstraction applicable to several developments.

The pattern is a good candidate for software reuse through experienced design ab-

straction instead of real source code. It is believed that design reuse has advantages

over code reuse [18].


Instantiated Patterns

Q instantiation
Message Transfer

Structural Repeated Events Tmer
Patterns
Basic CEFSM


Figure 1-2: Organization of pattern language









Figure 1-2 shows the organization of our patterns. Note that the behavioral

patterns have an expandable hierarchical structure. The pattern basic CEFSM is

the foundation of behavioral specification. It is possible to represent more complex

and high-level abstraction through merge patterns such as source merge, target

merge, and sequential merge. Patterns can also be augmented with the pattern

timer and/or repeated events to control timing constraints and repetition of events.

Basic CEFSM, timer, and repeated events are called elementary patterns because

other patterns are able to be made from these patterns. The current domain of our

pattern language is a communication protocol and our concern is concentrated on

the behavior of message exchanges between communicating blocks. The patterns

of message transfer are specialization of the elementary patterns. For example, the

pattern basic CEFSM has a tuple ({S,, St}, 5, {e} U 0, {< S,, e, St, A, 0 >}, V)

which means that there are two states S, and St with S, as an initial state. For an

input event e, the pattern moves to St after performing action A and generating

output O. There is a set of variables V for the action. The formal definition of the

pattern is given in Section 3.2.1. From the pattern, we can introduce a specialized

event indication instead of a general event e so as to describe a new pattern

unconfirmed receiver. The indication is used to inform a receiving entity of the

arrival of a message for a request message from a sender. The result pattern has

a tuple ({S,, St}, Ss, {indication} U O, {< S,, indication, St, A, 0 >}, V) which

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]

for the general introduction to the patterns.

As closely related work, Geppert and Rofiler [22] and Gotzhein [23] 1--.' -fI .1

a pattern-based SDL design where a pattern pool maintains a set of SDL patterns

that can be selected, adapted, and composed for a new SDL system. In fact,

their research provided us with the initial motivation. The SDL patterns are

SDL-oriented by presenting SDL semantics as well as SDL syntactic rules in

the pattern description. Due to the SDL orientation, their approach makes it

possible to generate an executable SDL specification directly from the pattern-

based design. Our methodology, on the other hand, can support other formal









description techniques such as Estelle [24] and LOTOS [25] as a design specification

language because our patterns are represented in a general CEFSM. Moreover,

by performing a validation before the implementation, it is possible to find design

errors immediately after the design.

Huni and his colleagues [26] proposed a framework called Conduits+ to address

a generalized software architecture for communication protocols. The framework

has two types of elements: conduits, protocol independent components, and

information chunks, messages that flows through conduits. There are four kinds of

conduits in the framework, that is, Protocol, Mux, Adapter, and ConduitFactory.

By using a sequence of design patterns of Gamma patterns [2], Conduits+ is

able to implement a network protocol with a graph of conduits and information

chunks. Since the conduits provide simple and concise architectural elements

for network protocols, we use them as a part of our structural patterns. Other

patterns for static components of a protocol system are also found in Parssinen and

Turunen [27] where the authors present common principles of a communication

protocol in protocol system, protocol entity, protocol behavior, and entity interface.

We use the CEFSM to formally describe the behavior of communication

protocols. The theoretical background of it is found at the book of Ellsberger

et al. [14]. There are several ways to implement a finite state machine (FSM) in

patterns [2, 28]. Yacoub and Ammar [28] presents a pattern language that provides

a pattern system for FSMs in object-oriented design. They propose a basic FSM

pattern and its extensions to handle several design issues such as state transition

mechanisms, design structure, state instantiations, exposure of internal state,

and the machine type, focusing on the object-oriented implementation. In our

case, a CEFSM pattern is depicted in an STD so that the description is simple

and straightforward. Furthermore, the CEFSM has an expandable hierarchical

structure using the specialization and instantiation. The pattern specialization is a









mechanism for creating a new pattern from an existing one and the instantiation is

a finalization of a pattern to adapt it in a concrete situation [19].

Meanwhile, our notation in the behavioral patterns is based on the State-

charts [29], a visual formalism for the specification of reactive systems. A transition

of an STD has a label with an input event, predicates, actions, and outputs events

where all fields are optional although the input event is almost always necessary. A

transition of Statecharts is labeled with an event, a condition, and an action. State-

charts have more descriptive power than our STD through the use of hierarchies of

states, orthogonality, and history connectors. However, several experiments such as

the case studies presented in Chapter 5 show that our notation is enough for the

description of communication protocols.

Faison emphasizes the importance of interaction in software with multiple

processes or components [30]. Actually, interactions between communicating

entities are essential in the description of behavior in many application domains.

He found fundamental patterns in the interactions such as pull interaction and

push interaction to describe the way the entities relate to and communicate

with each other. He also provided many useful examples in real life and software

components. The basic idea of the patterns is also found at our message transfer

pattern.

As a similar approach in a different domain, a workflow system uses pattern

concept called rule patterns in the design of exceptional handling [19]. An excep-

tional handling rule is represented with event, condition, action, and output, which

is analogous to our behavioral patterns except the timing concept. The authors dis-

covered frequently occurring exceptional situations in workflow design and modeled

the abstract activity in an application-independent manner. They also introduced

the specialization and instantiation as a formal basis for expanding their patterns.









Patterns can be used not only in software developments, but also in other

areas. As an example of patterns that are not relevant to software development,

Adams and his colleagues [31] presented several patterns for operations and

maintenance of telecommunications systems. They described their experience

and expertise for highly available fault tolerant switches. There are also several

efforts made to capture patterns for domain-specific applications such as factory

automation, e-business, embedded systems, and enterprise application [32,33,34].

Our patterns have a section named see also to provide the related patterns and

relationship with other patterns. Further related work can be found in this section.

For more information on patterns for communication systems, see Buschmann et

al. [1], Schmidt et al. [3], and Rising [35,4].

2.2 Model Checking using SPIN and PROMELA

Model checking is an automated technique to validate correctness of a system

by investigating a finite state model of the system [7, 8, 36]. The technique is

especially useful for reactive and distributed systems that are characterized by

many interactions among processes. A model checker explores all states reachable

from an initial state and validates a set of correctness properties on the model.

Model checking typically starts with the construction of a model and the

identification of properties to be checked. Then, it validates the properties with

an appropriate model checker. A system is usually modeled using a state based

description such as communication automata, CSP (Communicating Sequential

Processes), Petri Nets, etc. A model must be made as closely as possible to a

system so that the validation results for the model reflects the system's execution

exactly. The properties a model checker validates in a model include the reachabil-

ity of a certain state, safety and liveness of a system, and relative order of events

in a system [7]. Several formalisms are used to precisely express the properties.

Temporal logic [37] is specifically tailored for the description of properties of system









behavior over time. The two most popular temporal logics are linear time temporal

logic (LTL) and computation tree logic (CTL). Formally, a model checker validates

whether

M ^

holds, where M is a model of a system and D is a property to be required in the

system.

Model checking has been successfully used in hardware validation and pro-

tocol communication software. There are many tools applicable today such as

SMV [38], SPIN, UPPAAL [39], KRONOS [40], etc. We select SPIN (Simple Promela

INterpreter) as our model checker for the validation of pattern-based design. It

was developed at Bell Labs for the analysis and validation of distributed systems,

especially of communication protocols [9, 10, 11]. Furthermore, it is freely available

at the SPIN web site [11]. A system is described in a modeling language called

PROMELA (PROcess MEta LAnguage) [41]. Given a system model specified in

PROMELA, SPIN can simulate the system's execution. It is also possible to generate

a C program to perform an exhaustive exploration of a system's state space using a

depth-first search algorithm. During the simulation and validation, SPIN can check

for absence of deadlocks, non-progress cycles, unspecified message receptions, un-

executable code, etc. The model is also proven the correctness of system invariant

claims and temporal claims expressed in next-time free LTL formulae. If a system

model violates a correctness property, SPIN recognizes this and a trace of violation

is generated. To cope with the problem of state space explosion, SPIN employs

several techniques such as partial-order reduction, state-vector compression, and

bit-state hashing. For the simple usage of the tool, a graphic user interface, Xspin,

is also provided.

PROMELA is a validation modeling language for SPIN, focusing on the abstrac-

tion of message exchange in a system [42, 43]. It has C-like syntax with features










from Dijkstra's guarded commands and communication primitives from Hoare's

CSP. The important constructs of a PROMELA program are process, message

channel, and variable. Processes execute i,-\ ti. 1IL.-.t Ii-l\, which means there are

no assumptions on the relative speed of processes and only one process is executed

at a particular point. Each statement in a process is either executable or blocked.

If a statement is blocked for some reason, the statement halts until it becomes

executable. Processes interact either by message passing via channels or mem-

ory sharing of global variables. Communications via message channels are either

synchronous (i.e., rendezvous) or asynchronous (i.e., buffered).

The following example [42] presents a sample PROMELA program to show the

basic concept of PROMELA. It calculates the factorial value of a number n at the

process fact, returning the result through the channel p.


proctype fact(int n; chan p) {
int result;
if
: (n <= 1) -> p!1
: (n >= 2) ->
chan child = [1] of {int};
run fact(n-1, child);
child?result;
p!n*result
fi
}

init {
int result;
chan child = [1] of {int};
run fact(5, child);
child?result;
printf("result: %d\n", result)
}

A process is defined by a proctype with process behavior in it. A special process

init usually instantiates other processes by using the run operator. Channels

defined by chan are used to transfer data from one process to another. The

statement p! 1 means the sending of the constant one through the channel p.

To receive a value or a message from the head of a channel, a receive statement










expressed in the symbol ? is used such as child?result. The channel in the

example can store up to one integer value because the size of each channel is

declared as one. For synchronous communication, the channel size has zero.

There are three kinds of control flow constructs in PROMELA namely, selection,

repetition, and unconditional jumps. The if selection contains several execution

sequences, each preceded by a double colon. A sequence can be selected only if

its first statement is executable. The first statement is therefore called a guard.

If none of the guards of the statement is executable, the construct blocks. In the

above example, the if construct has two sequences. Note that only one sequence

can be selected among the sequences. The repetition construct do conducts the

same mechanism as if. But it repeats the construct until it meets the break.

Another way to terminate the repetition is to jump to a label outside of the

statement with goto. A label identifies a unique control state and can appear

before a statement.

By prefixing a sequence of statements enclosed in parentheses with the

keyword atomic a user can indicate that the sequence is to be executed as one

indivisible unit, that is non-interleaved with any other processes. Meanwhile, SPIN

is able to express the correctness properties in the PROMELA statements such as

assert, end label, progress label, accept label, and never claims [44].
The following shows a result of validation using SPIN for the example

PROMELA code.


(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










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

Internally, SPIN maintains three key data structure [45]: state-vector, depth-first

stack, and seen set. The state-vector shows the size of a state which is composed

of the value of local and global variables, control flow location of each process, and

the contents of message channels. In the example, each state occupies 124 bytes.

The depth reached field represents the deepest stack depth reached during the

depth first search of the state space. The seen set holds the states already explored

during the search. Thus, the stored means the number of states stored in the seen

set. The matched is the number of states that were already found in the seen set.

There is a lot of research that exploits SPIN and PROMELA for the validation

of communication protocols [46, 44, 47, 48]. Kamel and Leue [47] presented the

modeling and validation of the General Inter-ORB Protocol (GIOP) using SPIN.

This paper provides useful examples in the tool usage. The authors elicit ten

high-level requirements from the text-based specification and formally express

them in LTL for the validation. Property extraction from a system requirements

specification is common in practice. Note that our approach to capture the system

properties from a pattern does not enumerate all potential properties of a system.

Nonetheless, this method provides a systematic way to elicit the part of properties

of the target system.









D'Argenio and his colleagues [46] described the transfer of files on a lossy

communication channel using a bounded retransmission protocol. They present a

specification of the protocol in a network of timed automata and a list of properties

of the protocol with respect to inputs and outputs. SPIN and UPPAAL are used for

the checking of the properties and shows the importance of the real-time aspects

in the protocol validation. For more experience and usages of SPIN in protocol

validation and other applications, refer the proceedings of SPIN workshops [11].

Our design provides a visual description of a system in the composition of

patterns. In fact, using the visual specification such as STD is a common way to

describe a system abstraction before the formal PROMELA modeling [49, 50]. Leue

and Holzmann [51] -1-'-2. -f .l v-Promela, a visual and object-oriented modeling

language for SPIN. The language is designed to present abstraction and hierarchical

layering. The visual notation is able to express both structure and behavior of a

reactive concurrent system to acquire software architecture at the early life-cycle

stages. They use UML for Real-Time (UML-RT) notation for structural descrip-

tion and adapt many important ideas from Realtime Object-Oriented Modeling

(ROOM). Behavior is specified using hierarchical communicating extended finite

state machines (HCEFSMs). This paper -i.-' -tf a translation mechanism from the

visual constructs to a PROMELA program. The visual notation is supported by a

graphical tool, VIP. On the other hand, Mikk et al. [52] have translated Statecharts

into PROMELA using extended hierarchical automata as an intermediate format.

Their technique allows a system described in Statecharts to be validated in a linear

temporal logic model checker.

2.3 Introduction to SDL and Model Checking SDL System

Our methodology proposed in this dissertation was originally aimed at the

initial design of a communication system to be implemented in SDL. SDL skeleton

code which outlines the system architecture and behavior could be generated after









the pattern-based design and validation. In this section, we present the basic

concept of SDL which is related to our techniques. Further information on SDL is

available at [13, 14, 53]. Meanwhile, our pattern repository can be combined with

other SDL development methodologies such as SDL+ [54] as a library of reusable

artifacts.

SDL is an object-oriented formal language recommended by the ITU Telecom-

munication Standardization Sector (ITU-T) for the precise and unambiguous

specification of event-driven and reactive systems, in particular, communication

systems [12]. It describes structure, behavior, and data of a system in formal

notation.

The static structure of an SDL system is described by hierarchical blocks. A

block can contain other blocks, resulting in a tree structure. A leaf block is made

up of one or more processes. Channels and signal routes are used to convey signals

between the structural elements. Processes are connected with each other and to

the boundary of the nesting block by signal routes. Blocks are connected together

by channels. If many signals are transferred on the same channel or signal route,

their ordering is preserved. In addition to the static process, the SDL process can

also be created dynamically.

The behavior of a system is described by a set of autonomous and concur-

rent processes. A process is an extended finite state machine, communicating

i-\ i.1 lti' -i. i-lh with other processes by signals. Each process has an implicit

unbounded FIFO input queue where signals are buffered on arrival. Signals are ex-

tracted from the input queue in the order of arrival. An expected signal triggers a

transition, and the process executes a set of tasks such as an assignment of a value

to a variable, a procedure call, and a signal output. After initiating a transition,

a signal is removed from the input queue. Each process has a unique address. A

signal always carries the address of the sending and the receiving processes. The









destination address may be used if the destination process cannot be determined

statically and the address of the sending process may be used to reply to a signal.

In SDL, variables are owned by a specific process and cannot be modified

by other processes. The synchronization between processes is achieved using the

exchange of signals or remote variables.

Many researchers have investigated the simulation and validation of SDL sys-

tems using SPIN/PROMELA [55,56,57,58]. Holzmann and Patti [56] introduced an

experimental validation tool, supertrace, for the validation of an SDL specification.

In fact, the tool is an ancestor of SPIN and used for AT&T's 5ESS@ switching

system with a practical size. They also presented some consideration in the usage

of the tool such as closeness of a model and handling of time expiration that are

still open questions in current SPIN version.

Bozga and his colleagues [59] -1 .' -t. a validation toolset with an interme-

diate representation called IF for distributed software systems. The IF validation

environment provides a translator from SDL to IF sdl2if so that a system de-

scribed in IF is able to be validated in several different validation tools such as

CADP [60], KRONOS [40], and TGV [61]. Consequently, the environment makes it

possible to support several different techniques for one system validation.

Sidorova and Steffen -iL--2. -t .1 a validation methodology for a large-scale SDL

system in which an SDL specification is transformed to a PROMELA model using

the existing tools such as sdl2if, LIVE, and if2pml [57]. As the size of a system

to be model checked is limited, they use a bottom-up compositional technique

which starts from small components and then composes them for larger ones.

Tuominen [58] provided a translation mechanism from an SDL-88 dialect to

PROMELA. Bosnacki and his colleagues [55] have extended SPIN to validate the

timing properties of the SDL model. The resulting tool DTSpin allows to quantify

the time elapse between events. Meanwhile, Prigent et al. [62] have -'i-. -t. I a









validation of the SDL program with save operator which is not handled in other

literature. They extended the tool if2pml to get a PROMELA code from IF with

save.

One feature in their attempts is that they extract an abstraction model from

a completely developed SDL system. Typically, a model from a final system suffers

from a state space explosion and cannot be validated as a whole due to the size

of the system. As a result, the system is split into several small components and

performs a validation from each component [55,57]. In our case, we design a system

in high-level from the patterns and obtain a validation model from it. Thus, the

model needs relatively small number of states for the validation. Additionally, we

can extract several properties of the system during the design phase. Accordingly,

the properties can be used at the testing phase after the implementation of the

system as well as the validation for the design.

Meanwhile, the patterns discussed in this paper are specific to the communica-

tion protocols. However, SDL is not always used for communication systems. It is

possible for many SDL systems to be developed using the patterns popular in other

domains. Worm [63] presented SDL implementation of the classic patterns such

as Observer and Factory. The examples in this paper guide the SDL users how to

apply the patterns in an SDL system.















CHAPTER 3
PATTERN LANGUAGE FOR COMMUNICATION PROTOCOLS

3.1 Structural Patterns

3.1.1 Protocol Layer

3.1.1.1 Context

We need to design a complex system such as a communication protocol. Some

parts of the system may already exist.

3.1.1.2 Problem

How can we describe the structure of a communication protocol system?

3.1.1.3 Forces

The system is too large and complex to be understood completely. We need

techniques to help manage the complexity.

Decomposition: We decompose the system into several -ill -v-t' ili- that can

be dealt with more-or-less independently.

Abstraction: Each -ill -v-i' ill is treated as a black box and specifies the

interfaces with other 1 ,-\-t'. i- Internal details are left for later.

Reuse: Some of the -il -\- iti i may already be available and thus do not

need to be designed.

3.1.1.4 Solution

A communication protocol can be designed in layers. Each layer handles

problems at a particular level of abstraction. A layer offers services to the higher

layer and uses services from the next lower layer. This structure allows a protocol

developer to design external interfaces before internal functionality [64, 9].










First, we identify the blocks belonging to a layer and determine the communi-

cation paths between the adjacent layers. The layers and communication paths are

logical objects that may or may not correspond directly to ]1li\ -il ., components of

network or communication links.

Second, we address the messages between layers and associate the messages

with the communication paths. The communication paths show the list of mes-

sage types that can be sent on the path and the direction of the message flow.

Figure 3-1 shows a protocol layer that includes one block, four communication


upper layer messages = list all messages used in
Sthe pattern;
p1 p2
paths =
Protocol Layer pa : messages passing through p,;
A p2 : messages passing through p2;
P3 P4 P3 : messages passing through p3;
lower layer P4 : messages passing through p4;


Figure 3-1: A structure of pattern protocol layer

paths, a message list, and the adjacent layers. The internal behavior of the protocol

layer block can be designed using other patterns of this pattern language.

3.1.1.5 Variant: split protocol layer

Often, a communication layer can be conceptually split into two related

functions such as sending and receiving for message transfer [65]. It may be helpful

for the designer to consider the two functions separately. Figure 3-2 shows a


upper layer messages = list all messages used in
P P p the pattern;
pi P2 P5 6 paths=
Outgoing Incoming p, : messages passing through p,;
S p2 : messages passing through p2;
p3 p4 P7 P8 P3 messages passing through p3;
power lay4 : messages passing through p4;
lower layer



Figure 3-2: A structure of pattern split protocol layer










structure of the pattern split protocol layer where the 0itfil ;i block initiates a

communication requested from the upper layer and the Incoming block handles

messages coming from the lower layer.

3.1.1.6 Implementation

The SDL implementation can be obtained directly from the design. SDL has

two constructs to describe a system structure: SDL blocks and SDL processes.

SDL blocks are pure structuring mechanisms that may contain other blocks and

processes while SDL processes contain the specification of behavior.

Typically, the non-leaf blocks of the structural patterns are mapped to

SDL blocks and the communication paths between them are mapped to SDL

channels. Two types of channels are possible in SDL. One is a delaying channel

and another is a non-delaying channel. The selection of the channel is dependent

on the situation. Leaf blocks are mapped to SDL processes. In this case, the

communication paths are mapped to signal routes which connect processes to

other processes and to the channels of their containing block. Messages flowing

on communication paths that are mapped to channels or signal routes are called

signals in SDL.

BLOCK Layer SIGNAL
m cl msgl,msg2,
[msgl,... c2 msg3, msg4,
[msg2, ...]
ProtocolLayer

c3 /\
[msg3, ...] c4
/ [msg4,...]


Figure 3-3: SDL implementation of pattern protocol layer

Figure 3-3 shows an implementation of the pattern protocol layer of Fig-

ure 3-1. The Protocol Li,,, of Figure 3-1 is mapped to an SDL block Proto-

col'L,,, ,. Each communication path is converted to a delaying channel such as cl,

c2, C3, and c4. The signals correspond to the messages flowing through the channel.










3.1.1.7 Examples

The example shows a part of the Service Specific Coordination Function

(SSCF) for the User-Network Interface (UNI) in the ATM signaling system [66].

The SSCF_UNI layer provides a mapping function between UNI Signaling layer and

Service Specific Connection Oriented Protocol (SSCOP) layer. The basic structure

of SSCF_UNI is an example of the pattern protocol layer as Figure 3-4.


UNI Signaling MESSAGES=AAL EST.reqAAL EST.ind,
AAL EST.confAAL REL.req,AAL REL.ind,
A AAL REL.confAAL DATA.reqAAL DATA.
ind,AA EST.reqAA EST.resp,AA EST.ind,
UNI2SSCF SSCF2UNI AA EST.conf,AA REL.reqAA REL.ind,
AA-REL.conf,AA DATA.req,AA DATA.ind;
SSCFUNI PATHS=
UNII2SSCF:AAL EST.reqAAL REL.req,
AAL-DATA.req;
SSCF2SSCOP SSCOP2SSCF SSCF2UNI:AAL EST.indAAL EST.conf,AAL REL.
ind,AAL REL.confAAL DATA.ind;
SSCF2SSCOP:AA EST.reqAAESTresp,
AA REL.reqAA DATA.req;
SSCOP SSCOP2SSCF:AA-EST.indAA -EST.confAA REL.
indAA REL.conT,AA DATA.ind;


Figure 3-4: Example of pattern protocol layer in SSCF at UNI

Three kinds of messages such as AAL_EST, AAL_REL, and AAL_DATA

are exchanged with the upper layer through the communication paths UNI2-

SSCF and SSCF2UNI. AAL_EST is used to establish a connection from the UNI

signaling layer in the form of a request and a confirmation such as AAL_EST.req

and AAL_EST.conf. It also informs the upper layer that an incoming connection

has been established by an indication message AAL_EST.ind. AAL_REL is used

to release the connection established. AAL_DATA is used by the upper layer to

send a data packet in a request form AAL_DATA.req. SSCF_UNI hands out a

received packet to its user in an indication form such as AAL_DATA.ind. The lower

interface has similar messages which uses the communication paths SSCF2SSCOP

and SSCOP2SSCF.

As an example of the pattern split protocol layer, we demonstrates a variation

of alternating bit protocol (ABP) [67] which provides simple but reliable message










transfer on a lossy lower layer. Figure 3-5 illustrates the architecture of the


Figure 3-5: Structure of ABP using split protocol layer

protocol. The upper interface uses two messages put and get for a reliable data

transmission. The lower interface uses messages datareq, dataind, ackreq, and

ackind to send and acknowledge messages, allowing for retransmission if necessary

to deal with message loss.

3.1.1.8 See also

Layers [1], Pattern Half Object + Protocol [68], Protocol Conduit [26], Service

Architecture [23], Service Provider Refinement [23], SDL and Layered Systems [69]

3.1.2 Mux

3.1.2.1 Context

In a layered design, there may be multiple blocks in an adjacent layer and

resolving the destination or source of the messages is required.

3.1.2.2 Problem

How can we resolve the destination or source of a message?

3.1.2.3 Solution

Use a table to map an instance of a block to its address. Figure 3-6 describes

the structure of a mux layer where the upper layer has several blocks, while

the lower layer has one block. Similarly, the pattern is applicable to the reverse

situation.


upper layer messages = put, get,
usn data req, data ind,
up2snd rcv2up ack_req, ackmd;
paths=
sender receiver up2snd: put;
rcv2up: get;
lo2snd snd21o: data req;
snd2lo rcv21 lo2rcv lo2rcv: data ind
rcv2lo: ack req;
lower layer lo2snd: ack ind;











upper block1 upper block messages = list all messages used in
the pattern;
Pi P2 p3 p4 ...
V if paths=
Sp1 : messages passing through p,;
Mux Block p2 messages passing through p2;

P 6 name instance address
lower block



Figure 3-6: A structure of pattern mux

3.1.2.4 Implementation

Figure 3-7 shows an implementation of the pattern mux where the Muz_Block

is an SDL process, and communication paths such as rl, r2, r3 are signal routes.

The process array, MuzTable shows a trivial implementation of the address

resolution. It stores every instance identifier, PID, with the key name. The signals

enumerate the messages flowing through the signal routes. Note that the signal

routes of the upper interface are joined in one point to be connected with the

outside channel.


BLOCK r2 r4 SIGNAL
MuxLayer [msg2, ...] [msg4, ...] msgl, msg2,
msg3, msg4,
rl r3
[msgl ...] [msg3, ...]
Mux Block NEWTYPE Mux Table
-ARRAY (name, PID)
r \ ENDNEWTYPE;
r5 r6 SYNTYPE name
[msg5, ..] [msg6, ...] charstrings;


Figure 3-7: SDL implementation of pattern mux

3.1.2.5 See also

mux conduit [26]

3.1.3 Dynamic Handler

3.1.3.1 Context

A block needs to handle multiple communications at the same time. The

expected load will be variable and the system is appropriately sized to handle it.









3.1.3.2 Problem

How can a block be organized internally to service multiple communication

requests?

3.1.3.3 Forces

Concurrent processing: To provide a good response time, requests should be

processed concurrently.

Cpo,, 'f,, Handling concurrent requests imposes overhead for context

switches, resource contention, etc. If too many requests are handled at the

same time, the overhead will dominate the computation and the system

performance will degrade unacceptably. Therefore the amount of concurrency

should be bounded. Finding the optimal bound may be difficult to determine.

Static vs .*li,,.i,,l; handler creation: A communication request is serviced by

a handler, an instance of a block servicing the request. An important design

decision considers when the handler instances should be created. The static

approach creates all handlers at the system start-up time and their lifetime

extends until the system is shut down. When not servicing a request, the

handlers are idle, but still utilizing system resources. On the other hand,

an idle handler may be quickly deployed to handle a new request with little

overhead.

The dynamic approach creates a handler upon a request and its lifetime

spans only as long as necessary to service the request. This approach incurs

overhead for handler creation and termination, but there are no idle handlers

to unnecessarily consume system resources. Thus the resources used by

request handling adapt to the load.

A static approach is useful when the system load is uniformly high. A

dynamic approach is better when the system is appropriately sized and the










load is variable. Hybrid approaches combining aspects of static and dynamic

handling are also possible.

3.1.3.4 Solution

The context of this pattern leads us to choose a dynamic approach. The

solution utilizes a single instance of a static block, Admin, (an example of the

Singleton Pattern [2]) which is created at system startup time. The instance waits

for a communication request message from adjacent layers. Upon arrival of the

request message, Admin serves as a factory [2] and dynamically creates an instance

of the block Handler. The Handler instance then services that communication.

After the communication has been serviced, the instance is terminated. The

maximal number of instances of Handler that can be created is bounded by a

fixed number N. If there are more requests than N, Admin must either queue the

message, or more typically reject the request. N is determined empirically, or by

performance analysis using the expected load on the system.

P1 p3 messages = all messages
P P4 used in the pattern;

--- l__ paths -=
Admin (1,1) Handler (0,N) paths
p P5 : messages for p2
SPPs p : messages for P3;
P6 p8 p3 : messages for p3;
P7 P9


Figure 3-8: A structure of pattern dynamic handler

Figure 3-8 shows a structure of the pattern. First, the entity Admin waits

for a request through the communication paths either p2 or pe. Upon receiving a

message, for instance ,'.-1 through P2, the Admin creates an instance of Handler

block giving the necessary information for communication, for instance, the address

of the requester. The dotted line from Admin to Handler means the creation of an

instance. After being created, the instance starts communication through the paths

P3, p4, ps, and pg. When the communication ends, the Handler instance informs










the Admin of termination of service by sending, for example, a message msg5 and

ceases to exist.

3.1.3.5 Variant: split dynamic handler

The pattern dynamic handler considers only one type of handler. In communi-

cation systems, however, it is common to have handlers in pairs such as the pattern

split protocol layer. Figure 3-9 describes a dynamic creation of two type handlers,


P1 p3 p5 messages
and
P2 P4 P6 paths
\/ / \/ declaration
Outgoing --- Admin (1,1) -- Incoming
Handler (0,N) Handler (0,N)
p7 PS
P9 P11 P13
P10 P12 P14


Figure 3-9: A structure of pattern split dynamic handler

Outgoing Handler and Incoming Handler. The block Admin creates one of them

depending on the type of a request. All other behavior is similar to the pattern

.t,,II,/,;i handler. Note that the two handlers may need internal communication

between them.

3.1.3.6 Implementation

For the implementation of pattern liii,',,ii: handler, developers must consider

both the structure and the behavior of the blocks in the pattern. Figure 3-10

shows the structure of the pattern where two processes, Admin and Handler, exist

with the initial and maximum number of instances. The process Admin has one

instance during its life span, while the process type Handler has no instance at

startup time and can have the maximum N instances. The processes are connected

to the boundary of the block with signal routes which will interact with outside

channels. The behavior of the pattern needs the creation and termination of an

SDL process instance.























Figure 3-10: SDL implementation of pattern dynamic handler

3.1.3.7 Examples

Figure 3-11 shows a simplified file transfer server using the pattern dy-

namic handler. In this example, we do not present the interface with the lower

layer for simplicity. The server is composed of a block FTP_Admin and a block

FTP_Handler. When a user tries to download a file, an event FTP_connect goes to

the block FTP_Admin indicating a file transfer trial. The block creates an instance

of FTP_Handler to make it possible for the user to download a file from the server.

The instance sends a message FTP_connect_ok to indicate that it is ready to receive

a command. For the command get with a file name wanted, the FTP_Handler

provides the requested file with the message success. After getting the file, the

user sends a disconnect message which makes the instance stop after sending the

message terminate to the FTP_Admin.

A messages =
P3 FTP connect, FTP connect ok,
terminate, disconnect,
Pi P4 get (filename), success (file);
paths=
pi : FTP connect;
FTP Admin (1,1) FTP_Handler (0,N) 2: terminate;
p3: FTP connect ok, success (file);
p4: get (Tilenamey, disconnect;


Figure 3-11: A file transfer server using pattern dynamic handler

As an example of split dynamic handler, Figure 3-12 shows a simplified

version of call control block composed of Call_Admin, Oi,,fl'il iiH,_H, .1,'.r, and

Inc(i,..il_.Hiii1,'.:r in a switching system. When a calling party tries a call, a










message H_init goes to the block Call_Admin indicating that there is a call request

from a calling party. The block creates an instance of the block O',f il ,i.HIIt.1 r

in order to make the instance manage the calling party. After generating a message

L_init, the instance waits for a call connection from a called party.

p/ P4^ messages= H init,L init,
p8 L alert,H aTert,H answer,
P5 L answer-L complete,
Hicomplete;
Outgoing Call Admin Incoming
Handler (0,N) (1,1) Handler (0,N) paths p :H_init p:L_init;
p3:L alert; p4:H aert;
A\ A pps:-answer; pTL answer;
P? P3 p6 p:Lcomplete; pg:TI_complete;
P2


Figure 3-12: A call control block using pattern split dynamic handler

On the other hand, if the block CallAdmin receives a message L_alert im-

plying that there is an incoming call, it creates an instance of the block Incom-

;iJlHI'.II .:r to setup a call connection with the called party. A message H_alert is

used to indicate a new call is coming. When the called party answers, the messages

such as H_answer, L_answer, L_complete, and H_complete are transferred.

3.1.3.8 See also

DynamicEntitySet [70], ConduitFactory [26], Pattern Half Object + Proto-

col [68]

3.2 Behavioral Patterns

3.2.1 Communicating Extended Finite State Machine

3.2.1.1 Context

Many communication systems react to events coming from outside environ-

ments. The systems can be modeled by distinct states and transitions. When

a system receives an event, it moves from its current state to a new state while

performing some actions and providing output signals.

3.2.1.2 Problem

How can we describe the behavior of a communication system?









3.2.1.3 Forces

Und, ,c1i .fJii,'li;;f: The notation should capture the most important aspects

of the behavior of a system in a way that is convenient to express and can be

easily understood by a reader.

Completeness: The notation should be able to express all the important

aspects of a design.

Definedness: The notation should be well-defined, preferably standardized. A

formally defined notation allows the possibility of tool support for analysis,

simulation, verification, code generation, etc.

S4 ,l,;iiW;, The notation should remain tractable for systems with large

numbers of states.

Ease of implementation: The formalism should represent the system's behav-

ior in a way that can be easily mapped into an implementation language.

3.2.1.4 Solution

The behavior of a communication system can be described using a communi-

cating extended finite state machine (CEFSM). A CEFSM is a finite state machine

extended with local variables and parameterized communication events indicating

communication with another CEFSM [14, 71]. These state machines are very fa-

miliar to computer scientists and engineers and meet the criteria discussed in the

forces section. In particular, the local variables help with the scalability problem

by allowing, for example, an 8-bit counter to be represented by one variable instead

of 256 states. Other state based formalisms [29] may provide better support for

modularizing large designs at the expense of a more complex notation. A survey

of other formalisms that can be used for telecommunication systems design can be

found in [72].

When an event is initiated by the environment, the system updates local

variables, emits output events and transitions to a new state.









Definition 1 (CEFSM) A CEFSM is a 5-tuple (S, so, E, f, V) where
S is a set of states

so is an initial state
E is a set of events with their parameter lists

f is a state transition relation

V is a set of local variables ,l. ',.1 with their ,1,, and initial values, if any.

For a state, an input event, and a predicate composed of a subset of V, the state

transition relation f has a next state, a set of output events and their parameters,

and an action list describing how the local variables are updated.

As an example, see the following CEFSM:

CEFSM = ({S1, S2, S3, S4}, S1, {init, e(p), e2, o1, o2(p2,p3)}, f }),

where f has the four elements

{< S, init, S2, (x := 0), {0} >,

< S2, e l(p), S3, ( := X pl), {2(X, p)} >,

< S2, e2, S4, ("encoding e2"), {} >,

< S3, e2[x = 8],4, (-),{}>}

This CEFSM has four states, five events, and one integer variable. The input event

el has a parameter pi, and the output event 02 has two parameters, p2 and p3. The

four transitions among the states are represented by the relation f. For simplicity,

we do not give the types of variables and parameters.

As an internal event, we assume an init event to indicate the start-up signal of

the CEFSM. The tuple element < Si, init, S2, (x := 0), {Ol} > of relation f denotes

a transition that moves from S1 to S2 while assigning zero to the variable x and

generating the event or after the initial signal init. The action list can include the

brief activities during the transition in plain English as well as a variable update.










For example, "encoding e2" implies that the machine will encode the e2 received.

The actions will be refined in the later development phases.

As a precondition of a transition, we introduce a predicate, a boolean valued

expression of the local variables [14]. Upon receiving an event, the CEFSM

evaluates the predicate. If the predicate holds, the CEFSM executes the transition.

However, if the predicate does not hold, the CEFSM ignores the event and -t.,I\ at

the current state. An empty predicate is defined to be shorthand for true. In the

previous example, the transition from S3 to S4 has a predicate x = 8.

In this pattern language, we usually represent a CEFSM with a state tran-

sition diagram (STD), a directed graph whose vertices correspond to states and

whose edges correspond to transitions. Figure 3-13 shows an STD of the previous




init/x:=0/o1

S2
e,(p1)/x:=x+ p/ e2/encoding e2'/
02(x, pI)
S3, S4
e[x=8]/-/-


Figure 3-13: An example CEFSM represented in STD

example. Each state is represented by a circle, and the initial state has a dou-

ble circle. Each transition is labeled with an input event, action list, and output

events. It is denoted by input(parameters)[predicatej/actions/outputs(parameters).

The '-' symbol in a transition indicates that there is no corresponding field. Transi-

tions that do not alter the state are represented by an arc that points to itself.

Typically, a complex communication system is designed with a large number

of states and transitions. A CEFSM can be expanded by merging with other

CEFSMs.









Definition 2 (Merge of CEFSMs) Let M1 = (Si, si, El, fl, 01, V1) and M2

= (S2 2, E2, f2, 02, V2) be two CEFSMs. M1 D M2, merge of the two CEFSMs,

creates a new CEFSM (S, so, E, f, O, V) such that

S = S1 U S2. S is a union of S1 and S2.

So = 81, the initial state of M1.

E = E1 U E2

f = uf2

= O1U02

V VI U V2

The merge is formed by using the union operation between sets.

3.2.1.5 Pattern: basic CEFSM

This is the basis of the pattern language and is composed of a source state and

a target state. The transition relation f has only one element such as


basic CEFSM = {< S,, e, St, A, O >}


Note that the source state S, and target state St could be the same state. Fig-

ure 3-14 shows the STD of the pattern basic CEFSM.




e/A /O

St e/A/O

(a) (b)

Figure 3-14: Pattern basic CEFSM

Property specification. In the pattern basic CEFSM drawn in Figure 3-14

(a), the input event e has to occur eventually to initiate the transition. In the case

of Figure 3-14 (b), it is necessary for the input event to occur infinitely often to

repeat the transition.









Property: The input event e has to occur eventually.

LTL: Oe

Property: The input event e occurs infinitely often.

LTL: Doe

After the occurrence of the input event, the output event 0 has to response to the

input so that the transition completes.

Property: The input event e is followed by the occurrence of output event 0.

LTL: O(e -- 00)

It is important to note that the latter property does not consider the correspon-

dence between the input and output events. Usually, one needs input and output

events to alternate. This property can be captured by introducing a global variable

n, initialized to zero to measure the number of events happened [47]. The counter

is increased when an input event e happens, whereas it is decreased if an output

event 0 occurs.

Property: The input event e and output event 0 occur alternatively.

LTL: D(0 < n, < 1), where n, initialized to zero is increased after e and

decreased after 0.

Meanwhile, if the state S, is the initial state of a whole system, the input event e

is the first event to have happened in the system. Accordingly, other events cannot

proceed the event.

Property: The event e proceeds all other events eo. None of the available

events can happen before e.

LTL: D(-e,) V (-e, U e)

Until now, the properties specified above apply to the entire computation. How-

ever, we can constraint the period in which the properties would apply. For

example, in Figure 3-14 (a), the input event e must happen between the state S,

and St.









Property: The event e must occur between the states Ss and St.

LTL: D((S, A -St) (St U ((e A -St) V E-S1)))

In addition to the existence property, it is also possible to specify the absence

property of an event.

Property: The event e must not happen before the state S, and also after the

state St.

LTL: (OS, (-e U S,)) A (E(St -- O(e)))

Since every pattern of our pattern language is based on the pattern basic CEFSM,

the properties mentioned in this pattern are also applicable to other patterns. It

is worth noting that the properties presented in this section are not a complete set

of properties possible in the pattern. The key idea is to capture and deduce the

properties required in a system from the visual pattern.

3.2.1.6 Variant: predicate CEFSM

As we mentioned at the definition, a CEFSM can have predicates to control

the behavior of the CEFSM [14]. The predicate indicates under what condition the

action will be taken. By adding a predicate to the pattern basic CEFSM, we can

get the variant predicate CEFSM. Meanwhile, an input event usually has several

predicates as a decision point. We, therefore, define the pattern having several

predicates.


predicate CEFSM = { < S,, e[<,, ,l;, ;It,1], St, A1, 01 >

< S,, e [!,, ,;, ,, t,2], St2, A2, 02 >



< Ss,> [}; t*,], Stn, A, ,O >}


Note that the source state S, and target states could be the same state. If the

predicates are mutually exclusive, then the CEFSM is deterministic. Figure 3-15

shows the STD of the pattern predicate CEFSM.


















Figure 3-15: Pattern predicate CEFSM
Property specification. The input event e has to occur eventually and at

least one of the predicates must hold at that time to initiate the transition.

Property: The input event e happens eventually and at least one of the

predicates holds.

LTL: O(e A (predicate V .. V '.'.; ,,t, ))

Furthermore, the output event corresponding to the holding predicate has to

respond to the input event.

Property: The predicate predicate which holds at event e is followed by a

corresponding output event Oi where 1 < i < n.

LTL: D(((e A predicated) -* 001) V .. V ((e A ",(li;, ,,' ) OO ))

In addition to these two properties, it will also be necessary to consider the

properties presented at the pattern basic CEFSM from which the new properties

are deducible.

3.2.1.7 Variant: predicate after action

At the pattern predicate CEFSM, an input event is followed by predicates to

decide the next transition. However, in some cases decisions need to be made after

performing some actions. In other words, after performing a sequence of actions for

an input, an instance decides its next transition based on the result of the actions.









The instance therefore needs predicates after the actions.


predicate after action


{ < S, e,S1, A,,0 >

< S', -[prut litatel], St, A, 01 >

< SS, -[I)/.(\litrite2, St2, A2,O2 >


< S', -[prt /11icte,], Stn, A, O, >}


Note that the transitions from S' do not have event fields. Figure 3-16 shows the

STD of the pattern predicate after action. In fact, this pattern is a sequential


Figure 3-16: Pattern predicate after action

merge between the transition from Ss to to S and the predicate CEFSM. Refer to

the pattern sequential merge.

Property specification. First, the input event e must occur. Then at least

one of the predicates has to hold in the future.

Property: The input event e must happen eventually and at least one of the

predicates has to hold after the event.

LTL: O(e A O(preicatei V** edicredicate,))

Another property of the CEFSM is an occurrence of an output event following the

input and holding predicate.









Property: The input event e is followed by a holding predicate predicate1 and

the corresponding output event O.

LTL: D(e -- O((predicatel A 001) V .. V (predicate A 00)))

3.2.1.8 Variants: sequential, source, and target merges

Typically, a complex communication protocol is made by composing several

CEFSMs to fulfill the required functionality. There are three common types of

merge: sequential merge, source merge, and target merge. To introduce these

patterns, we classify a state in a CEFSM into either a terminal state or a nonter-

minal state. A state is called a terminal state if it is not used as a source state in a

transition of the CEFSM. Otherwise, it is a nonterminal state.

A sequential merge is a merging of a terminal state of a CEFSM with a

nonterminal state of another CEFSM. Figure 3-17 (a) shows the merging of

states S2 and S3. The combined CEFSM goes to state S4 through the state S23-

This situation is common when a system handles a sequential input from the

environment.




1 3 ~ ei/Ai/O0 1 3) S S3

e1/AI/OG e e2/A2/02 S23 eI/AI/O/ e2/A2/0 e1/AI/O1 e2/A2/2
ee2/A2/02
S2 S4 S2 S4 S24
S4
(a) (b) (c)

Figure 3-17: Merge patterns combined from two CEFSMs

The pattern source merge combines each nonterminal state of two CEFSMs.

In Figure 3-17 (b), the initial states, S1 and S3, are combined, and the resulting

CEFSM has three states and two transitions. This behavior commonly occurs in a

state receiving several potential input events.









The pattern target merge is obtained by combining each terminal state of a

CEFSM. This is usual when two transitions want to stay at the same state after

each transition. Figure 3-17 (c) shows a typical example.

Property specification. The pattern sequential merge is a combination of

two basic CEFSMs in sequence. Thus, the input events happen in order.

Property: The input event e1 has to occur eventually to initiate the CEFSM.

LTL: Oe1

Property: The input event e1 is followed by the events 01, e2, and 02.

LTL: D(ei --- 0(0 A O(e2 A 02)))

Frequently, it is sufficient to check that the initial input e1 is followed by the final

output 02 such as

Property: The input event e1 is followed by the output event 02.

LTL: D(ei -- 002)

Furthermore, the input e2 cannot happen before the input e1 because e1 is the first

event of the CEFSM.

Property: The event e1 proceeds the event e2.

LTL: Oei -- (-e2 U ei)

Note that the second property does not consider the correspondence between each

event. These events have to happen alternatively. This property can be captured

by introducing the global variables ni, n2, and n3 which are initialized to zero. The

variables count the number of events happened [47]. The counters are increased

when the events el, 01, and e2 happen, while they are decreased if the events O1,

e2, and 02 occur.

Property: The events el, 01, e2, and 02 occur sequentially and alternatively.

LTL: D((0 < n < 1) A (0 < n2 < 1) A (0 < n3 < 1)), where the counters

are increased when the events el, 01, and e2 happen and decreased when the

events 01, e2, and 02 occur.










For the case of pattern source merge, the two inputs have to occur to check

both the cases.

Property: The input events e and e2 have to occur eventually to initiate the

CEFSM.

LTL: Oei A Oe2

3.2.1.9 Implementation

The basic CEFSM is implemented in SDL by a mechanical one-to-one mapping

from its STD. Figure 3-18 shows an SDL diagram fragment for the basic CEFSM

of Figure 3-14 (a). Each state of the CEFSM is converted to the corresponding


Ss

Qe

A
e/A /O

St
St


Figure 3-18: SDL fragment for pattern basic CEFSM

SDL state. A transition is represented by an input signal, a task for the action, and

an output signal. When an instance of the pattern receives an input event e with

its parameters in the state Ss, it performs the task A and generates output signal

O. Note that if the transition expresses an initialization with the init internal

event, the source state has to be translated to a start symbol. The internal event is

not shown at the SDL implementation.

The implementation of pattern predicate CEFSM leads to an SDL decision

symbol. Figure 3-19 shows an SDL diagram fragment for Figure 3-15 where there

are n predicates for an event e. Upon receiving an event e, the CEFSM checks the

predicates and then performs actions for a true predicate. The pattern predicate

after action is similarly implemented as Figure 3-19 with a decision symbol after










the actions. It it important to note that the state S' of Figure 3-16 is not shown in

the SDL diagram.


Figure 3-19: SDL fragment for pattern predicate CEFSM

The implementation of merge patterns can be obtained by straightforward

mapping of the resulting STDs. We omit the SDL implementation of the patterns.

3.2.1.10 Example

As an example of the pattern predicate after action, Figure 3-20 shows an

error detection method which performs the checksum for an input msg(data). If


Figure 3-20: Example of pattern predicate after action for error detection

the result of the action procedure has zero value, which means that there is no

error in the received message, the CEFSM performs the decoding and generates the

output message msg(ok). Otherwise, the input message has an error, and an error

notification message msg(nok) is sent. Note that the predicates rst = 0 and rst !

0 are evaluated depending on the previous action checksum().


e[predicate ]/ \e[predicate]/
A1/O1 A/On

Sti ( S,


wait-data
msg(data)/
rst: =checksum(data)/-
wait data'
-[rst != -[rst= 0]/"decoding"/
msg(nok) msg(ok)
error proceed










From the property specification of the pattern, we can get the following

requirements of the CEFSM.

Property: The input event msg(data) has to happen eventually and the

checksum will have zero or non-zero value for the data.

LTL: 0(msg(data) A 0((rst!=0) V (rst=0)))

Property: The input event msg(data) is followed by one of output events

msg(nok) or msg(ok) depending on the result of predicates.

LTL: D(msg(data) -+ 0(((rst!=0) A Omsg(nok)) V ((rst=0) A Omsg(ok))))

As an another example, let us suppose we are designing a system that uses

the connection oriented communication with other systems. The system handles

connection establishment and release requests to setup a connection with a peer

system and to release the connection. Figure 3-21 (a) shows the connection

setup scenario using the pattern basic CEFSM. After receiving a connection


wait wait
stablis release

EST.conf REL.conf

established released
(a) (b)

wait
(arsg establis
EST.req/connect/ REL.req/disconnect/ EST.req/connect/
EST.conf REL.conf EST.conf

established released established
REL .req/disconnect/
(c) REL.conf
released

(d)

Figure 3-21: Example of merge patterns

request EST.req, the CEFSM performs action "connect". Then, it notifies the

peer that the connection is set up by using the message EST.conf. Similarly, the

disconnection step is also achieved in the pattern basic CEFSM as Figure 3-21 (b).









In fact, it is possible to handle the two requests at one state. Note that the

CEFSMs for connection setup and release have different state names. Before

merging the CEFSMs, we rename both wait_establish and waitrelease to wait_msg.

The merged CEFSM is described in Figure 3-21 (c), and it is an example of

pattern source merge.

On the other hand, a connection can be disconnected only after the connec-

tion is setup. Figure 3-21 (d) show that the connection CEFSM is sequentially

merged with the disconnection CEFSM. The state waitrelease was renamed to

established before the merging. The state released can be reached through the state

established. The requirements of the result CEFSM can be obtained as follows:

Property: Eventually, the input event EST.req has to occur to initiate the

connection.

LTL: OEST.req

Property: The input event EST.req is followed by the event EST.conf,

REL.req, and REL.confin sequence. In other words, before the request of

connection release REL.req, the connection was established by EST.conf.

LTL: O(EST.req -- O(EST.conf A O(REL.req A OREL.conf)))

Property: The event EST.req proceeds the event REL.req. In other words,

before the connection release request, the connection must be established by

EST. req.

LTL: OEST.req (-REL.req U EST.req) ce.

Property: The events EST.req, EST.conf, REL.req, and REL.conf must

happen alternatively.

LTL: D((0 < ni < 1) A (0 < n2 < 1) A (0 n3 < 1))









3.2.1.11 See also

To describe the CEFSM, we use the STD with transitions labeling with an

event, predicates, actions, and outputs. The similar notation is used at State-

charts [29], a visual formalism for the specification of reactive systems, where a

transition is labeled with an event, a condition, and an action. Statecharts are an

extension of our STD to enhance the descriptive power using hierarchy of states,

orthogonality, and history connectors.

3.2.2 Timer

3.2.2.1 Context

In an event-driven system such as a communications system, an event may

occur later than it is expected, or not happen at all because of transmission delay,

lost message, etc. Many event-driven systems employ timing constraints where

some action is taken if an expected event does not occur in a given amount of time.

We are designing the system in CEFSMs.

3.2.2.2 Problem

How can we model the timing constraints to avoid unbounded waiting for an

event?

3.2.2.3 Solution

A CEFSM can be supplemented with a timer and timer-related operations

to manipulate the timing constraints [14]. A timer T is an element of variable

set V with an associated time value. It has two modes, active and inactive.

Initially, a timer is inactive. The unit of a time value depends on the context of

an application. There are timer-related operations, set and reset, which are the

elements of action list A. 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 all

these time concepts come from SDL [14].




Sejset(v,T),
Al/O1
Si
T/A2/O e /reset(T),
2 A3/03
S2 S3



Figure 3-22: Pattern timer with the expected event e

Figure 3-22 shows an STD of the pattern timer. First, a timer T should be

set before using it. In the diagram, the transition happens upon the event eo. On

timer expiration for T, the CEFSM moves to the state S2. If the CEFSM receives

the expected event e, it resets the timer and performs the remaining transition.

3.2.2.4 Property specification

First, the input event eo must occur eventually to initiate the CEFSM.

Property: The initial input event eo must happen eventually.

LTL: Oeo

Then, either the intended event e or time expiration T has to follow the input

event eo.

Property: The input event eo is followed by either an event e or a time

expiration T.

LTL: D(eo O(((e A -T) V (-e A T)))










There is a possibility to arrive at the intended event e after T is taken due to the

delay of the event. If the delayed delivery of an event is not allowed in the system,

we also have to describe this property using the absence property.

Property: After a timeout T, no e occurs.

LTL: D(T -+ D(-e))

3.2.2.5 Implementation

A timer variable in the CEFSM maps to an SDL Timer object. The Timer

object must be declared like any other variable in SDL. In addition, the time

value is given as part of the declaration. The operations on the Timer object are

set(Timer) and reset(Timer). Since the time value is given in the declaration, it is

not specified in the set operation. Figure 3-23 shows the SDL implementation of

the typical timer pattern discussed above.


Timer T:= v;

so S1

e/set(v,T), T e
A1/01 set(T) A2 reset(T)

I A, O, A3
e/r eset(T), 1 2
T/A/02 A3/O3 01 S 03

S2 S3 S S3


Figure 3-23: SDL fragment for pattern timer

3.2.3 Repeated Events

3.2.3.1 Context

In an event-driven system, a single event may not be sufficient to initiate

a reaction: an event must occur several times. For example, if a message is

transmitted in several packets, all packets must arrive before the further message

handling.










3.2.3.2 Problem

How does a communication system handle the repeated events?

3.2.3.3 Forces

Timing constraints: It is necessary to impose timing constraints for the

repeated events. There are two kinds of timing constraints such as for the

individual event and for all events.

Number of repetitions: In some cases, the number of repetitions is known in

advance. In other cases, it is not. Even when the number is not known in

advance, there still may be an upper bound on the number of repetitions.

3.2.3.4 Solution

This pattern is a specialization of the pattern predicate CEFSM. First, the

CEFSM has an integer variable c which is initialized to one to count the number of

occurrences of an event. Predicates c < N and c = N determine the next transition

where N is the number of times the event should be repeated. If c is less than N,

then c is incremented and the state unchanged. Otherwise, the state changes to the

the next state and any specified output events are generated. Figure 3-24 shows

the solution and its SDL implementation.


S1 DCL
c integer: =1;
N integer: =MAX;


(< N) (== N)
e[c Sc:=c+1,A1/O1
A1 02
e[c =N]/A2/O, 2
SS




Figure 3-24: Pattern repeated events and its SDL implementation









3.2.3.5 Property specification

The input event e has to occur to initiate the CEFSM and the counter c

should be one at that time.

Property: The input event e has to happen eventually and the counter c is

one at that time.

LTL: O(e A (c = 1)), where c keeps the number of occurrences of event e.

Then, the event happens (N-1) times more and then it is followed by an output

event 02.

Property: The input event e and predicate (c = 1) is followed by (N-l) times

e and 02.

LTL: O((e A (c = 1)) ((e A (c = N)) A 002))

Moreover, the event e should not happen after the N-th occurrence.

Property: The input event e cannot happen more than N times.

LTL: D(1 < c < N)

3.2.3.6 Variant: timed repeated events

In this variant, we add timers to enforce timing constraints. This pattern can

thus be considered as a combination of the patterns of repeated events and timer.

Two timers TI and T2 are used in the pattern. Timer T1 is used for the individual

occurrences of event e, while T2 is used for all of the events together. Figure 3-25

shows the resulting CEFSM and its SDL implementation. At the state S1, the

CEFSM receives the event e until it has all events needed. If the number of events

is less than N, the machine increases the c and sets the timer Ti again. If the timer

Ti or T2 expires, the machine moves to the corresponding state to handle this

exceptional case. Note that either timer could be omitted but not both. Then only

the total or single event timing constraints would be checked.

























Figure 3-25: Pattern timed repeated events and its SDL implementation

Property specification. This pattern is a combination of the pattern

repeated events with the pattern timer. Therefore, we can deduce the properties of

this pattern from their ones.

Property: The initial input event eo must happen eventually.

LTL: Oeo

Then, the event is followed by one of the three possible events.

Property: The input event eo is followed by one of three input events e, T1,

and T2

LTL: O(eo 0O((e( A (c = N)) A -Ti A -T2) V (-(e A (c = N)) A T A -T2) V

((e A (c = N))- A T A T2)))

Property: The subsequent input events are followed by each corresponding

output event.

LTL: D(((e A (c = N)) -- 003) A (T -- 004) A (T2 005))

As a simplified property of the above properties, we may check that the initial

input event eo is followed by one of three output events 03, 04, and 05.

3.2.3.7 Variant: timed retrial

In the previous patterns, the number of repetitions of an event before the

system moved to a different state was known in advance. This variant considers the










case where the number of repetitions is not known in advance (and may be 0), but

the maximum number is bounded. A typical scenario would be where the repeated


So S DCL c integer:=;
N integer:=MAX;
Timer T := v;


set(T)

Al ( e0/set(v,T), A1/O1
01 set(T) reset(T)
Si T[c / set(v, T),A, /0, I I --, I -




S2 S3 S3 S_


Figure 3-26: Pattern timed retrial and its SDL implementation

event is the expiration of a timer set. For example, a message is transmitted and

the timer is set. If an acknowledgment is not received before the timer expires, the

message is retransmitted. The message will be transmitted a maximum of N times

before the system moves to an error state. Figure 3-26 shows the solution where

the repeated event is the expiration of the timer.

Property Specification. The pattern timed retrial has a similar state

transition diagram as the pattern timed repeated events. It needs the initial input

eo which will be responded by either the target event e or N-th expiration.

Property: The input event eo has to occur eventually.

LTL: Oeo

Property: The input event eo is followed by either the target event e or N

times timeout.

LTL: (eo -- 0((e A -(T A (c = N))) V (-e A (T A (c = N)))))

Property: After N-th expiration, no timeout T exists.

LTL: D(1 < c < N)









3.2.3.8 Example

Figure 3-27 (a) describes a part of a call setup software. It receives a tele-

phone number composed of nine digits from a caller. After receiving the event dial

nine times, the CEFSM generates an output connreq to request a call connection

with a callee of the number. The example can be expanded with a timer T to avoid



FTP req/c:=1,set(5,T)
/FTP connect
S dial(digt)lc<9]/ cT[c < 10]/c:=c+1,
dialing ) "store digit", connecting) set(5, T)/
c:=c+l;/- FTPconnect
connect ok/
dial(digit)[c=9]/"store reset(T)7 T[c=N]/-/FTP_fail
digit"/conn_req(digits) FTPready

connection (connected connecterror


(a) (b)

Figure 3-27: Nine-digit dialing using pattern repeated events

unlimited waiting. If a caller does not push a digit in a given time bound, the

machine notifies the caller that time is over by giving a special beep. This case is

implemented by adding a transition for the timer expiration. The following are the

part of properties obtainable from the patterns used.

Property: A call connection request needs nine digits.

LTL: D((dial(digit) A c = 1) -* 0((dial(digit) A (c = 9)) A Oconnreq))

Property: A call connection needs nine digits in the timing constraints T.

LTL: D((dial(digit)Ac = 1) O(((dialA(c = 9))A-T)V(-(dialA(c = 9))AT)))

As an example of the pattern timed retrial, Figure 3-27 (b) shows an FTP

client that receives an FTP request from a user and try to connect to an FTP

server. The following are the properties obtainable from the example.

LTL: OFTP_req

LTL: D(FTP_req O(0(connect_OKA-(TA(c = 9)))V(-connect_OKA(TA(c =

9)))))









3.2.3.9 See also

Pattern TimerControlledRepeat [70] repeats a message transmission to avoid

message loss during data transfer. If a sender entity does not receive an expected

acknowledgment in the given expiration time from a receiver entity, the message

is repeated by the sender. This pattern is considered as an instantiation of the

pattern timed retrial.

3.2.4 Message Transfer

3.2.4.1 Context

In a communication network, two communicating entities in the same layer

want to interact to transfer messages through their lower layer.

3.2.4.2 Problem

How do two communicating peers interact in a layered protocol?

3.2.4.3 Forces

Role of interaction: In the communication, one party initiates communication

and another reacts to it. Thus, it is important to identify the role of entity

before communication.

3.2.4.4 Solution

Conceptually, a layer provides a set of services to its users. Thus, the users

consider the lower layer as a service provider [64, 73]. They communicate with

the service provider through service access points (SAP). The service provider

coordinates and manages communications between users by using four types of

primitives, request, indication, response, and confirm, as shown in Figure 3-28.

The user A initiates a message transfer with the peer B by invoking the primitive

request to the lower layer. The peer of the initiator is informed by the lower layer

using the primitive indication. The respondent replies to the indication by invoking

the primitive response to the lower layer. The lower layer notifies the initiator of






















Figure 3-28: Protocol layer as a service provider

the response from the peer using the primitive confirm. Depending on the protocol,

the name of each primitive might be different.

Typically, there are two kinds of communication between peers such as con-

firmed transfer and unconfirmed transfer. If an initiator needs an acknowledgment

from a peer, it uses a confirmed transfer with the four primitives. However if this is

not the case, the initiator sends a message without expecting an acknowledgment.

For example, a connection establishment always uses a confirmed transfer because

a peer must agree to establish a connection with its initiator. A data transfer,

on the other hand, uses either confirmed or unconfirmed transfer depending on

protocol [73].

3.2.4.5 Variant: unconfirmed sender

The pattern unconfirmed sender given in Figure 3-29 (a) initiates a simple but

unconfirmed message transfer. It does not care about the progress and result of

message transfer once it has been initiated.




e/A1/request,01 indication/A2/02

S2 S4

sender receiver


Figure 3-29: Patterns unconfirmed sender and unconfirmed receiver









Property specification. If a system is designed with this pattern, it is

necessary to check the following properties, but are not limited.

Property: The input event e has to occur eventually and it must be followed

by an occurrence of request.

LTL: Oe A O(e -- Orequest)

Property: The events e and request occur alternatively.

LTL: D(0 < nr < 1), where nr, initialized to zero is increased after e and

decreased after request.

Example. An IP datagram sending at Internet Protocol (IP) uses an

unreliable, best-effort, connectionless packet delivery system [74]. As a user's point

of view, the transfer of an e-mail is also the unconfirmed transfer of a message.

See also. Push Interaction Pattern [30], SendReceive [23]

3.2.4.6 Variant: unconfirmed receiver

The pattern unconfirmed receiver takes a message from a sending party

in the form of indication as shown in Figure 3-29 (b). It does not reply to the

sending party. It is important to consider a receiving party with a sending party

simultaneously because a message transfer is typically performed in pairs. If the

pattern unconfirmed receiver communicates with the pattern unconfirmed sender,

the indication corresponds to the request of unconfirmed sender.

Property specification. Since this pattern has a similar STD such as

the pattern unconfirmed sender, the properties specified at the pattern are also

applicable here.

Property: The input event indication has to occur eventually and it must be

followed by 02 if the output exists.

LTL: Oindication A O(indication -* 002)

Property: The events indication and 02 occur alternatively.










LTL: D(0 < nio < 1), where nio initialized to zero is increased after the

occurrences of indication and decreased after O02

Moreover, it may be necessary to check the correspondence of indication to the

request if both unconfirmed sender and unconfirmed receiver are used in pair.

Property: The indication must always follow the request and each event has

to happen alternatively.

LTL: O((request -* Oindication) A (0 < nKi < 1))

Example. Reception of an IP datagram uses the unconfirmed receive. As a

user's point of view, the reception of an e-mail is also the unconfirmed receive.

See also. Push Interaction Pattern [30], SendReceive [23]

3.2.4.7 Variant: confirmed sender

To initiate a confirmed message transfer, the pattern confirmed sender starts a

message transfer with a primitive request. Then, it waits for a confirmation from

its peer. The primitive confirm would contain the result of request, for instance,

successful transfer of request, request refusal due to resource insufficient, etc.

Figure 3-30 (a) depicts the typical behavior of the pattern where the transition

labeled with request is sequentially merged with the transitions that have several

confirmation messages.




eI/Al/
e1lAi/request,01 GetRequest-PDU

S2 S2
Res onse-PDU/
confinnI /A2IOG / con m 2AJGO2 ... A/Op U
CO /2121 /A22/022 *0* A2 1

S31 S32 ... S3
requester SNMP_getrequester

(a) (b)

Figure 3-30: Pattern confirmed sender and its example on an SNMP client









Property specification.

Property: The input event e1 has to occur eventually and the request follows

the event.

LTL: (Oei A O(ei -- Orequest))

Property: The request is followed by one of confirmations.

LTL: D(request O((confirmA A -confirm2 A ... A -confirmn) V .. V

(-confirmn A -confirm2 A A confirmn))
Moreover, it is also necessary to check the correspondence between the request and

confirmation messages.

Example. A network management protocol allows a network manager to

monitor and debug the nodes attached to the network. A client of the Simple

Network Management Protocol (SNMP), a standard TCP/IP network manage-

ment protocol, needs a value of a host to check the status of the machine [75].

Figure 3-30 (b) presents an abstract behavior of the client which asks a value of

a variable in a system using the message GetRequest-PDU. Then, it receives the

result in the message Response-PDU. If the value was accessible at the remote

machine, value field is set to the corresponding value. Otherwise, error status field

has a non-zero value which indicates that an error occurred during the request

handling. Connection establishment request at two-way handshake, status query,

and resource reservation request also use this pattern.

See also. Pull Interaction Pattern [30], BlockingRequestReply [23]

3.2.4.8 Variant: confirmed receiver

After receiving a request from its peer, a confirmed receiver processes the

request and then replies with an appropriate response message. There are three

common ways to handle the behavior. In Figure 3-31 (a), a receiver takes an

indication from a peer. Then, it decides an appropriate response after performing

action A1. The response message includes the information that indicates the type










of response such as success, remote host down, illegal address, etc. Another case is

to reply with one of possible response messages which holds a predicate after action

A1 as in Figure 3-31 (b). There are many different names for each response in this

case. As a last case, a receiver waits for another event which indicates the result of

request handling.




indication/A/- indication/A1/O1


indication A
response,01 -[predl]/A21/ -[pred2]/A22/ e21/A21/ e22/A22
response 1,02 response2, 022 response ,02 response2,022

S2 S31 S32 ... ( 31 S32 .

(a) (b) (c)

Figure 3-31: Pattern confirmed receiver in three common cases

Property specification. Since the STDs given in Figure 3-31 have the

same form as in basic CEFSM, predicate after action, and confirmed sender, we

can infer the properties of this pattern from them. The following are the properties

applicable to Figure 3-31 (a).

Property: The input event indication has to occur eventually and it is

followed by the occurrence of response.

LTL: Oindication A O(indication -- Oresponse)

Property: The events indication and response occur alternatively.

LTL: D(0 < ni, < 1) where ni, initialized to zero is increased after the

occurrences of indication and decreased after response.

In the case of Figure 3-31 (b) and (c), we can also infer the following property.

Property: The input event indication is followed by one of response messages.

LTL: O(indication -> responsensl A -response2 A ... A -responsen) V ... V

(-response A response A -response A .. A responsen))









Example. As a corresponding receiver of SNMP protocol which is given

in the example of confirmed sender, a remote host receiving GetRequest-PDU

processes the variable binding to produce a Response-PDU. If the binding fails,

a Response-PDU is replied with an error status field set. Many servers in the

client-server model use this pattern to handle a request from clients. For example,

a time-of-day server returns the current time when it receives a time request from a

client [74].

See also. Pull Interaction Pattern [30], BlockingRequestReply [23]

3.2.4.9 Variant: timed receiver and timed retrial receiver

The pattern timed receiver waits for an intended message, indication, after

setting a timer. If the timer expires before receiving the message, the pattern

considers it as an error case. This pattern is a combination of an unconfirmed

receiver with a timer. As a general case of this pattern, we can try to receive the



0 0
e/set(v,T), A/O, e/set(v,T),c:=1,A1/O1

S ) S )T[c T/AO /indication! T[c=N]/A3/03 indicationlreset(T),A4/04
/ reset(T) \,/O,
S, S3 S2 S3

timed receiver timed retrial receiver

Figure 3-32: Patterns timed receiver and timed retrial receiver

intended event several times, which is called timed retrial receiver. Figure 3-32

represents the patterns. Note that it is also possible to have patterns timed

confirmed receiver and timed confirmed retrial receiver for confirmed message

reception in timing constraints.

Property specification. The following is a property applicable to the

pattern timed receiver.









Property: The initial input event eo must happen eventually and it has to be

followed by either an intended event indication or a timeout T.

LTL: Oeo A D(eo O0((indication A -T) V (-indication A T)))

In some cases, the indication could arrive after T because of event delay. If a

delayed delivery of an event is not allowed in a system, we can describe this

property using an absence property.

Property: After a timeout T, no indication can occur.

LTL: D(T -> -Oindication) or equivalently, D(T ->* O(indication))

For the pattern timed retrial receiver, we have to check the number of occurrences

of timeout in addition to the event existence and respondence.

Property: The input event eo is followed by either the event indication or N

times timeout.

LTL: Oeo A D(eo -* O((indication A -(T A (c = N))) V (-indication A (T A (c =

N)))))

Property: After N-th timeouts, no timeout T exists.

LTL: D(1 < c < N) or equivalently, D((T A (c = N)) O-T)

Example. In the ATM signaling protocol, an access switch waits for

an ALERT message from a called party in 10 seconds. If it fails to receive the

message, it assumes that there is some problem with the called party and proceeds

to clear the call connection.

See also. Pattern Timer [76]

3.2.4.10 Variant: timed confirmed sender and timed retrial confirmed
sender

In the pattern timed confirmed sender, a CEFSM requests a message transfer.

Then it waits for a confirmation message from its peer within a certain time

interval. If a timer expires before the reception, the sender considers it as an error

or abnormal case. As a general case of this pattern, the sender retries the request










until it receives the confirmation or reaches the maximum number of repetition.

The timed retrial confirmed sender retransmits the request at most N times.




e1/set(v,T),A1/ e1/set(v,T),c:=l,
request,01 Allrequest,01
ST[c S2 S c:=c+l,set(v,T),A2/
request, 02
T/A T/O T l) *** T[c=N]/AT/OT CO in1 set(T)A21/021 ...

s31) ... (3 T3 ..."n

timed confirmed sender timed retrial confirmed sender

Figure 3-33: Patterns timed confirmed sender and timed retrial confirmed sender

Property specification.

Property: The input event eI has to occur eventually and the request follows

the event.

LTL: (0ei A D(ei -- OKrequest))

Property: The request is always followed by one of the confirmation messages

or timeout T.

LTL: O(request -+ O((T A ... A -confirmn) V ... V (-T A ... A confirmn))

In the case of pattern timed retrial confirmed sender, we also need to check the

number of occurrences of timeout.

Property: The request is followed by either one of confirmations or N times

timeout.

LTL: O(request -> O((T A (c = N)) A ... A -confirm,) V ... V (-(T A (c =

N)) A ... A confirmrr))

Property: After N-th timer expiration, no timeout T exists.

LTL: D(1 < c < N) or equivalently, D((T A (c = N)) -- OT)

Example. As an example of timed confirmed sender, we can consider

ping command in UNIX which tests reachability of a host using the Internet









Control Message Protocol (IC1'0 P) [74]. A host sends an IC'iP echo request,

ECHO_REQUEST, to a specified destination and sets a timer for it. The default

value of timeout is 20 seconds. If the request is answered with the ECHOREPLY

within the given time, the sender prints a successful result. Otherwise, it indicates

the failure of the request. TCP timer/retransmission and Bootstrap Protocol

(BOOTP) retransmission also use this pattern [74].

See also. TimerControlledRepeat [23], PAR (Positive Acknowledgment with

Retransmission) [73], Bounded Retransmission Protocol [46], Abortable Interaction

Pattern [30].

This is the end of pattern message transfer. As mentioned before, the patterns

presented in this section are not a complete set. They can be combined to obtain

more complex and high-level patterns. For example, we can get a new pattern,

confirmed sender-receiver, a combination of confirmed sender and confirmed

receiver for negotiation of communication. At an initial state, it sends a request

to a peer, and then wait for a confirmation such as confirmed sender. Then, for

the confirmation message, it replies with an acknowledge message to guarantee

that the confirmation is agreed upon. This behavior is well-known as a three-way

handshake [74].
















CHAPTER 4
MODEL CHECKING PATTERN-BASED DESIGN

4.1 Modeling Pattern-Based Design in PROMELA

In our development methodology, the pattern-based design is followed by the

validation of design specification to find errors in the design phase. The formal

validation using SPIN needs to construct a model for the design specification and

validate the model against the properties to be satisfied in the design. Figure 4-1

shows an overview of SPIN model checking for a pattern-based system. After


Requirements Analysis and
High-level Design




-i Modeling in Properties
PROMELA in LTL





SPIN
pass

fail

Counter
Example


Figure 4-1: Model checking pattern-based system using SPIN

the high-level designing, we can construct the PROMELA model and obtain the

correctness properties of the final system. In this section, we present a model

construction mechanism from the system design description and issues arising in

the construction.










A model that is consistent with the design is essential to the subsequent

validation results because any violation in the model has to exactly reflect the same

fault of the design. The correspondence between our patterns and PROMELA makes

it simple to build a consistent model of the design. The patterns are composed

of blocks, communication paths, messages, dynamic creation of block instance,

states, transitions, predicates, repetition, action list, state merge, timers, etc. Most

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


caller MESSAGES=
m dial,connreq; dial(digit)lc<9]/
from caller di-almging) ) "store digit",
c:=c+l;I
PATHS =
nine_digitdial from caller:dial; dial(digit)[c=9]/"store
Stolower:conn req; digit"/conn_req(digits)
to lower
connection
lower
nine_digitdial

(a) (b)

Figure 4-2: Nine-digit dialing in call setup

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.

1 #define BUFFSIZE 2 /* channel capability */
2
3 chan from_caller = [BUFFSIZE] of {mtype,DIGIT};
4 chan to_lower = [BUFFSIZE] of {mtype,DIGITS};
5 mtype = {dial,conn_req};
6
7 proctype nine_digit_dial() {}

More detailed issue on communication path will be given later.

4.1.1.2 Modeling behavioral design

Recall that the CEFSM used in the design description is composed of a set of

states and transitions. Each state is converted to a label in PROMELA. Moving

to the next state is implemented in goto control transfer construct with a target

label. A transition performs a set of actions and output generation for a coming

input message. For the message exchange on a communication path, the send and

receive statements are used. A decision point with predicates is converted to the

selection construct if and each predicate is converted to a corresponding guard.

The repeated event is mapped to the repetition construct do. The source merge

is represented using if for the selection of a transition from merged transitions.

Other merge patterns are implemented with goto.

In the pattern description, the action list is usually composed of assignment

commands and arithmetic operations. The C-like PROMELA syntax supports the

actions directly. Meanwhile, the high-level abstraction action described in plain

English is commented in the PROMELA model so that the action is to be designed

in later development phases. PROMELA provides bit, bool, short, int, and

unsigned data types as well as array and typedef for array and user-defined data

types. They are usually enough for the data in a pattern.











The following code shows the finalized model of Figure 4-2.


1 #define BUFFSIZE 2 /* channel capability */
2 #define N 9 /* repetition number */
3 #define DIGIT byte
4 typedef DIGITS {DIGIT ch[9];}
5
6 chan from_caller = [BUFFSIZE] of {mtype,DIGIT};
7 chan to_lower = [BUFFSIZE] of {mtype,DIGITS};
8 mtype = {dial,conn_req};
9
10 proctype nine_digit_dial()
11 {
12 int c = 1;
13 DIGIT digit;
14 DIGITS digits;
15
16 dialing:
17 from_caller?dial(digit) ->
18 if
19 :: (c < N) ->
20 digits.ch[c-1] = digit; /* store digit */
21 c = c + 1;
22 goto dialing;
23
24 :: (c == N) ->
25 digits.ch[c-1] = digit; /* store the last digit */
26 to_lower!conn_req(digits);
27 goto connecting;
28 fi;
29 connecting: skip;
30 }

The modeling is straightforward from the pattern-based design. Currently, the

modeling is performed manually. However, it is believed that the conversion could

be performed automatically.

4.1.2 Communication Path and Channel Capacity

Channels defined by chan are used to transfer data from one process to

another. A process transfers data to other processes through message channels. For

example, chan UNI2MAIN=[8] of {mtype,int,byte} declares a channel named

UNI2MAIN that is able to store up to eight messages consisting of mtype, int, and

byte fields.









The channel capacity is one of the important issues in modeling. Communi-

cation via a channel is either synchronous (i.e., rendezvous) or asynchronous (i.e.,

buffered) depending on the channel capacity. When we specify a communication

path in design phase, we did not care about the size of message queue. We as-

sumed that it has an unlimited size. In a PROMELA model, however, a channel can

store a finite number of messages. Furthermore, increasing the channel capacity

could increase the state space dramatically. Table 4-1 shows the memory and CPU

usages for the different buffer size of the PROMELA model described in Chapter 5.1.

Note that the memory (1024M) reaches its limit at the small change of channel

Table 4-1: Effect of channel capability on memory and CPU for ABP

channel size 0 1 2 3 4
state vector (byte) 80 80 104 120 144
depth reached 345 8422 172580 1373142 4657542 (stopped)
states stored 54 24311 397351 2.89692e+06 5.75892e+06 (stopped)
total memory (M) 2.542 4.488 47.756 597.439 over the limit (1024 M)
real time (sec) 0.0 1.8 46.5 7:59.3 17:36.5 (stopped)


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

PROMELA.


timer declaration: bool T = false;
set(v,T): T = true;
reset(T): T = false;
timer expiration: (T == true)

As an example the timer model, let us consider a communication between

two communicating entities. A sending entity transfers a message (DATA) to

a receiving entity and waits for an acknowledgment (ACK) from it through the

channel comm. The sender has a timer ACKTimer for the ACK 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 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.


/** 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







73

: comm!ACK; /* reply with ACK */
: skip -> comm!ACKLoss; /* indicate the message loss */
fi;

4.1.4 Environment Process

A model to be validated with SPIN should be a closed system. As a result, we

have to provide any missing parts of a whole system as well as the validation model

itself [56]. If we have already developed these parts, this would provide a complete

set for validation. Otherwise, we have to build them. Frequently, the abstracted

environment is much difficult than the model because it is not well-designed and

a developer may not have enough information for the environment. Moreover,

it is necessary to identify whether an error has occurred in the model or in the

environment. In our case, we extract the expected behavior of the environment

processes from the design specification to make the model. The following presents

one possible scenario of the environment process for the example of nine-digit dial

described in Figure 4-2.


1 proctype ENV ()
2 {
3 byte count;
4 count = 1;
5 DIGITS callee_num;
6
7 do
8 :: (count < N) -> from_caller!dial(count);
9 count = count + 1
10 :: (count == N) -> from_caller!dial(count);
11 to_lower?connreq(calleenum);
12 break
13 od;
14 }

4.2 Property Specification

After SPIN has checked obvious initial design flaws such as system deadlocks

and unreachable code and these problems have been corrected, the system model

is verified against system requirements [44] specified using temporal logic. One

important issue in this stage is to identify requirements or properties to be verified.

If such requirements specification is not clear or does not exist, it is difficult or

impossible to determine the properties to be checked. Thus, the identification of









the desired behavior is an important issue in the system model [48]. As a high-level

design document, the system design description represented in STD helps to find

correctness properties in a system. The visual specification makes it easier for a

developer to determine the intended events and relationship among them. In this

section, we propose a property specification technique from behavioral patterns.

4.2.1 Linear Temporal Logic

Temporal logic [37] is a logic for statements and reasoning that involve the

notion of order in time. It is a useful formalism to specify properties of reactive

and concurrent systems and provides a formal and succinct notation for desired

system behavior over time. We use LTL formulae in SPIN to express properties of a

model.

A linear temporal formula is constructed from propositions to which we apply

temporal and boolean operations [77]. Every proposition p, a statement that has

either true or false boolean value, is an LTL formula. For example, DATA was sent

by a client is a true proposition if a client sent the message DATA sometime before.

Otherwise, it has false value. If the propositions p and q are temporal formulae,

then so are -p, p V p, p A p, p -- q for logical connectives negation, disjunction,

conjunction, and implication. In addition to the boolean operators, an LTL formula

contains temporal operators O(always), 0(. ', ,ft,,i,ll), U(until), and W(weak until).

A PROMELA model is considered to be a state transition system. LTL

formulae are used to formally state properties concerned with the executions of

the model. For instance,

D(DATA -* O(ACK))

means that whenever the event DATA has occurred, the event ACK has to follow it

eventually. A model checking tool can automatically validate that the property is

satisfied with a system.









It is worth noting that some experience is required to write temporal logic

statements, which is one of the obstacles to the more widespread usage of model

checking techniques [7]. Dwyer and his colleagues [78, 79] introduced a pattern

system for property specification for finite-state validation. The pattern system

describes commonly occurring properties in a finite-state system. Patterns are

largely classified for the occurrence and order of states and events. They include

absence, universality, existence, bounded existence, precedence, response, chain

precedence, and chain response. By using the patterns, it is possible for developers

to express properties more easily. It expedites the developers learning and writing

more expressive specification.

4.2.2 Property Extraction from Communication Patterns

One important issue in the validation is to identify the requirements or the

properties of a designed system. If such properties are not provided properly,

it is not possible to determine whether the system meets the required behavior.

As a high-level design document, the system design description provides the

requirements of a system. They are particularly useful to identify the existence of

an event and order of events. Each pattern has a property specification section to

describe the properties required by the pattern.

Meanwhile, we need a method to check an event occurrence such as the

message transfer and reception in the SPIN validation. For this purpose, we

associate an event occurrence with a control location that comes immediately after

the event occurrence statement [47]. A label is used to identify a control location in

a process declaration. By checking the reachability of the label, we know that the

event has really happened.

For example, to see the reception of a message ACK in a sending process, we

introduce a label ACK_rcv after the reception statement:









comm?ACK ->

ACK_rcv: skip; /* instrument a control label */



Note that a label in a PROMELA model always prefixes a statement and thereby

uniquely identifies a control state corresponding to the labeled statement [41].

Then, remote reference in an LTL formula is used to see the arrival of the

process control at the control label. The remote reference makes it possible

to determine the current state of an active process from an LTL formula. The

remote reference operator takes three arguments: the first is the name of a pro-

cess, the second is an instantiation number of an executing process of that type,

and the third argument is the name of a label that is defined within the pro-

cess. The operator returns a non-zero value if and only if the process referred

to is currently in the state marked by the label. For instance, suppose a vari-

able s_pid has an instance number of the sending process. Then, the reference

sender [s_pid]@ACK_rcv evaluates to true when the process instance is at the state

referred by the label ACK_rcv. Using the remote reference, we can check that the

input event ACK has eventually occurred.















CHAPTER 5
CASE STUDIES

5.1 Case Study: Alternate Bit Protocol

To show the practical usage of pattern-based development, we have performed

several case studies. As a simple one, we demonstrate a variation of alternating bit

protocol (ABP) [44, 73] which provides a simple but reliable message transfer on a

lossy lower layer. The following is the requirements specification of the protocol: A

sending entity transmits a DATA to a receiving entity. When the receiving entity

takes the DATA from the sending entity, it replies with an ACK so that the sender

is able to transfer the next DATA. Thus, each DATA should be acknowledged

before the next one is sent. The lower layer could randomly lose messages but not

corrupt the content and order of them.

5.1.1 Structural Design

The pattern split protocol layer looks suitable for the architecture of ABP. In

adapting the pattern, it is worth noting that it is not clear from the requirements

whether the ABP layer has an upper layer, which is an optional block of the

pattern, or not. If an upper layer exists, the upper layer would initiate a DATA

transfer. Otherwise, the ABP layer is the uppermost layer and internally generates

and consumes the DATA. For this example, we suppose that there is a user layer

of ABP that uses the messages PUT and GET to initiate and consume the DATA.

Figure 5-1 illustrates the architecture of the protocol. For the validation of

protocol, it is necessary to get an outline of PROMELA model from the structural

pattern. Since the model has to be a closed system, we need the environment

processes for the upper and lower layers.











upper layer

UP2SND RCV2UP

sender receiver

SND2LO L02SND RCV2LO L02RCV

lower layer


messages= PUT (d), GET (d),
DATA req (d), DATA ind (d),
ACK req, ACK ind;

paths = UP2SND : PUT;
RCV2UP: GET;
SND2LO: DATA req;
LO2RCV: DATA ind;
RCV2LO ACK req;
LO2SND: ACK ind;


Figure 5-1: Structure of ABP using split protocol layer

5.1.2 Behavioral Design

In this section, we describe the execution of the blocks presented at the

structural design. Note that this section illustrates the process of using SPIN step

by step.

The confirmation for a DATA transfer in the ABP layer makes the blocks

sender and receiver to be described in the patterns confirmed sender and confirmed

receiver. One immediate problem that one can meet from the design is that the

sender can wait for an ACK forever if a message is lost at the lower layer. To

avoid the unbounded waiting, a timer is added to the sender so that it can be

implemented in the pattern timed confirmed sender. Figure 5-2 presents the initial

behavior of the protocol. From the patterns, we can construct the behavior part



wait data


PUT(d)/set(v,T)/ ACK ind/ ready
DATA req(d) reset(T)/-

wait ack

T/set(v,T)/ DATA ind(d)/-/ACK req,GET(d)
DATA req(d)
sender receiver


Figure 5-2: Initial description of ABP behavior

of PROMELA model and capture several correctness requirements to be checked for

the protocol. The following is the list of the properties:

Property 1 The event PUT has to be received eventually and DATA_req follows it.









LTL: (Op A D(p -- Oq)) where p and q represent the reception of PUT and

transfer of DATA_req.

Property 2 The request DATA_req is always followed by either reception of

ACKind or timeout T.

LTL: D(p -- O((q A -r) V (-q A r))) where p, q, and r denote the transfer of

DATA_req, reception of ACK_ind, and timeout of timer T, respectively.

Property 3 Reception of DATA_ind has to occur eventually.

LTL: Op where p means the reception of DATA_ind.

Property 4 If the DATA_ind is received, the indication is always followed by

sending of ACK_req and GET.

LTL: D(p O(q A Or)) where p, q, and r represent the reception of DATA_ind,

transfer of ACK_req and GET, respectively.

Property 5 As a combination of the sender and receiver, the input message PUT is

followed by the output message GET.

LTL: D(p -- Oq) where p and q represent the transfer of PUT and reception of

GET.

Property 6 The messages PUT and GET must occur alternatively.

LTL: D(0 < (n, ng) < 1) where rn, and ng denote the numbers of

occurrences of PUT and GET.

From the PROMELA model and the properties mentioned above, we can perform

the validation of the initial design.

During the validation, there is one problem at the receiver when the model is

checked with Property 3, or the existence of DATAind. SPIN generates an error

trace which shows that the DATA_req sent from the sender is lost at the lower layer

repeatedly without any progress. As a solution for this problem, we can limit the

number of trials of message DATAreq by replacing the pattern timed confirmed

sender with the pattern timed retrial confirmed sender. Thus, when the DATA is









lost more than N times consecutively, the sender gives up the communication. As

a result, we have an updated Property 3 saying that reception of DATA_ind has

to occur eventually. Otherwise, the sender gives up the communication after the

N times timeout. Property 2 is also changed that the request DATA_req is always

followed by either reception of ACK_ind or N times timeout.

Another problem occurs at the receiver when we check the correspondence

of PUT and GET as in Property 6. Because of the possibility of ACK loss at the

lower layer, the receiver could take a duplicated DATA. The receiver, therefore, has

to check the duplication of received DATA and ignore a duplicated one although it

replies the ACK again. The checking can be achieved by appending one sequential

bit called alternate bit to the DATA and inspecting the bit. The behavior is

specified by predicates to examine the alternate bit after receiving a DATA.

After modifying the model and properties for the problems, we can validate

it again. In this time, the updated model passes all properties at the synchronous

communication. Nevertheless, one more problem still remains when the layer

uses asynchronous communication, i.e., BUFFSIZE is greater than zero. If sender

receives a timeout signal for a DATA, it assumes that either a previous DATA

or an ACK for the DATA is lost at the lower channel. Thus, it sends the DATA

again. But, this assumption is not always true because there is a possibility of

message delay. Suppose the sender had transferred a DATA with setting the

alternate bit zero. Then, it transferred the DATA again after it received a timeout

signal. Next, the sender received an ACK for the first DATA which had been

delayed. Since it received the ACK, the sender transmits the second DATA which

happens to be lost at the lower channel. Meanwhile, the receiver sends another

ACK for the duplicated DATA. Unfortunately, the sender considers this ACK

as an acknowledgment for the second DATA which was accidentally lost. Hence,

sender transfers third DATA in which the alternate bit has zero again. The receiver










ignores the message because the alternate bit is not what it expects. Thus, this

situation results in consecutive loss of two DATA messages. Tracing of this error is

quite long and hard to find, but SPIN makes it possible to find this kind of error.

To fix the problem, the sender has to wait for an ACK that contains the same bit

as the alternate bit being sent. If the sender receives the wanted ACK, it flips the

alternate bit and sends the next DATA. The checking for the control bit of ACK

can also be achieved by introducing predicates to inspect the bit. The updated

description of ABP behavior is shown in Figure 5-3 where d, a, e, b, c means data,

alternate bit, expected bit, control bit, and counter, respectively.



wait data

ACK ind(b)
PUT(d)/set(v,T)/ [a b]a:=!a,
DATA req(d,a) reset(T)/-
ACK ind(b) ready
wait ack [a!=bJ/set(v,T)/
D TDA T A r e q ( d a )
T[c c:-c+1/ T[c=N]/ "error"/-
DATAreq(d,a) DATA ind(d,a) DATA ind(d,a)
finished [a=e]/e:!e/ [a!=e]/-/ACK req(a)
ACK req(a),GET(d)
sender receiver

Figure 5-3: Final description of ABP behavior

Validation for the updated model shows that the design is error-free for the

correctness properties. We, therefore, can go to the next development phase.

Appendix A presents the PROMELA model of Figure 5-1 and Figure 5-3. It also

includes the properties checked at the final validation.

Meanwhile this case study shows the possibility of a new pattern construction

from the current pattern language. Actually, the ABP is a common protocol at

the communication systems. Therefore, we register the CEFSMs described in

Figure 5-3 as new patterns with the names of ABP sender and ABP receiver.










5.2 Case Study: ATM UNI Signaling Protocol

5.2.1 Protocol Overview

ATM signaling [65, 80, 81] is a connection-oriented protocol and dynamic

behavior for connection setup and release is achieved by signaling, an exchange of

control information in a communication network. It is broadly classified by two

interfaces: User-Network Interface (UNI) and Network-Node Interface (NNI). UNI

signaling specifies interactions between an ATM end system and an ATM access

switch, while NNI is used between switches within an ATM network. Our case

study is devoted to the development of UNI signaling, but the method can be

similarly used for NNI signaling. There are many standards for ATM UNI signaling

such as Q.2931 [82], Q.2971 [83], UNI 3.1 [84], and UNI 4.0 [85] from the ITU-T

and the ATM-Forum. The standards define a set of capabilities, messages, and

procedures for user connections. Stiller [86] surveyed commonalities and differences

between the standards. Our case study is based on the ITU-T's Q.2931.

Figure 5-4 depicts the ATM signaling protocol stack [81]. The stack consists of


Signaling Layer 3

SSCF
SSCOP SAAL

AAL
ATM Layer
Physical Layer

Figure 5-4: Protocol stack for signaling in ATM control plane

the signaling layer 3 or signaling protocol layer, the signaling ATM adaptation layer

(SAAL), the ATM layer, and the ]11\' -i ,1l layer. The signaling layer 3 has different

functions depending on the interface over which it is being used. The UNI signaling

protocol layer establishes, maintains, and releases user connections for incoming









and outgoing calls. Either user applications or switch functions such as routing,

call admission control and management can be located on top of the layer [65].

SAAL provides reliable transfer of signaling messages between instances of

signaling layer 3. It adapts the protocol data unit of a signaling layer to ATM

cells. The layer has several sublayers such as service specific coordination func-

tion (SSCF), service specific connection oriented protocol (SSCOP), and ATM

adaptation layer (AAL). The SAAL functions are accessed by the signaling layer

3 through AAL service access points. SSCF supplies a mapping function between

SSCOP and signaling layer 3. It simplifies the upper layer interface of SAAL with

regard to SSCOP. There are two kinds of SSCF, an SSCF at UNI [66] and an SSCF

at NNI [87], because the needs of signaling layer 3 are different at each interface.

SSCOP [88] implements a reliable transport protocol which sends signaling mes-

sages using sequence numbers, acknowledgments, and retransmissions to ensure

an error-free sequence delivery. The AAL sublayer is used by SSCOP to send and

receive AAL messages to the ATM layer. Typically, this layer is implemented in

hardware for performance reason. Both ATM layer and ]11i\- P ,I1 layer are also

implemented in hardware. The SSCOP and SSCF layers are usually in software

and are often referred to as SAAL [81].

Recall that an ATM connection has three phases: establishment, data transfer,

and release. During the establishment phase, an end system negotiates connection

characteristics with a network. The connection is cleared during the release phase

after data is exchanged. Figure 5-5 shows a typical message flow for an ATM

connection [65, 81]. To establish a connection, a calling party sends out an SETUP

message to an ATM network. The message contains lower layer parameters, called

party address, quality of service requirements, and other information needed for the

connection. The message is received at an access switch of an ATM network. After

checking the availability of resources, the switch may acknowledge the reception























Calling Party q





SETUP


CALL PROC










ALERT



CONN





CONN ACK






REL






REL COMP


--


T303



T310



----

--





---
T301



















:T308
VI-


SI Called Party







SETUP


CALL PROC




ALERT




CONN


CON ACK~









REL

RELCOMP


Figure 5-5: Message flow for connection establishment and release









of the message by responding with a CALL_PROC to indicate that the call is

proceeding well. Then the SETUP message is forwarded to a called party across

the network. Along the way, each network switch determines if it has enough

resources to serve the connection. If there is a problem within the network or at

the called party, the call is rejected by returning either a REL or a REL_COMP

message to the calling party. When the SETUP message reaches the called party,

it may answer with a CALL_PROC message to indicate that it is going to start the

processing of the connection. The called party may send an ALERT message to

imply an alerting has begun at the called party. Note that both CALL_PROC and

ALERT messages are optional, though we assume that these messages exist in our

case study. Whether to send a CALL_PROC in response to a SETUP is usually a

configuration feature of the access switch. Sending an ALERT is a feature of the

end system software [65]. When the called party is ready to connect, it sends a

CONN message to the calling party backwards through the network. The message

is answered with a CONN_ACK. At this point, a connection is established and data

can be exchanged.

To release the connection, which can be initiated by a calling party or a

called party, a REL message is sent to the other side. This message includes the

reason of release. The message is acknowledged with a REL_COMP after releasing

the resources allocated. The connection release of Figure 5-5 is initiated by the

called party. In addition to the message sequence, the protocol manages timing

constraints of messages. There are many timers such as T303, T310, T301, and

T308 for confirmed acknowledgments. Typically, if a timer expires, the call to be

connected is cleared.

It is important to note that each side of UNI provides a different function,

and thus the signaling protocol is defined separately for an ATM end system and











an ATM access switch. In this case study, we consider only the switch side of the

protocol. However, the behavior of an end system can be similarly obtained.

5.2.2 Structural Design

An ATM access switch has two distinct functions to deal with a calling party

and a called party. This separation of functionality leads the switch to be designed

in the pattern split dynamic handler as shown in Figure 5-6. The block contains

MESSAGES=
SETUP, CALL PROC, ALERT,
ORG2TERM CONN, CONN ACK, REL,
ORGCC(0,N) ( > TERM_CC(O,N) REL COMP, TERMINATE,
A, TERM20RG \ SETUP.int, ALERT.int, CONN.int,
REL.int;
L---------- -----------------
PATHS=
MAIN2ORG MAIN2TERM UNI2MAIN:SETUP;
ORG2MAIN:SETUP.int,TERMINATE;
UNI20RG IUNI2TERM MAIN2ORG:SETUP;
TERM2MAIN:TERMINATE;
MAIN2TERM:SETUP.int;
ORG2MAIN TERM2MAIN ORG2TERM:REL.int;
\ ,/ | TERM2ORG:ALERT.int,CONN.int,REL.int;
UNI20RG:CONN ACK,REL,REL COMP;
MAIN CC(1,1) UNI2TERM:CALL PROC,ALERT,CONN,
/ REL,REL COMP;
ORG2UNI:CALL PROC,ALERT,CONN,
ORG2U7NI UTN2MAIN TERM2UNI REL,REL COMP;
OG2UN UN2MAIN TM2U TERM2UNI:SETUP,CONN ACK,REL,
REL COMP;


Figure 5-6: Architecture of connection control block using split dynamic handler

three internal blocks: MAIN_CC to administrate calls, ORG_CC to handle outgoing

calls or originating calls, and TERM_CC to handle incoming calls or terminating

calls. The pattern also needs the definition of communication paths and messages

between the blocks.

A static instance MAIN_CC creates instances of ORG_CC and TERM_CC

depending on the messages received. When a calling party tries a new call,

the SETUP request comes to the MAIN_CC from the lower layer through the

path UNI2MAIN. Upon receiving the message, MAIN_CC creates an instance of

ORG_CC to handle the originating call. The signaling messages between a calling

party and the instance flows through the communication paths UNI20RG and

ORG2UNI via the lower layer of the protocol. To connect the call to a called party,

it is necessary for the instance to inform the called party of the arrival of a new










call. The internal message SETUP.int is used for this purpose. The message makes

the MAIN_CC create an instance of TERM_CC to handle the terminating call.

As mentioned earlier, this case study deals with UNI, and thus we consider only

a local call in one ATM switch. In other words, the instances of ORG_CC and

TERM_CC exist in the same switch. If there are many switches in the network

and the call flows through the switches as a long distance call, the instances would

need different protocols such as NNI. Note that ORG2TERM and TERP M'ORG

are used for the internal messages such as ALERT.int, CONN.int and REL.int.

These messages are represented in the dotted line in Figure 5-5. Note that the

difference between normal messages and internal messages. The normal messages

are transmitted through a lower layer of the signaling protocol, whereas the internal

messages are exchanged among block instances.

5.2.3 Behavioral Design

5.2.3.1 Behavior of MAIN_CC

As shown in Figure 5-6, MAIN_CC takes the role of administrator of the

pattern split dynamic handler for the messages SETUP, SETUP.int, and TER-

MINATE. It creates instances of ORG_CC and TERM_CC for the messages

SETUP and SETUP.int. After finishing communication, each instance informs the

MAIN_CC of the termination of execution using the message TERMINATE. The



main wait main wait main wait



SETUP/ SETUP.int/ TERMINATE/
"create ORG CC" "create TERM CC", "delete instance id"/
"save instance id"/ "save instanceid"/
SETUP to ORG CC SETUP.int to TERM CC
(a) (b) (c)

Figure 5-7: MAIN_CC as an administrator of split dynamic handler

behavior is given in Figure 5-7. The whole behavior of MAIN_CC is obtained by









merging the CEFSMs of Figure 5-7 through the pattern source merge at the state

mainwait.

We can extract the properties of MAIN_CC behavior from the CEFSMs.

In the case of Figure 5-7 (a), the input event SETUP has to be followed by the

transferring of SETUP to the newly created ORG_CC. Furthermore, the two

events have to occur alternatively. These properties are also applicable to the

SETUP.int. Then, TERMINATE must follow the corresponding SETUP or

SETUP.int. For example, if an ORG_CC instance was created once, it has to cease

to exist sometime later in any situations. The property could be expressed in LTE

as O(SETUP -* O(TERMINATE)).

5.2.3.2 Outgoing Call Establishment

Confirmed receiver for SETUP. The block ORG_CC handles an outgoing

call from a calling party at the access switch. When it receives a SETUP message

from a calling party, it checks the possibility of connection first. If the service is

possible in the node, the block allocates the resources needed for the connection.

Then, it acknowledges with a message CALL_PROC to the calling party to indicate

that the call is being processed properly. If the connection is failed, it replies

with a REL_COMP message to notify that the connection is not possible and

being cleared. This behavior is well-suited for the pattern confirmed receiver as

in Figure 5-8 (a) where the SETUP is confirmed with either CALL_PROC or

REL_COMP. Note that the corresponding sender of the confirmed receiver exists

at the calling party. Because the behavior of the calling party is not our concern,

we do not present it here. However, it is possible to design the behavior with the

pattern timed retrial confirmed sender similarly as the handling of SETUP at the

TERM_CC which is given in the incoming call establishment. In addition to the

communication with a calling party, ORG_CC has to inform the MAIN_CC that

there is an incoming call request so that it initiates a TERM_CC. This notification










is performed using the SETUP.int. From the pattern used in the design, we are



call
delivered
SETUP/status: CONNint/-/CONN
"check availability"/-
outcall call
call initiated proceed delivered'
-[status=NOK][/ -[status=OK]/"resource REL/"rel. rsc"/
-/REL COMP, alloc."/CALL PROC, ALERT.int/ REL COMP,
TERMINATE SETUP.int -/ALERT REL.int, CONN ACK/-/-
TERMINATE
outcall call
proceed delivered active
(a) (b) (c)


Figure 5-8: Behavior of ORG_CC for SETUP, ALERT, and CONN

able to capture the properties to be checked in validation phase. The input event

SETUP has to be followed by either CALL_PROC or REL_COMP. Moreover, other

events in the block cannot proceed SETUP because it is the first event to have

happened in the block.

Unconfirmed sender for ALERT. After handling the message SETUP,

the block ORG_CC waits for an internal message ALERT.int from a TERM_CC

from which it knows that a called party is being alerted. Then, it transfers

the message ALERT to the calling party. This behavior can be designed in

unconfirmed sender. The corresponding calling party uses timed receiver to handle

it. Figure 5-8 (b) represents the behavior. We can extract an existence and

response property of ALERT from the pattern property section.

Confirmed sender for CONN. After the ALERT message, the called

party notifies the connection establishment using the internal message CONN.int.

For the event, ORG_CC transfers the message CONN to the calling party and

then it waits for a response from the calling party. There are two possibilities,

either CONN_ACK or REL, from the party. This behavior can be achieved using

the pattern confirmed sender, whereas the calling party uses timed confirmed

receiver to handle it. Figure 5-8 (c) shows the behavior. The detailed description