On tools supporting the use of formal description techniques in protocol development

Chanson, Samuel T.; Loureiro, A.A.F.; Vuong, Son T.

doi:10.1016/0169-7552(93)90045-6

Cited by 21 publications

(6 citation statements)

References 8 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Well-known methods are called the W [1,2], Wp [3], UIO [4], UIOv [5], DS [6], HSI [7][8][9] and the H [10,11] test derivation methods. For related surveys and tools the reader may refer to [12][13][14][15][16][17]. Moreover, in the last years an increasing research has been developed on the application of these methods to object oriented software [18].…”

Section: Introductionmentioning

confidence: 99%

“…During the past years a lot of research work has been done on developing complete FSM-based testing methods [1,3,5,8,9,15], studying the fault coverage of test suites [23,24], developing testing computer-aided tools [13,25], and using the FSM-based methods in the development of test cases from specifications modeled using other formalisms as extended FSMs (EFSMs) and labelled transition systems LTSs (related survey in [12]). Moreover, these methods have been used in order to derive tests for realistic protocols.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

FSM-based conformance testing methods: A survey annotated with experimental evaluation

Dorofeeva

El-Fakih

Maag³

et al. 2010

Information and Software Technology

136

View full text Add to dashboard Cite

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

FSM-based conformance testing methods: A survey annotated with experimental evaluation

Dorofeeva

El-Fakih

Maag³

et al. 2010

Information and Software Technology

136

View full text Add to dashboard Cite

“…One of the possible reasons for this is that protocol implementators areas usually reluctant to disclose such information.Protocol test derivation and execution requires specflc support tools. Due to space limitations, we cannot discuss these issues here; the interested reader is referred to a recent review[Chan93]. According to some data, the cost of test suite production can be reduced by at least 40% by using such tools.…”

mentioning

confidence: 99%

Protocol testing

Bochmann

Petrenko

1994

Proceedings of the 1994 International Symposium on Software Testing and Analysis - ISSTA '94

158

View full text Add to dashboard Cite

Communication protocols are the rules that govern the communication between the different components within a distributed computer system. Since protocols are implemented in software and/or hardware, the question arises whether the existing hardware and software testing methods would be adequate for the testing of communication protocols. The purpose of this paper is to explain in which way the problem of testing protocol implementations is different from the usual problem of software testing. We review the major results in the area of protocol testing and discuss in which way these methods may also be relevant in the more general context of software testing. servation and synchronization problems between the different parts of the test system. These issues have a strong impact on testability. Finally, we review the practice of protocol conformance testing and state our conclusions. 1.1. The nature of protocol testing communication protocols are the rules that govern the communication between the different components within a distributed computer system. In order to organize the complexity of these rules, they are usually partitioned into a hierarchical structure of protocol layers, as exemplified by the seven layers of the standardized 0S1 Reference Model [1S7498]. Figure 1(a) shows a communication system from the point of view of two users. The users interact with the communication service through interactions, called service primitives, exchanged at 109 so-called service access points (SAP). The definition of the behavior of the box which extends between the two users is called the service specification. It defines the local rules of interactions at a given service access point, as well as the so-called end-to-end properties which relate the interactions at the different access points and represent the communication properties, such as end-to-end connection establishment or reliable data transfer. SAP1 SAP2 communication service N communlcah + Figure 1: The architecture of a communication system.

show abstract

“…There are many LOTOS tools for verification, execution, analysis, and so on (for survey, see Ref. [5]). We have developed a testin tool for LOTOS expressions with data values [9f and proposed a technique for adding time constraints to LOTOS expressions and verifying the equivalence between two exressions with different time constraints automatically 211.…”

Section: Resultsmentioning

confidence: 99%

“…2) asynchronized parallel execution 3) synchronized parallel execution 4) successive execution a > > P 5 …”

Section: Process Description In Lotos/spdmentioning

confidence: 99%

Software process description using LOTOS and its enaction

Yasumoto¹,

Higashino²,

Taniguchi³

Proceedings of 16th International Conference on Software Engineering

View full text Add to dashboard Cite

Software processes can be treated as cooperative works among several engineers. I n order to enact a software process in a distributed environment, the engineers must communicate each other for exchanging data values and synchronization messages. Such communications should be described in a process description for enacting the process automatically and clarifying the engineers ' work. Since these communications are numerous, it is troublesome for the process designers to describe them minutely in the process description. They also make the description unreadable. I n this paper, we propose a formal software process model where we describe only a whole description of a process in which we describe only the contents and temporal orders of primitive activities, and do not spec-ZJ$ the communications. From the whole description, we derive each engineer's individual description automatically where the contents and orders of his activities and communications to others are described. A whole process is enacted by executing all individual descriptions in parallel. Both whole and individual descriptions are described in LOTOS/SPD, an extension of the formal specification language LOTOS. W e have also developed a support system for deriving the individual descriptions and executing them on UNIX machines.

show abstract

On tools supporting the use of formal description techniques in protocol development

Cited by 21 publications

References 8 publications

FSM-based conformance testing methods: A survey annotated with experimental evaluation

FSM-based conformance testing methods: A survey annotated with experimental evaluation

Protocol testing

Software process description using LOTOS and its enaction

Contact Info

Product

Resources

About