Acoel on Coral

SAVCBS 2001 Proceedings
Specification and Verification of Component-Based Systems
Workshop at OOPSLA 2001
Dimitra Giannakopoulou, Gary T. Leavens, and Murali Sitaraman (editors)
TR #01-09a
October 14, 2001, revised November 6, 2001
Keywords: Specification, verification, component-based systems.
2000 CR Categories: D.1.m [Programming Techniques] Miscellaneous — component-based
programming, reflection; D.2.1 [Software Engineering] Requirements/Specifications — languages,
methodology, theory, tools; D.2.4 [Software Engineering] Software/Program Verification — assertion
checkers, class invariants, correctness proofs, formal methods, model checking, programming by contract,
reliability, validation; D.2.5 [Software Engineering] Testing and Debugging — testing tools; D.2.11
[Software Engineering] Software Architecture — languages; D.2.m [Software Engineering] Miscellaneous
— component-based systems, reusable software; D.3.1 [Programming Languages] Formal Definitions and
Theory — semantics; D.3.3 [Programming Languages] Language Constructs and Features — data types
and structures; F.3.1 [Logics and Meaning of Programs] Specifying and verifying and reasoning about
programs — assertions, invariants, logics of programs, pre- and post-conditions, specification techniques;
F.3.m [Logics and Meaning of Programs] Miscellaneous — reasoning about performance.
Each paper’s copyright is held by its author.
Department of Computer Science
226 Atanasoff Hall
Iowa State University
Ames, Iowa 50011-1040, USA
Table of Contents
Preface ................................................................................................................................................. iii
Session I: Specification-Based Testing and Run-Time Analysis
Testing Components ............................................................................................................................. 4
Neelam Soundarajan, The Ohio State University
Benjamin Tyler, The Ohio State University
Spying on Components: A Runtime Verification Technique ................................................................7
Mike Barnett, Microsoft Research
Wolfram Schulte, Microsoft Research
Toward Reflective Metadata Wrappers for Formally Specified Software Components ......................14
Stephen H. Edwards, Virginia Tech.
Session II: Architecture and Composition
Architectural Reasoning in ArchJava ..................................................................................................22
Jonathan Aldrich, University of Washington
Craig Chambers, University of Washington
Using Message Sequence Charts for Component-based Formal Verification .....................................32
Bernd Finkbeiner, Stanford University
Ingolf Krüger, Technical University of Munich
Session III: Keynote
The Outer Limits of the Specification Universe: On to the Fourth Quadrant
Clemens Szyperski, Microsoft Research
Session IV: Compositional Verification
Reasoning about Composition: A Predicate Transformer Approach ...................................................42
Michel Charpentier, University of New Hampshire
Specification and Verification with References ...................................................................................50
Bruce W. Weide, The Ohio State University
Wayne Heym, The Ohio State University
Modular Verification of Performance Correctness ..............................................................................60
Joan Krone, Denison University
William F. Ogden, The Ohio State University
Murali Sitaraman, Clemson University
Session V: Discussion
i
Other Accepted Papers
On Contract Monitoring for the Verification of Component-Based Systems ...............................68
Philippe Collet, Université de Nice - Sophia Antipolis
A Framework for Formal Component-Based Software Architecting ...........................................73
M.R.V. Chaudron, Technische Universiteit Eindhoven
E.M. Eskenazi, Technische Universiteit Eindhoven
A.V. Fioukov, Technische Universiteit Eindhoven
D.K. Hammer, Technische Universiteit Eindhoven
Type Handling in a Fully Integrated Programming and Specification Language .........................81
Gregory Kulczycki, Clemson University
A Formal Approach to Software Component Specification .........................................................88
Kung-Kiu Lau, University of Manchester
Mario Ornaghi, Università degli studi di Milano
A Pi-Calculus based Framework for the Composition and Replacement of Components ...........97
Claus Pahl, Dublin City University
Analysis of Component-Based Systems - An Automated Theorem Proving Approach ............107
Murali Rangarajan, Honeywell Technology Center
Perry Alexander, The University of Kansas
A Component Oriented Notation for Behavioral Specification and Validation .........................115
Isabelle Ryl, Université des Sciences et Technologies de Lille
Mireille Clerbout, Université des Sciences et Technologies de Lille
Arnaud Bailly, Université des Sciences et Technologies de Lille
ACOEL on CORAL: A COmponent Requirement and Abstraction Language .........................125
Vugranam C. Sreedhar, IBM TJ Watson Research Center
Non-Functional Requirements in a Component Model for Embedded Systems .......................132
Roel Wuyts, Universität Bern
Stéphanie Ducasse, Universität Bern
ii
Preface
The goal of this workshop was to explore how formal (i.e., mathematical) techniques can be or should be
used to establish a suitable foundation for specification and verification of component-based systems.
Component-based systems are a growing concern for the object-oriented community. Specification and
reasoning techniques are urgently needed to permit composition of systems from components, for which
source code is unavailable.
We wanted to bring together researchers and practitioners in the areas of component-based software and
formal methods, to address the specification and verification problems. Several representatives from
Microsoft research attended the workshop, and presented their approach to specification and verification in
the context of Microsoft products. However, it was generally agreed that a lot remains to be done to address
the needs of industry. On the other hand, papers on testing, run-time checking of assertions, and the use of
message sequence charts addressed more practical concerns. Another goal was to focus more of the effort
in formal methods on component-based systems; time will tell if we have contributed to realizing this goal.
The main expected result of the meeting would be an outline of collaborative research topics and a list of
areas for further exploration. Some of these ideas were presented in our OOPSLA poster.
The papers at the workshop and those included in the proceedings were selected from papers submitted by
researchers worldwide. Due to time limitations at the workshop, only a few papers could be presented
The discussion at the workshop itself was quite interesting. All agreed that compositional, modular
reasoning is a necessary goal in this area. We discussed several strategies for making reasoning more
tractable, including proving less, checking parts of a proof at run-time (as in run-time assertion checking),
decomposing proofs by using stronger specifications, and writing components in ways that make proofs
easier (e.g., by limiting the use of pointers). We also discussed ways to add value to specifications, including
providing support for testing and run-time assertion checking. Barnett and Schulte pointed out that in one
case at Microsoft, a specification was “orders of magnitude” smaller than the code it specified. We discussed
ways to extend type systems, to incorporate architectural constraints and message sequence information.
Several of the techniques discussed focused on component interaction at interface boundaries, which is
helpful in reasoning about compositions.
We also identified several areas that seem ripe for future work. One is putting together trace-based
concurrency reasoning with reasoning about data values. Another is how to reason about performance (i.e.,
time and space behavior); one paper at the workshop discussed this, but there is more to be done, and this
kind of reasoning is important for embedded systems. Another area is how to make reasoning easier. One
direction for making reasoning easier is finding limits on programs that have a big impact on ease of
reasoning. There was a lot of discussion of the idea of Weide and Heym to encapsulate references (pointers)
in components, so that all variables in a program are not general references. We also talked about finding
the right abstractions for reasoning about compositions. And we discussed extending type systems to
incorporate more specification information, while still allowing them to be decidable and efficiently
checkable.
The workshop was organized by Dimitra Giannakopoulou (NASA Ames/RIACS), Gary T. Leavens (Iowa
State University), and Murali Sitaraman (Clemson University). The program committee that selected papers
consisted of the organizers and Betty H. C. Cheng (Michigan State University), Steve Edwards (Virginia
Tech), K. Rustan M. Leino (Compaq Systems Research Center), and Markus Lumpe (Iowa State
University). We thank the organizers of OOPSLA 2001 for hosting the workshop.
iii
Testing Components
Neelam Soundarajan and Benjamin Tyler
Computer and Information Science
Ohio State University, Columbus, OH 43210
e-mail: {neelam,tyler}@cis.ohio-state.edu
Abstract
Our goal is to investigate specification-based approaches to
testing OO components. That is, given a class C and its
specification, how do we test C to see if it meets its specification? Two important requirements that we impose on
the testing approach are that it must not require access to
the source code of the class under test; and that it should
enable us to deal incrementally with derived classes, including derived classes that exploit polymorphism to extend the
behavior of the base class. In this paper, we report on our
work towards developing such a testing approach.
1.
INTRODUCTION
Our goal is to investigate specification-based approaches
to testing OO components. Suppose we are given an implementation of a class C and the specifications of its methods
in the form of pre- and post-conditions (and possibly a class
invariant). How do we test the implementation of C to see if
it meets its specifications? We are not specifically interested
in the question of how to choose a broad enough range of
test cases [12] although that would, of course, have to be an
important part of a complete testing methodology for OO
systems. Rather, we want to develop a general approach
that can be used to test that C meets its specifications.
Once we do this, we should be able to combine it with an
appropriate methodology for choosing test cases.
We impose two important requirements on the testing approach. First, as far as possible it must not require access
to the source code of the class under test. This is important
if we are to be able to test not just components we designed and implemented but components that we may have
purchased from a software vendor. Second, the testing approach should enable us to deal incrementally with derived
classes, including derived classes that exploit polymorphism
to extend the behavior of the base class. Much of the power
of the OO approach derives from the ability to develop systems incrementally, using inheritance to implement derived
classes that extend the behavior of their base classes. To
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
OOPSLA 2001 Workshop on Specification and Verification of Component
Based Systems Oct. 2001 Tampa, FL, USA
Copyright 2001 N. Soundarajan and B. Tyler.
1
best exploit this incremental nature of OO, our approach
to reasoning about and testing the behavior of such classes
should also be correspondingly incremental. In this paper,
we report on our work towards developing such a testing
approach.
In the next section, we provide a more detailed statement
of the problem. In Section 3, we outline how the behavior of
derived classes that use polymorphism to enrich base class
behavior may be established in a verification system. In
Section 4 we show how our testing approach can work with
the kind of specifications used in the verification system.
In Section 5, we briefly consider some problems related to
testing classes that have components that may themselves
exploit polymorphism.
2.
BACKGROUND AND MOTIVATION
An important tenet of the OO approach is abstraction.
Thus a client of a class should have an abstract view of the
class, rather than thinking in terms of the concrete structure, i.e., the member variables, of the class. Correspondingly, the specification of a class C usually consists of preand post-conditions of the methods of C, in terms of an
abstract or conceptual model of C. But abstraction causes
an important difficulty [2] for specification-based testing1 .
When testing, we have to analyze how the values of the
member variables of the class change as various member operations are invoked, so we have the problem of matching
these values to the abstract specification. Inheritance exacerbates the problem since the set of variables and operations
in the derived class is a complex mix of items defined in the
base and derived classes.
Given this, in our approach to testing, we work with concrete specifications for the classes. This is not to suggest
that abstract specifications are not important. It is just
that when considering and testing the behavior of the implementation of C, the concrete state of the class has to
play an important role since that is what the implementation works with. Similarly, when considering the behavior
of the derived class, we (the designer of the derived class as
well as the tester) must keep in mind the concrete state of
both the base and derived classes. When dealing with the
behavior of some client code cc that uses C, we should of
course not think in terms of the concrete state of C; later
in the paper, we will see how abstract specifications (of C)
enter the picture when considering testing of cc.
1
In this paper, by ‘component’, we will generally mean
‘class’ as in a typical OO language.
literature [6], we will call such methods template methods,
the methods they invoke that may be redefined in D being
called hook methods. Let t() be a template method of C,
and h() a hook method that t() invokes. As we just noted,
redefining h() in the derived class enriches also the behavior of t(). When reasoning about t() in the base class, we
would have appealed to the base class specification of h() to
account for the effects of the calls that t() makes to h(). In
order to be sure that the conclusions we have reached about
the behavior of t() apply also to its behavior in the derived
class despite the redefinition of h(), we have to require that
the redefined h() satisfies its base class specification; this
requirement is the essence of behavioral subtyping [10, 4].
But ensuring that t() continues to behave in a way that is
consistent with it its base class specification is only part of
our concern. The reason that we redefined h() in the derived
class was to thereby enrich (as we will see even in the simple
example later in the paper) the behavior of t(). Therefore we
need to be able to reason incrementally about this enriched
behavior and, more to the point of this paper, we need to
be able to test the enriched behavior that t() exhibits (or is
expected to exhibit) in the derived class as a result of the
redefinition of h().
First let us consider how the behavior of t() may be specified in the base class so that we can reason incrementally
about it in the derived class. The approach used in [3, 15]
to specify the behavior of t() in the base class is to include
suitable information, in its specification, about the sequence
of hook method calls t() makes during its execution. This
information is in the form of conditions on the value of the
trace variable τ associated with t() that records information
about these calls. This information can then be used [15]
to arrive at the richer behavior to t() in the derived class3
by combining it with the derived class specification of h().
In this paper we will see how we can test the implementation of C and D, in particular the code of t() (and h()), to
check whether it satisfies this richer specification about its
behavior.
This is a challenging task because we need to keep track of
the value of τ . Every time t() makes a call to h() (or another
hook method), τ has to be updated to record information
about this call (and return) but, of course, there is nothing in
the code of t() to do so. After all, τ is a variable introduced
by us in order to help reason about the behavior of t(),
not something included by the designer of C. One possible
solution to this problem would be to modify the code of
t() to include suitable (assignment) statements, immediately
before and after each hook method call, that would update
τ appropriately. But this would violate our requirement
that we not assume access to the body of C, and certainly
not modify it. As we will see, it turns out that we can, in
fact, exploit polymorphism in the same way that template
methods do, to address this problem.
The concrete specification of C characterizes the behavior
of each method of C in terms of pre- and post-conditions
that are assertions on the member variables of C. The specification may also include an invariant, although for simplicity we will usually ignore it in our discussion. Our goal is to
create a testing class TC corresponding to C that will allow
us to test the class C against this concrete specification. We
note that the word ‘testing’ in the title of the paper may be
considered a verb since we are interested in testing the behavior of C; it may also be considered an adjective since our
approach to testing is to construct the testing component
TC.
In [16], we had suggested the following simple approach to
the construction of TC: For each method m() of C, include
a corresponding test method test m() in TC that will invoke
m(). To do this we need an instance object, call it tc, of type
C. More precisely tc is a member variable of TC of type C,
and its value will be (a reference to) an object of type C.
Let us assume that the constructor of TC has initialized tc
to such a value. We can now write test m() to simply consist
of a call to m() followed by an assert statement in which we
require that the post-condition post.m is satisfied. Now m()
is required to work, that is ensure that its post-condition is
satisfied when it finishes, only if its pre-condition was satisfied at the time of the call to it. Thus a natural definition
of the body of test m() is:
if ( pre.m ) { tc.m(); assert( post.m ); }
Since the object here is tc, references to a variable x of C
in pre.m, post.m should be replaced by to tc.x. Are these
references legal? Member variables are typically protected,
and accessible only within C (and derived classes). In Java
[1], we could put TC in the same package with C and give
data members package scope. It is not clear how to address
this in other languages; we had suggested in [16] that it
may be useful to introduce the privileged notion of test class
into the language, with the methods of the test class being
given access to the members of the class2 . Another point
is that post.m may contain references to the value of tc.x
at the time of the call. So we need to save this value in,
say, xold, and replace (in post.m) x@pre by xold; in general,
we need to use a cloning operation [11] for this purpose.
Yet another issue has to do with the form of the assertions.
Given that we want the assertions to be machine checkable,
they have to have a somewhat restricted form [5, 8]. One
possibility [11] would be to require that the assertions be
legal boolean expressions allowed by the language. Here we
will just assume that simple assertions, including quantifiers
over finite domains, are allowed.
In this paper, we want to focus on a different issue. Suppose again that D is a derived class of C. Some methods
may be defined (or redefined) in D while others may be
inherited from C. Most importantly, even some of the inherited methods may exhibit behavior that is different from
their behavior in the base class because of calls to methods that are redefined in D. Following the design patterns
3
Ruby and Leavens [14] (see also earlier work by Kiczales
and Lamping [7, 9]) present a formalism where some additional information about a method beyond its functional
behavior is provided; this may include, for example, information about the variables the given method accesses, the
hook methods it invokes, etc. While this is not as complete
as the information we can provide using traces, it has the
important advantage that it is relatively easy to build tools
that can exploit this information, or indeed even mechanically extract this type of information from the code, rather
than having to be specified by the designer.
2
In C++, we could simply declare TC a friend of C but,
as is widely recognized, the friend mechanism is subject to
serious abuse.
It is also worth noting that if the state of tc is such that
pre.m is not satisfied, the body of test m() would be entirely
skipped; this may be considered a truly extreme instance of
poor test-case-choice!
2
3.
INCREMENTAL REASONING
drawal. Thus doAutos() iterates through the elements of
this array, invoking deposit() if the element in question is
positive and withdraw() if it is negative. addAuto() allows
us to add another transaction to the autos[] array. We will
leave the precise specification of addAuto() to the interested
reader; its pre-condition would require the parameter value
to be not equal to 0, the post-condition would say that autos[] array is updated to include this value at the end of the
array (and nautos is incremented by 1).
Let us now consider the specification of doAutos(). An
obvious specification for this method would be:
Let us consider a simple example consisting of a bank account class as the base class (and a derived class we will
define shortly). The definition (in Java-like syntax) of the
Account class appears in Figure 1. The member variable bal
class Account {
protected int bal; // current balance
protected int nautos; // no. of ‘automatic’ transactions
protected int autos[]; // array of automatic transactions
public Account() { bal = 0; nautos = 0 ; }
public int getBalance() { return bal; }
public void deposit(int a) { bal += a; }
public void withdraw(int a) { bal −= a; }
public final void addAuto(int a) {
autos[nautos] = a; nautos++; }
public final void doAutos( ) {
for (int i=0; i < nautos; i++) {
if (autos[i] > 0) { deposit(autos[i]); }
else { withdraw(autos[i]); } } }
pre.Account.doAutos() ≡ true
post.Account.doAutos() ≡
[ !{nautos, autos} ∧
(bal = #bal+(Σ(k = 0 . . . nautos − 1). autos[k]) ] (2)
This specifies that doAutos() updates bal appropriately.
What is missing is information about the hook method calls
that it makes during execution. As a result, although (2) is
correct in what it specifies, it proves inadequate in allowing
us to reason about the enriched behavior that this method
will exhibit in the derived class, to which we turn next.
}
Figure 1: Base class Account
class NIAccount extends Account {
protected int tCount; // transaction count
maintains the current balance in the account. The methods deposit(), withdraw(), and getBal() are defined in the
expected manner. Their concrete specifications4 are easily
given:
public NIAccount() { tCount := 0; }
public void deposit(int a) { bal += a; tCount++; }
public void withdraw(int a) { bal −= a; tCount++; }
public int getTC() { return tCount; }
pre.Account.getBalance()
≡ true
post.Account.getBalance() ≡
[ !{nautos, autos, bal} ∧ (result = bal) ]
}
Figure 2: Derived class NIAccount
pre.Account.deposit(a)
≡ (a > 0)
post.Account.deposit(a)
≡
[ !{nautos, autos, a} ∧ (bal = #bal+a) ]
pre.Account.withdraw(a)
≡ (a > 0)
post.Account.withdraw(a)
≡
[ !{nautos, autos, a} ∧ (bal = #bal−a) ]
The enrichment provided by NIAccount (for ‘New and
Improved account’ !) is fairly simple: it keeps a count of
the number of transactions (deposits and withdrawals) performed on the account. This is achieved by redefining deposit() and withdraw() appropriately5 . The newly defined
method, getTC() allows us to find the value of the transaction count. The specifications of these methods are straightforward modifications of (1). We will only write down the
specs for getTC() and deposit():
(1)
In the post-conditions we use the notation “!S” to denote
that the value of each of the variables that appears in the set
S is the same as it was at the start of the method in question.
The “#”notation, also in the post-condition, is used to refer
to the value of the variable at the start of the execution of
the method. Thus these specifications simply tell us that deposit() and withdraw() update the value of bal appropriately
and leave the other variables unchanged; and getBalance()
returns the balance in the account and leaves all variables
unchanged. The notation result [11] in the post-condition
refers to the value returned by the function in question.
More interesting are the ‘automatic transactions’. The
autos[] array maintains the current set of automatic transactions, nautos being a count of the number of these transactions. doAutos() is the (only) template method of this
class. Whenever it is invoked, it performs each of the transactions in the autos[] array by invoking the hook methods
deposit() and withdraw(). A positive value for an array element denotes a deposit, a negative value denotes a with-
pre.NIAccount.getTC()
≡ true
post.NIAccount.getTC()
≡
[ !{nautos, autos, bal, tCount} ∧ (result = tCount) ]
pre.NIAccount.deposit(a) ≡ (a > 0)
post.NIAccount.deposit(a) ≡
[ !{nautos, autos, a} ∧ (bal = #bal+a)
∧ (tCount = #tCount+1) ]
(3)
Let us now turn to the behavior of doAutos() in the NIAccount class. It is clear from the body of this template
method, as defined in the base class, that during its execution, the value of tCount will be incremented by the number of transactions in the autos[] array, i.e., by the value
of nautos, since doAutos() carries out each of these transactions by invoking deposit() or withdraw(). But we cannot
arrive at this conclusion from its specification (2), not even
given the specification (3) for the behavior of the redefined
4
This class is so simple that its abstract specification would
essentially be the same as its concrete specification. Note
also that we have included the name of the class in the specs
since we will also consider the behavior of these methods in
the derived class. Thus, (1) specifies the behavior of these
methods when applied to an instance of the Account class.
5
If these methods were at all complex, it would have been
appropriate to invoke the base class methods in their definitions; here, the only task to be performed by the base class
portion is to update bal, so we have just repeated the code.
3
class TAccount {
protected Account tAccount; // test object
Random rg;
public void t deposit( ) {
int rd = rg.nextInt(); int oldbal = tAccount.bal; . . .
if( rd > 0 ) { tAccount.deposit(rd);
assert( (tAccount.bal = oldbal+rd) ∧ . . . ); }
}
Figure 3: Test class TAccount
hook methods that doAutos() invokes. The problem is that
there is nothing in (2) that in fact tells us that doAutos()
invokes deposit() or withdraw(). Indeed, if we rewrote the
body of doAutos() so that it directly added each element of
the autos[] array to bal, instead of invoking deposit() and
withdraw() to perform the transactions, it would still satisfy
the specification (2) but, of course, this rewritten method,
in the NIAccount class (i.e., when applied to a NIAccount
object) would not change the value of tCount.
Consider the following more informative specification:
pre.Account.doAutos( ) ≡ (τ = ε)
post.Account.doAutos() ≡
[ !{nautos, autos} ∧(|τ | = nautos)
∧ (bal = #bal + (Σ(k = 0 . . . nautos − 1). autos[k]))
∧ (∀k : (1 ≤ k ≤ |τ |) :
τ [k].m ∈ {deposit, withdraw}) ]
(4)
need the save the starting values of the data members of
tAccount since the post-condition refers to these values. We
have shown only one of these in the figure, oldbal being the
variable in which the starting balance in tAccount is saved.
Of course, when the data member in question is more complex, such as the array autos[], this becomes somewhat more
involved; and if the member is an object (of a type defined
by the user), this will require, as we noted in Section 2, that
the corresponding class provide a cloning operation.
The test methods t withdraw() and t getBal() are similarly
written, and we will omit them. Let us consider the template method doAutos(). If we were only interested in the
specification (2) which gives us information only about the
functional effect that doAutos() has on the data members of
the Account class, this too would be straightforward6 . But
a key aspect of the behavior of doAutos(), indeed the aspect
that qualifies it as a template method and makes it possible
to define derived classes that enrich its behavior by simply
redefining deposit() and/or withdraw(), is of course the calls
it makes to these hook methods. Thus if we are to really test
the implementation of doAutos() against its expected behavior, the testing must be against the trace-based specification
(4).
However, we face an important difficulty in doing this.
The problem is that the trace variable τ which plays a key
role in this specification is not an actual member variable
of the Account class. We could, of course, introduce such
a variable in the test class TAccount but this won’t serve
our purpose. The problem is that τ has to record appropriate information about the hook method calls that doAutos()
makes during its execution; this cannot be done in the test
method t doAutos() before it calls doAutos() or after doAutos() returns. In other words, what we need to do is to ‘track’
doAutos() as it executes; whenever it it gets ready to make a
hook method call, we have to ‘intervene’, record appropriate
information about the call – in particular, the name of the
method called, the parameter values, the state of the object
at the time of the call – and then let the call proceed; once
the hook method finishes execution and returns control to
doAutos(), we again need to intervene and record information about the results returned and the (current) state of
the object. One possible way to do this would be to insert
the appropriate statements to update the value of τ before
and after each hook method call in the body of doAutos();
but this would not only require access to the source code of
doAutos(), it will require us to modify that source code, and
τ denotes the trace of hook method calls that doAutos()
makes during its execution. At its start, doAutos() has
not made any hook method calls, so τ is ε, the empty sequence. Each hook method call (and corresponding return)
is recorded by appending a single element to τ . This element
consists of a number of components, including the name of
the method in question, the parameter values passed in the
call, the returned results, etc.; for full details, we refer the
reader to [15]. Here we are interested only in the identity of
the method; τ [k].m gives us the identity of the method invoked in the call recorded in the k th element of τ . Thus the
post-condition in (4) states that when doAutos() finishes, it
would have made as many hook method calls as nautos, the
number of automatic transactions in the autos[] array, and
that each of these calls will be to either deposit() or withdraw(). This specification can, using the enrichment rule of
[15], then be combined with the specification (3) to arrive
at the following:
post.NIAccount.doAutos()
≡
[ !{nautos, autos} ∧(|τ | = nautos)
∧ (bal = #bal + (Σ(k = 0 . . . nautos − 1). autos[k]))
∧ (∀k.(1 ≤ k ≤ |τ |). τ [k].m ∈ {deposit, withdraw})
∧ (tCount = #tCount + nautos) ]
(5)
This asserts, as expected, that doAutos() increments the
transaction count appropriately. Informally speaking, what
we have done here is to ‘plug-in’ the additional information
provided by the derived class specs (3) of the hook methods, into the specification (4) of the template method, to
arrive at the enriched behavior of the template method in
the derived class.
4.
TESTING POLYMORPHIC BEHAVIOR
Suppose we wanted to test the class Account to ensure that
it behaves as expected, i.e., according to its specifications.
We could use the approach outlined in Section 2 to define the
corresponding test class, TAccount shown partially in Figure 3. tAccount is the test account object. rg as an object of
type Random, to be used for generating random values (for
use as parameter values). t deposit() is the test method corresponding to deposit(). We generate a random amount rd
to deposit into tAccount, and if the pre-condition of deposit()
(as specified in (1)) is satisfied, we invoke deposit(rd) on tAccount, and then assert that the post-condition of deposit()
must be satisfied, with appropriate substitutions such as replacing bal by tAccount.bal being made. Note that we also
6
One question here would be that of generating a random
value in the tAccount.autos[] array; indeed, in general, the
test object should be in a random (reachable) state, rather
than being initialized to some ‘standard’ state; but this question is independent of inheritance and polymorphism, so we
will ignore it here.
4
being tested so that the redefined hook methods can record
the information on the correct trace variable. This is in fact
not necessary since only one template test method will be
executing at a time, and it starts by initializing tau to ε.
Of course we have assumed that we can declare tau to be of
type “trace”. If we really wanted to record all the information that tau has to contain in order to ensure completeness
of the reasoning system [15], things would be quite complex. We can simplify matters somewhat by only recording
the identities of the hook methods called and the parameter
values and results returned. This is a topic for further work.
This approach can also be used for testing abstract classes,
i.e., classes in which one or more of the hook methods may
be abstract (in Java terminology; pure virtual in C++, deferred in Eiffel). The only change we have to make is that
in T2Account.deposit(), we cannot invoke super.deposit(); instead, we would just record information in tau and return
to doAutos(). Note that the specifications (2) and (4) would
also be quite different. For one thing, we cannot really establish (2) because, if Account.deposit() (and, presumably,
Account.withdraw() as well) is abstract, there is no way to
tell what effect doAutos() will have on bal, etc. Nevertheless,
the portion of (4) that refers to the hook methods invoked
can still be specified since the basis for this can be seen
from the body of the template method, so the designer of
the Account class could have written this down as part of
the specification of doAutos(). The t doAutos() method will
then test that doAutos() does indeed satisfy the expectation
about the hook methods it will call7 .
Let us now consider the derived class NIAccount. How do
we construct the test class TNIAccount? We cannot define
it as a derived class of T2Account because then the redefinitions of the hook methods in NIAccount would not be
used by the test methods in TNIAccount. In fact, in general, test classes should be final; i.e., a given test class TC is
only intended to test that the methods of the corresponding
class C meet their specs. A different class D, even if D is
a derived class of C, would have to have its own test class
defined for it. Of course, TNIAccount would be quite similar
to T2Account. The important differences would be that we
would have test methods corresponding to any new methods
defined in NIAccount, and pre- and post-conditions would be
the ones from the specifications (such as (3) and (5)) of this
class.
Before concluding this section, we should note one other
point. An important assumption we have made is that hook
methods obey behavioral subtyping [10], i.e., any redefinitions of hook methods in the derived class must continue
to satisfy their base class specifications. If this were not
the case, the reasoning that we have performed in the base
class about the behavior of the template method, including
the trace-based specification of that method, may no longer
be valid. For example, suppose a template method t() first
calls the hook method h1(); if the value returned by h1()
is positive, t() then calls h2(), else it calls h3(). Suppose
this is clearly undesirable.
The solution turns out to be provided by polymorphism
itself. The key is to define TAccount not as a class that
includes a member variable of type Account but rather to
have TAccount as a derived class of Account. We call this
new test class T2Account in order to distinguish it from the
original test class TAccount. T2Account appears in Figure 4.
The variable tau of T2Account is the trace variable in which
class T2Account extends Account {
protected trace tau; // trace variable
public void deposit(int aa) {
// add element to tau to record info such as
// name of method called (deposit),
// parameter value (aa) etc., about this call;
super.deposit(aa);
// add info to tau about the result returned
// and current state.
}
// withdraw() will be similarly defined.
public void t doAutos( ) {
tau = ε;
// check pre-condition, then call doAutos(),
// assert post-condition.
}
}
Figure 4: Test class T2Account
we record information about the sequence of hook method
calls that doAutos() will make during its execution.
The t doAutos() method starts by initializing tau to ε,
then calls doAutos() (on the self object). Let us consider
what happens when doAutos() executes, in particular when
it invokes the deposit() method (withdraw() is, of course,
similar, so we won’t discuss it). We have redefined deposit() in T2Account, so this call in doAutos() to deposit()
will be dispatched to T2Account.deposit() since the object
that doAutos() is being applied to is of type T2Account.
Now T2Account.deposit() is simply going to delegate the call
to the Account.deposit() but before it does so, it records appropriate information, such as the name of the hook method
called (‘deposit’), the parameter value (aa), etc., about this
call on tau. Next, T2Account.deposit() calls the deposit()
defined in Account; when Account.deposit() finishes, control comes back to T2Account.deposit(); T2Account.deposit()
now records additional information (about the result returned, current state of the object, etc.), and finishes, so
control returns to Account.doAutos(). The net effect is that
the original code, Account.deposit(), of the hook method invoked has been executed but, in addition, information about
this call has been recorded on the trace. And to do this, we
did not have to modify the code of any of the methods of
Account, indeed we did not even need to be able to see that
code.
One point might be worth stressing: T2Account.deposit()
is not the test method corresponding to deposit(); rather,
it is a redefinition of the hook method Account.deposit() in
order to record information about calls that template methods might make to this hook method, the information being
recorded on the trace of the template method. If there is
more than one template method, we might consider introducing more than one trace variable, and yet another variable to keep track of which template method is currently
7
In fact, we would not only want to be assured about the
identity of the hook methods called or the number of times
they are called (which are the pieces of information provided
by (4)) but also the parameter values passed in these calls as
well as the state just before the calls, etc.; this is particularly
important if the hook method in question is abstract. This
additional information can be provided using our traces although the resulting specs are naturally much more involved
[15].
5
6.
also that the base class specification of h1() asserts that it
will return a positive value. When reasoning about the base
class, we might then establish, on the basis of this specification of h1(), a specification for t() which asserts that the
identity of the first hook method that t() calls (as recorded
in the first element of the trace τ of t()) is h1(), and the
identity of the second method called is h2(). Suppose now
we redefine h1() in the derived class so that it returns a negative value. Then, in the derived class, t() will not satisfy its
specification, and the problem is not with t() but with the
way that h1() was redefined. The redefined h1() does not
satisfy its base class specification, i.e., it violates behavioral
subtyping. Hence, when testing the behavior of the hook
methods in the derived class, it may be useful not just to
test against the derived class specification of the method,
but also against its base class specification to ensure that
the redefined hook method still satisfies that specification.
5.
REFERENCES
[1] K. Arnold, J. Gosling, and D. Holmes. Java
Programming Language, Third Edition, 2000.
[2] E. Berard. Essays on object oriented software
engineering. Prentice-Hall, 1993.
[3] M. Buchi and W. Weck. The greybox approach: when
blackbox specifications hide too much. Turku Centre
for Computer Science TR No. 297, 1999,
http://www.tucs.abo.fi/.
[4] K.K. Dhara and G.T. Leavens. Forcing behavioral
subtyping through specification inheritance. In
Proc. of 18th Int. Conf. on Softw. Eng., pages
258–267. IEEE Computer Soc., 1996.
[5] S. Edwards, G. Shakir, M. Sitaraman, B. Weide, and
J. Hollingsworth. A framework for detecting interface
violations. In Proc. of 5th Int. Conf. on Softw. Reuse.
IEEE, 1998.
[6] E. Gamma, R. Helm, R. Johnson, and J. Vlissides.
Design patterns: Elements of reusable OO software.
Addison-Wesley, 1995.
[7] G. Kiczales and J. Lamping. Issues in the design and
specification of class libraries. In OOPSLA ’92, pages
435–451, 1992.
[8] P. Krishnamurthy and P. Sivilotti. The specification
and testing of quantified progress properties in
distributed systems. In 23rd Int. Conf. of Software
Eng. ACM, 2001.
[9] J. Lamping. Typing the specialization interface. In
OOPSLA, pages 201–214, 1993.
[10] B. Liskov and J. Wing. A behavioral notion of
subtyping. ACM Trans. on Prog. Lang. and Systems,
16:1811–1841, 1994.
[11] B. Meyer. Object-Oriented Software Construction.
Prentice Hall, 1997.
[12] G. Myers. The art of software testing. John Wiley,
1979.
[13] D. Perry and G. Kaiser. Adequate testing and OO
programming. Journal of Object Oriented
Programming, 2:13–19, 1990.
[14] C. Ruby and G. Leavens. Safely creating correct
subclasses without seeing superclass code. In
OOPSLA 2000, pages 208–228. ACM, 2000.
[15] N. Soundarajan and S. Fridella. Framework-based
applications: Incremental development to incremental
reasoning. Proc. of 6th Int. Conf. on Softw. Reuse, pp.
100–116, Springer, 2000.
[16] N. Soundarajan and B. Tyler. Specification-based
incremental testing of object-oriented systems. In
TOOLS 39, pp. 35–44, IEEE CS Press, 2001.
DISCUSSION
Let us briefly consider a class C that has a member variable acc of type Account. In reasoning about the behavior of
the methods of C, we will of course depend upon the specifications of the Account class. Do we have to worry about
the specifications of the NIAccount class? Yes, indeed. The
point is that for a particular object that is an instance of
C, the acc component may well be of type NIAccount8 . In
fact, one reason for defining classes such as NIAccount is
precisely that client classes such as C can take advantage of
the enrichment provided by this class. What are the issues
that we have to consider in reasoning about and testing the
behavior of C?
One possibility would be that in reasoning about C, we
only take account of the specification of Account. And in
testing C, we only create instances of C that have an acc
component of type Account. But this is clearly insufficient.
We need to test the behavior of C for instances that have an
acc component of type NIAccount. In fact, whenever a new
derived class of a base class such as Account is defined, the
behavior of any client code of Account has to be re-tested
[13]. While this may seem undesirable, it is to be expected.
After all, by defining a new derived class of Account, we are
enriching the behaviors that a client class, such as C, of Account can exhibit; so naturally we have to test for such richer
behaviors. The techniques for reasoning about such richer
behaviors of C, as well as the corresponding techniques for
testing them, are topics for further work.
8
Of course, in languages like C++ for this to happen, acc
would have to be a pointer to Account but this is a language
detail which we can ignore.
6
Spying on Components: A Runtime Verification Technique
Mike Barnett and Wolfram Schulte
Microsoft Research
One Microsoft Way
Redmond WA, 98052-6399, USA
{mbarnett,schulte}@microsoft.com
ABSTRACT
Machines (ASMs) [16], it allows the writing of operational
specifications at any given level of abstraction. Using it, we
have built models of real-world components, like intelligent
devices, internet protocols, debuggers and network components [2, 14]. Because ASMs have a formal semantics, an
AsmL specification is itself a formal specification.
For the second problem, we use AsmL’s native COM connectivity and the COM infrastructure to dynamically monitor the execution of a component. By checking for behavioral equivalence between the component and its concurrently executing specification we ensure that, during a particular run, the component is a behavioral refinement of its
specification, i.e., a behavioral subtype [22].
There are two major issues that we do not address in this
paper: non-deterministic specifications and callbacks. Both
are crucial elements of component-based specification and
we have developed solutions for both of them, but they are
beyond the scope of this paper. Although our system is
implemented for COM components, it applies to any component technology that uses dynamic linking.
The paper is organized as follows. Section 2 gives an
overview of AsmL. Section 3 explains how to use AsmL to
write an interface specification. Then in Section 4 we explain our technique for runtime verification. In Section 5 we
describe some initial experiments we have conducted within
Microsoft. An overview of similar approaches is discussed in
Section 6; Section 7 summarizes, presents limitations, and
describes future work.
A natural way to specify component-based systems is by an
interface specification. Such a specification allows clients of
a component to know not only its syntactic properties, as is
current practice, but also its semantic properties. Any component implementation must be a behavioral refinement of
its interface specification. We propose the use of executable
specifications and a runtime monitor to check for behavioral
equivalence between a component and its specification. Furthermore, we take advantage of the COM infrastructure to
perform this kind of runtime verification without any instrumentation of the implementation, i.e., without any recompilation or re-linking.
1.
INTRODUCTION
We believe that component-based programming needs formal specifications at the interface level. Currently there are
standardized ways to formally specify the syntactic properties of a component, for example, by type libraries or IDL
files for COM components [7]. However, the proper mechanism for specifying semantic properties is still an open research topic. Clearly, clients of a component, whether they
are human or other software components, require some way
of understanding the behavior of a component. Natural language descriptions, while valuable, are often incomplete or
ambiguous and are in any case limited to human consumption.
Even if there was agreement on a particular specification
technique, there is still the problem of ensuring that a particular component does indeed implement its specification.
We propose an answer to the first problem and a technique
that partially addresses the second problem.
Our approach for specifying components is to use AsmL to
write an executable specification at the highest level of abstraction that defines the behavior of a component as seen
through its interface by a client. AsmL is an industrialstrength specification language we have developed at Microsoft Research. Based on the theory of Abstract State
2.
AsmL
We write executable specifications of components in the
Abstract State Machine Language (AsmL). The language is
based on the theory of Abstract State Machines [16]. It is
currently used within Microsoft for modeling, rapid prototyping, analyzing and checking of APIs, devices, and protocols.
The key aspects which distinguish AsmL from other related specification languages are:
• it is executable,
• it uses the ASM approach for dealing with state,
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
OOPSLA 2001 Workshop on Specification and Verification of ComponentBased Systems Oct. 2001 Tampa, FL, USA
Copyright 2001 M. Barnett and W. Schulte.
• it has a full-fledged object and component system,
• it supports writing non-deterministic specifications.
Our web site [13] contains a complete description as well
as an implementation that is freely available for noncommercial purposes.
1
7
Because AsmL has native COM connectivity (the next
release will also be integrated into the .NET framework), one
can not only specify components in AsmL and simulate them
but also substitute low-level implementations by high-level
specifications. This substition allows heterogeneous systems
to be built, partly developed using standard programming
languages and partly using executable specifications. It is
also crucial for implementing runtime verification without
the need for instrumenting the implementation.
Although not shown in this paper, non-determinism is one
of the key features of AsmL. It allows designers to clearly
mark those areas where an implementation must make a
decision. In AsmL, non-determinsm is restricted; you can
choose or quantify only over bounded sets [5].
AsmL specifications are model programs: they are operational specifications of the behavior expected of any implementation. Thus, they provide a minimal model by constraining implementations as little as possible. There are
three main properties of AsmL that support this.
interface ICanvas
createFigure(. . .) as IFigure
interface IFigure
getColor () as Color
setColor (c as Color )
getBorder () as IBorder
interface IBorder
getWidth() as Integer
setWidth(i as Integer )
Figure 1: Example Interfaces: Syntax Only
interface ICanvas
createFigure(c as Color , . . .) as IFigure =
new IFigure(c, . . .)
1. The ASM notion of step allows the specifier to choose
an arbitrary granularity of sequentiality. Within a single step, all updates (assignment statements) are evaluated in parallel; locations (variables) are written in
one atomic transaction at the end of the step. Using
the maximal step size means that no unnecessary sequencing is forced on the implementer. An implementation is free to choose an evaluation order consistent
with efficiency considerations.
interface IFigure
var color as Color
border as IBorder = new IBorder (3)
getColor () as Color = color
setColor (c as Color ) = color := c
getBorder () as IBorder = border
interface IBorder
var w as Integer
getWidth() as Integer = w
setWidth(i as Integer ) =
if i < 0 then throw Exception(. . .) else w := i
2. Non-deterministic (bounded) choice is a basic construct in the language. Although non-determinism is
undesirable in an implementation, non-deterministic
specifications allow implementations to make the correct engineering decisions. For instance, a specification
might say that any element satisfying certain conditions can be returned from a collection where the implementation might make a particular choice based on
the efficiency of searching the data structures that are
employed.
Figure 2: Example Interfaces: Semantics
The example provides interfaces for a component-oriented
drawing program: a client interacts with a root interface,
ICanvas, to create and manipulate geometric figures, which
support the interface IFigure. Each figure has a nested object, a border, which supports the interface IBorder. That is,
a component supporting the IFigure interface also must be
able to provide a reference to an IBorder interface. Whether
this reference is actually to a separate component, or just
a different interface on the same component is exactly the
kind of underspecification that component-based programming encourages.
The method createFigure returns a reference to the IFigure interface on the figure that is created. A figure’s border
is created with some default attributes; the attributes can
be changed later through calls to methods such as setWidth.
Note the syntax of the interface definitions alone allows data
values and interface references to be distinguished.
An example AsmL specification for this interface is shown
in Figure 2. It is written as a model program, as opposed
to a set of pre- and post-conditions (although AsmL does
provide also that style of specification). It is a particularly
trivial model; this is good — such a trivial component should
not have a complicated specification.
Note that the method setWidth throws an exception if the
argument is less than zero. The exception must belong to
3. High-level data structures and programming constructs allow a specification to be expressed in ways
that might not be acceptable when efficiency is the
primary concern. For instance, a specification might
not bother to normalize a data structure, but instead
re-organize and manipulate it each time it is accessed.
In general, the primary goal of a specification is to be as clear
and understandable as possible; the goal of an implementation is to meet engineering considerations such as execution
time, storage efficiency, etc.
Compared to an implementation language such as C++,
we have found AsmL specifications to be an order of magnitude more compact. While part of this is due to the advantages offered by any higher-level notation, some part is
caused by the specific features of AsmL enumerated above.
3.
INTERFACE SPECIFICATIONS
Figure 1 presents a small example that we use throughout. It is not COM-specific. Although written in AsmL, it
corresponds exactly to an interface expressed in IDL. AsmL
makes implicit the fact that COM methods also return a status value in addition to whatever other values they return;
compiler-generated code handles that automatically.
2
8
When runtime verification uncovers a difference in behavior between the specification and the implementation, there
is no a priori way to know which is “wrong” (unless one
assumes that the specification is always correct. . . ). We are
unaware of any method for creating perfect specifications;
one can only hope to use a specification language that supports a layered approach. Engineering practice has shown
the importance of separating unrelated concerns in order to
focus on the proper details at issue. We have tried to ensure
AsmL is such a language.
calls Client
C
Server
S
-
Figure 3: A client-server architecture
4.1
The Proxy P
All method calls between C and S are intercepted by P .
As far as C is concerned, it is accessing the functionality
provided by S and is unaware of either P or M . P manages
the concurrent execution of M and S ; it forks every call so
that they are delivered to M as well as S . P compares the
results from both components, checking at each interface
call that they agree in terms of their success/failure codes
as well as any return values. (In our examples, we do not
explicitly show the checks for the success or failure of the
methods.) As long as they are the same, the results are
delivered to C . Otherwise S and M are not behaviorally
equivalent; the discrepancy is made evident to an observer
of the system.
We create P automatically from the definition of the interfaces that are used between C and S . The correct operation
of P relies on two properties of object references in S that
allow them to be used as identifiers.
callsClient
C
-
Proxy
P
- Server
S
?
Model
M
Figure 4: Proxy Architecture
some interface, but we do not show it.
4. RUNTIME VERIFICATION
A component that interacts with an implementation of
ICanvas is a client, while the implementation is a server;
together their architecture is shown in Figure 3. We refer to the client program as C and the implementation of
the server as S . The important feature implied by such
an architecture is that the client is completely unaware of
the identity of the server component. C is aware solely of
the functionality provided through whatever interfaces are
supported by S . This is the crucial feature we rely on for
implementing our runtime verification.
To enable the AsmL specification to spy on the interactions between C and S , we insert a component, P , which
operates as a proxy, as shown in Figure 4. Using a proxy
allows the interaction of the client C and the server S to be
observed without having to instrument (i.e., modify) either
component. The proxy forks all of the calls made from C
to S so that they are delivered to the AsmL specification or
model, M . From now on, we use the letters C , S , M , and P
to refer to the client, server, model, and proxy, respectively.
Inserting a proxy is easily accomplished for COM components [7]. Clients can initiate access to a COM component
only by making a request to the operating system. That request can be intercepted either with or without the client’s
cooperation. As long as the value returned to the client is a
valid interface reference, the client is unable to distinguish
whether the reference is to the actual implementation, S , or
to our proxy, P . In fact, it is this property of COM that
allows transparent access to COM components that are not
local to the machine on which the client is executing.
Runtime verification means that from the client’s point of
view, the observed behavior of the model is indistinguishable
from that of the server, i.e., they are behaviorally equivalent.
Because this is a dynamic check, it means they are equivalent only on the observed behavior; ideally the specification
allows more behaviors. An implementation restricts its behavior, usually for reasons of efficiency.
1. They must be stable: an object reference returned to
C maintains its identity in S . The client C can always
use that reference to refer to the same object.
2. They can be tested for equality: a reflexive, symmetric
operation allows P to distinguish different objects.
We believe both of these properties to be reasonable and
easily met; we mention them only to be explicit about our
dependencies.
4.2
Verifying Data
For methods that return atomic data values, runtime verification is comparatively simple. P maintains a global table
map, which stores object references created in P to pairs of
corresponding model and server object references:
map as Map of Object to (Object ∗ Object)
The datatype Map in AsmL is an associative array, i.e.,
an array whose indices do not have to be integers. Initially
this table contains just one entry: the reference of the root
object of P along with the tuple containing the references
to the roots of M and S . This entry is created when C
first connects to P . As object references are returned to the
client, the map is kept current, as explained in Section 4.3.
Thus when the client uses an interface reference of type
IFigure to call getColor, it is really calling the method on
an instance of a class, PFigure, defined in P . The behavior
of PFigure.getColor is shown in Figure 5. The table map
is consulted to retrieve the interface references to M and
S . Each is an interface reference to an object implementing
the interface IFigure in M and S , respectively. The method
getColor is called in each of the components and their return
3
9
class PFigure implements IFigure
getColor () as Color =
let (M , S ) = map(me)
let m = M .getColor ()
let s = S .getColor ()
if s 6= m then
throw Exception(. . .)
else
return s
class PCanvas implements ICanvas
createFigure(. . .) as IFigure =
let (M , S ) = map(me)
let m = M .createFigure(. . .)
let s = S .createFigure(. . .)
if (m = nothing) and (s = nothing) then
return nothing
else
let p = checkObjects(m, s)
if p = nothing then
let p 0 = new PFigure()
map(p 0 ) := (m, s)
return p 0
else
return p
Figure 5: PFigure.getColor
values are then compared to guarantee that M and S remain
equivalent, from the perspective of the client.
Consider the similar method setWidth that would be defined on an instance of a class PBorder. If the client called
it with a negative argument, then M would throw an exception. In such a case, S.setWidth should also throw a subtype
of the same exception type.
4.3
Figure 6: PCanvas.createFigure
checkObjects(m as Object, s as Object) as Object =
if (m = nothing) or (s = nothing) then
throw Exception(. . .)
elseif ∃ p ∈ domain(map)
where map(p) = (m, s) then
return p
elseif ∃ p ∈ domain(map)
where first(map(p)) = m
or second (map(p)) = s then
throw Exception(. . .)
else
return nothing
Verifying Objects
The simple scheme outlined in Section 4.2 breaks down
when a method returns an interface reference. For instance,
in our example, the methods createFigure and getBorder
both return interface references. Consider the situation
when a client calls createFigure (which is probably the first
method the client will call). Our proxy, P , calls the method
on both the implementation and the model. Both M and S
will return to P a created object internal to the respective
components; the objects must support the IFigure interface.
One problem is that there is no way for P to make an
equality test between the references returned from M and
S . That is, it cannot decide at this time whether or not
the two figures are the same. That can be decided only as
operations returning simple data (such as getColor) on those
figures are invoked.
Another problem is that P needs to return a reference
(to an object supporting the IFigure interface) to the client.
If the interface reference from S is returned directly to C ,
then P will no longer be able to monitor the communication
between C and S . C may use that interface reference to
make further method calls and those calls would go directly
to S .
To solve both problems, P creates a a new local object,
p, from the class PFigure. P installs the pair of objects
returned from M and S in the global table map, indexed by
p. Instead of returning either the reference from M or S ,
it returns a reference to the local object p. Then, when the
client calls getColor on p, it is executing the method shown
in Figure 5.
In this way, all interface references from S are spoofed.
(This is the standard way marshalling proxies are created
for remote interfaces in COM [7].) Returning the interface
reference to the local object means that all future calls can
be monitored.
Now, consider the case when an interface reference is not
new; say it is a reference that has been returned from S in
some previous call. For instance, if getBorder is called more
than once on the same figure, the same reference will be returned. So if S returns an interface reference, s1 , then M
Figure 7: checkObjects
must also have returned an interface reference, m1 . Again,
there is no way to know if the two interface references refer to two “equal” components: equality cannot be decided
between them.
However, the references must have been seen together as a
pair the previous time; this is where we assume the stability
of the interface references. If the two returned references
form such a pair, then there is a local object, p, such that
map(p) is the pair (m1 , s1 ). Then p is the spoof for the pair
and should be returned to C . Otherwise, there is some other
pair in the map (m2 , s1 ), indexed by another local object p 0 .
(Remember the assumption is that s1 has been seen before,
i.e., returned from S at some earlier method invocation.)
This is enough evidence to know that M and S are not
behaviorally equivalent because they are not responding in
the same way to the same method call. The symmetric
argument handles the case when m1 has been seen by P
before.
All of these possibilities are illustrated in P ’s method for
createFigure as shown in Figure 6. The logic that decides
the correspondence (or lack thereof) between the returned
interface references is enapsulated in the method checkObjects, which is defined in Figure 7. This explains how the
entry in the table retrieved in Figure 5 was initially created.
4
10
5.
EXPERIENCES
faces, but with pre- and post-conditions. Their main concern is the verification of frame properties, i.e., controlling
the modifications a method can make.
In Edwards et al. [9], an architecture is proposed for deriving wrappers for any class implementing an interface that
is enriched with pre- and post-conditions. Human intervention is required to map the concrete state of the class to the
abstract state used in the interface specification. The advantage of our approach is that the operations on the abstract
state are independent of the concrete state, so an AsmL
specification can check any implementation. However, the
use of an abstraction function means that discrepencies can
potentially be discovered earlier than by checking behavioral
equivalence as we do.
Jonkers, working at Phillips, is also working on interface
specifications [18]. In their work on Ispec, they use transition systems to provide the semantics for interface specifications. However they don’t try to execute the model in
isolation or run it in parallel with the implementation. Instead they want to generate black-box tests.
Besides JML, there has been a lot of work on using assertions to specify Java interfaces, e.g., Contract Java [11,
12], iContract [8], and Jass [4]. And of course, Eiffel [23,
24], uses pre- and post-conditions to specify components.
However, these do not introduce model programs as we do.
Closer to our work on runtime verification is the work on
program checking as proposed by Blum and Wasserman [6].
They argue that it is often much easier to write a program
that checks whether a result is correct, than to prove the
algorithm correct that produces the result. For example,
it is difficult to factor an integer, but, given x and y, it is
trivial to determine whether or not y is a factor of x . In our
case the checker is the specification.
Using this idea, Antoy and Hamlet [1] propose the use of
algebraic specifications to specify software. Algebraic specifications use high level data structures, thus solving one of
the aforementioned problems of pre-/post-conditions. The
price is that when checking the implementation against the
specification one needs abstraction. Their system is able
to run the executable specification (in fact it is a rewrite
system) in parallel with the implementation in C; similar to
our framework, they check the results on the method boundaries. They include a comprehensive review of similar work;
we do not repeat it here. But due to the restricted nature of
algebraic specifications, they cannot deal with state or with
object identities (without a lot of coding).
Another similar project is the SLAM project by HerranzNieva and Moreno-Navarro [17]. They developed a new
specification language and define class operations with pre/post-conditions. The resulting specifications are translated
to C++; part of the pre-/post-conditions are compiled to
Prolog. Using a bridge between C++ and Prolog, the Prolog clauses are used as assertions during runtime. Results
are speculative, since the project is in the early stages of
development.
While not specifically relating to interface specification,
Erlingsson and Schneider [10] have also developed a method
for injecting a runtime monitor into programs to enforce
security properties. In their examples, the monitors are derived from finite automata and so are consequently limited.
The transitions of the automata must be triggered by events
that are observable at the level of machine code. This is appropriate for the security properties they check, but are not
Within Microsoft, we have used AsmL for runtime verification in two case studies on existing product components.
Since they already existed, we reverse-engineered an AsmL
model from the available documentation, discussions with
the responsible product group, and (self-imposed) limited
access to the source code. We did not want to re-implement
the current components, but wanted to have a true n-version
system. Both components are of medium-size: between 50
and 100 thousand lines of code (LOC).
The first case study was partially described in [2]. We
created a model of the Debug Services component for the
.NET Runtime. The Debug Services control the execution
of a .NET component in the runtime; a debugger is a client
that requests the installation and removal of breakpoints,
etc. (In turn, a person executing a debugger is a client
of the debugger.) Our model was less than 4K LOC. The
published case study is more concerned with describing the
methodology for creating the specification. In the course of
performing runtime verification, we encountered a violation
of the Debug Services protocol. In conversations with the
product team, it turned out that there was an unresolved
ambiguity in the meaning of one method when used to respond to a callback. While it could not be considered a
major bug in any sense, it did make them realize that they
had never decided how to resolve the ambiguity even though
they had held meetings about it. Had they been using runtime verification, the problem would not have been able to
lie hidden for so long.
For our second case study we modeled the Network Configuration Engine that is part of the Windows operating system. The engine is responsible for maintaining a database
of installed network drivers and the network paths that exist between them. We wrote the specification only from the
documentation; it ended up being about 2K LOC. We performed runtime verification using an automated test suite
provided by the product group and again found a discrepency
between the model and the implementation. For one particular method, a flag is used to choose between two different
behaviors. However in the real implementation there had
originally been three different behaviors and the one that
was removed was different from the one that was removed
from the documentation. This demonstrated the usefulness
of having a specification as documentation: had it been used
during the development process, the documentation would
have been guaranteed to be consistent with the implementation.
6.
RELATED WORK
The need to specify and check components is widely recognized (cf. [26]). However there is neither a standard way
to specify components nor any standard for checking an implementation’s conformance with its specification.
In a recent book, Leavens and Sitaraman [19] summarize
the current approaches for specifying components formally.
In that book, Leavens and Dhara [20] use the specification
language JML to specify Java components. As we do, JML
uses model programs in addition to pre- and post-conditions.
Our approaches are very similar, but JML is restricted to
specifying Java, while AsmL can be used with any programming language. Müller and Poetzsch-Heffter’s [25] article
in the same volume also concerns the specification of inter5
11
suited for checking interface properties.
Instead of performing checks at runtime, there has been
much work using static analysis to prove general properties
about a program. While it provides a more general result
that is true of any execution of the program, the limitations
of program analysis enforce a consequent weakening of the
set of properties that can be checked. Perhaps the most well
known static program checker is ESC/Java [21].
7.
[4] Detlef Bartetzko, Clemens Fischer, Michael Möller,
and Heike Wehrheim. Jass — Java with Assertions.
http://semantik.informatik.unioldenburg.de/~jass/doc/index.html.
[5] A. Blass, Y. Gurevich, and S. Shelah. Choiceless
Polynomial Time. Annals of Pure and Applied Logic,
100:141–187, 1999.
[6] Manuel Blum and Hal Wasserman. Software reliability
via run-time result-checking. Journal of the ACM,
44(6):826–849, November 1997.
[7] Don Box. Essential COM. Addison-Wesley Publishing
Company, Reading, Massachusetts, 1998.
[8] A. Duncan and U. Hölze. Adding contracts to Java
with handshake. Technical Report TRCS98-32,
University of California at Santa Barbara, December
1998.
[9] Stephen H. Edwards, Gulam Shakir, Murali
Sitaraman, Bruce W. Weide, and Joseph
Hollingsworth. A framework for detecting interface
violations in component-based software. In
P. Devanbu and J. Poulin, editors, Proceedings: Fifth
International Conference on Software Reuse, pages
46–55. IEEE Computer Society Press, 1998.
[10] Ulfar Erlingsson and Fred B. Schneider. SASI
enforcement of security policies: A retrospective.
Technical Report TR99-1758, Cornell University,
Computer Science, July 19, 1999.
[11] Robert Bruce Findler and Matthias Felleisen.
Behavioral interface contracts for java. Technical
Report TR00-366, Department of Computer Science,
Rice University, August 2000.
[12] Robert Bruce Findler, Mario Latendresse, and
Matthias Felleisen. Object-oriented programming
languages need well-founded contracts. Technical
Report TR01-372, Department of Computer Science,
Rice University, 6100 South Main Stree, Houston,
Texas, 77005, 2001.
[13] Microsoft Research Foundations of Software
Engineering, 2001.
http://research.microsoft.com/fse.
[14] Uwe Glässer, Yuri Gurevich, and Margus Veanes.
Universal plug and play machine models. Technical
Report MSR-TR-2001-59, Microsoft Research, June
2001. Available from
http://research.microsoft.com/pubs/.
[15] Wolfgang Grieskamp, Yuri Gurevich, Wolfram Schulte,
and Margus Veanes. Testing with Abstract State
Machines. In Formal Methods and Tools for Computer
Science, Eurocast 2001, pages 257–261. IUCTC
Universidad de Las Palmas de Gran Canaria, February
2001. Submitted for inclusion in LNCS ASM 2001.
[16] Y. Gurevich. Evolving Algebras 1993: Lipari Guide.
In E. Börger, editor, Specification and Validation
Methods, pages 9–36. Oxford University Press, 1995.
[17] Angel Herranz-Nieva and Juan Jose Moreno-Navarro.
Generation of and debugging with logical pre and
post-conditions. http://lml.ls.fi.upm.es/slam/.
[18] H.B. Jonker. Ispec: Towards practical and sound
interface specifications. In IFM’2000, volume 1954 of
LNCS, pages 116–135, Berlin, Germany, November
1999. Springer-Verlag.
[19] G. T. Leavens and M. Sitaraman (eds.). Foundations
CONCLUSIONS
We have presented a specification method for interfaces
that allows a component implementing the interface to be
run concurrently with its specification with no need for recompiling, re-linking, or any sort of invasive instrumentation
at all. While runtime verification does not prove that the
component is correct (with respect to its specification), it
does guarantee that, for that particular trace, the component is a behavioral subtype of its specification. For systems
that are not amenable to current formal verification technology, this may be the highest degree of formal proof possible.
To be useful in real-world applications, formal specifications
must provide benefit within the existing development processes. Runtime verification can be used as part of current
testing techniques, whether directed or ad-hoc.
We have used our methods to model two medium-sized
components within Microsoft and performed runtime verification during user scenarios as well as in the context of
testing using an automated test suite. Both times we have
been able to find discrepencies between the actual component and its specification.
While this presentation has been restricted to deterministic specifications and systems that do not make callbacks,
these burdensome qualifications are addressed in a more
complicated scheme [3]. Unfortunately, this scheme is subject to exponential worst-case behavior. We are developing
a new system that will be integrated into the .NET runtime,
which does not suffer from this drawback.
Our specification language, AsmL, allows other opportunities which are beyond the scope of this paper. For instance, we have used it for early prototyping and test-case
generation [15].
We believe that runtime verification shows promise in providing automated support for keeping a specification alive
and for ensuring that an implementation correctly implements its specification.
8.
REFERENCES
[1] Sergio Antoy and Richard G. Hamlet. Automatically
checking an implementation against its formal
specification. Software Engineering, 26(1):55–69, 2000.
[2] Mike Barnett, Egon Börger, Yuri Gurevich, Wolfram
Schulte, and Margus Veanes. Using Abstract State
Machines at Microsoft: A case study. In Abstract State
Machines: Theory and Applications, volume 1912 of
LNCS, pages 367–379, Berlin, Germany, March 2000.
Springer-Verlag.
[3] Mike Barnett, Lev Nachmanson, and Wolfram
Schulte. Conformance checking of components against
their non-deterministic specifications. Technical
Report MSR-TR-2001-56, Microsoft Research, June
2001. Available from
http://research.microsoft.com/pubs.
6
12
[20]
[21]
[22]
[23]
[24]
[25]
[26]
of Component-Based Systems. Cambridge University
Press, New York, NY, 2000.
Gary T. Leavens and Krishna Kishore Dhara.
Concepts of behavioral subtyping and a sketch of their
extension to component-based systems. In Gary T.
Leavens and Murali Sitaraman, editors, Foundations
of Component-Based Systems, chapter 6, pages
113–135. Cambridge University Press, 2000.
K. Rustan M. Leino. Applications of extended static
checking. In Patrick Cousot, editor, Static Analysis:
8th International Symposium (SAS’01), Lecture Notes
in Computer Science, pages 185–193. Springer, July
2001.
Barbara Liskov and Jeannette Wing. A behavioral
notion of subtyping. ACM Transactions on
Programming Languages and Systems,
16(6):1811–1841, November 1994.
Bertrand Meyer. Eiffel: The Language.
Object-Oriented Series. Prentice Hall, New York, NY,
1992.
Bertrand Meyer. Object-oriented Software
Construction. Prentice Hall, New York, NY, second
edition, 1997.
P. Müller and A. Poetzsch-Heffter. Modular
specification and verification techniques for
object-oriented software components. In Foundations
of Component-Based Systems [19], pages 137–160.
Clemens Szyperski. Component Software.
Addison-Wesley Publishing Company, Reading,
Massachusetts, 1999.
7
13
7RZDUG5HIOHFWLYH0HWDGDWD:UDSSHUVIRU)RUPDOO\
6SHFLILHG6RIWZDUH&RPSRQHQWV
6WHSKHQ+(GZDUGV
9LUJLQLD 7HFK 'HSW RI &RPSXWHU 6FLHQFH
0F%U\GH +DOO
%ODFNVEXUJ 9$ 86$
HGZDUGV#FVYWHGX
$%675$&7
$EVWUDFW
UHDVRQ
EHKDYLRUDO
VSHFLILFDWLRQV
IRU
VRIWZDUH
FRPSRQHQWV
WR
KDYLRU
RI
XQGHUVWDQG
KRZHYHU
UHTXLUHV
FRPSRQHQWV
RI
ZKDW
LV
WR
WKH
LQIRUPDWLRQ
GLVWULEXWLQJ
EDVHG
SRUWV
RQ
WKDW
WKH
IRU
GHOLYHU\
SURJUDPOHYHO
VXSSRUW
WR
LQ
ZLWK
D
$
LQWURVSHFWLYH
DERXW
WKHVH
GHOLYHUHG
FRQVLGHUV
VSHFLILFDWLRQ
³VRXUFH´
SUHVHQWHG
EH
SDSHU
SDFNDJH
VRXQGO\
$FKLHYLQJ
DORQJ
WKH
DQG
DQ
UHIOHFWLYH
DFFHVV
WR
EH
5DWKHU
LQWHUIDFH
WKH FRPSRQHQW LWVHOI
JLHV
EHKDYLRUDO
SRVVLEOH
IRU
IRU
FRQWUDFW
WKH
UHIOHFWLYH
WKDQ
VXS
YLRODWLRQ
FKHFNLQJ
WR
LQFOXGLQJ
,QGHHG
D
ZDUH
WKH
LV
KDYLRUV
GHVFULS
LQWHUIDFH
VHOIWHVWLQJ
FODVV
LQYDULDQWV
6SHFLI\LQJ
DQG
VSHFLILFDWLRQ
DVVHUWLRQV
)
DWHG
DQG
SUH
DQG
DERXW
>
7HFKQLTXHV²REMHFWRULHQWHG
-DYD%HDQV
LVVXH
SUREOHP
ZKHQ
VRXUFH
LQ UHDVRQLQJ DERXW FRPSRQHQWEDVHG VRIW
RI
FRUUHFWO\
FRGH
LV
UHDVRQLQJ
XQDYDLODEOH
DERXW
,I
WKH
FRPSRVLWH
FRPSRQHQW
EH
SUR
QRQFRGH
LQIRUPDWLRQ
6HFWLRQ DORQJ
RXWOLQHV
ZLWK
WKH
WKH
FRPSRQHQW¶V
SUREOHP
ZKLOH
LPSOH
6HFWLRQ PD\ EH DSSURSULDWH WR SURYLGH WKURXJK VXFK D UHIOHFWLYH ZUDSSHU
6HFWLRQ 7RROV
RXWOLQHV
DQG
VXPPDUL]HV
UHODWLRQV
WKH
ZLWK
OLPLWDWLRQV
SUHYLRXV
RI
ZRUN
WKH
DQG
DSSURDFK
6HFWLRQ 6HFWLRQ
VXPPDUL]HV
WKH LVVXHV FRYHUHG
6RIWZDUH
'
7HVWLQJ DQG 'HEXJJLQJ²GHEXJJLQJ
&25%$
6HFWLRQ H[SORUHV WKH YDULRXV NLQGV RI PHWDGDWD DQG VHUYLFHV WKDW
LQYDULDQWV
&RGLQJ
SURJUDPPLQJ
GHULYDWLYHV
ILFDWLRQ GHWDLOV WKURXJK D VWDQGDUGL]HG UHIOHFWLRQEDVHG LQWHUIDFH
FKHFNHUV
3URJUDPV²
SRVWFRQGLWLRQV
6RIWZDUH (QJLQHHULQJ@
'
DVVHUWLRQ
5HDVRQLQJ
LWV
SURYLGHV DFFHVV WR D ZLGH YDULHW\ RI LQIRUPDWLRQ LQFOXGLQJ VSHFL
/RJLFV DQG 0HDQLQJV RI 3URJUDPV@
9HULI\LQJ
DQG
VNHWFKHV D SRVVLEOH VROXWLRQ GHOLYHULQJ D ZUDSSHU FRPSRQHQW WKDW
>
WHFKQLTXHV
(QJLQHHULQJ@
FRQWUDFW
RI
DQG GHOLYHU D FRPSRQHQW¶V IRUPDO VSHFLILFDWLRQ DV ZHOO DV DVVRFL
6RIWZDUH3URJUDP 9HULILFDWLRQ²
E\
EHKDYLRU
7KLV SRVLWLRQ SDSHU H[SORUHV WKH TXHVWLRQ RI KRZ EHVW WR SDFNDJH
DQG
&DWHJRULHVDQG6XEMHFW'HVFULSWRUV
SURJUDPPLQJ
WKH
)RU PRVW FRPPHUFLDO FRPSRQHQW WHFKQROR
&20
FHQWUDO
PHQWDWLRQ
PHWKRGV
FRPSRQHQWEDVHG
IRUP ZLOO LW EH GHOLYHUHG"
IRUPDO
RI
VSHFLI\LQJ
DOVR
WHFKQRORJ\ GRHV QRW KDYH EXLOWLQ UHIOHFWLRQ FDSDELOLWLHV
6RIWZDUH (QJLQHHULQJ@
EHKDYLRU
IRUPDOO\
YLGHU LV JRLQJ WR GHOLYHU D EHKDYLRUDO VSHFLILFDWLRQ DV ZHOO LQ ZKDW
DEVWUDFW YDOXH PDQLSXODWLRQ HYHQ ZKHQ WKH XQGHUO\LQJ FRPSRQHQW
' >
DW
$FWLYH; DQG 1(7 FRPSRQHQWV DUH GLVWULEXWHG LQ D ELQDU\ IRUP
VROXWLRQ
WKDW
G\QDPLF
FRPSRQHQW¶V IRUPDO VSHFLILFDWLRQ PXVW EH GLVWULEXWHG DORQJ ZLWK
ZLWK
TXHVWLRQ
DOWHUQDWH
WKH
(IIRUWV
7R DFKLHYH WKLV EHQHILW IRU D FRPPHUFLDO FRPSRQHQW QDWXUDOO\ WKH
YHULILFDWLRQ
FRPSRQHQW
IRUP
WKH
EHQHILWV
%\ HPERG\LQJ WKLV LQWHUIDFH LQ D ZUDSSHU FRP
EHFRPHV
VHUYLFHV
7KLV
DORQJ
VSHFLILFDWLRQV
LV
UHDVRQ
VSHFLILFDWLRQV
ZD\
UHIOHFWLRQ
LW
DQG
V\VWHPV
FRQVXPHU
EHVW
WLRQV LV SURSRVHG
SRQHQW
SUHGLFW
FRPSRQHQWEDVHG
DERXW
V\VWHPV
VRIWZDUH FRPSRQHQWV DLP DW PD[LPL]LQJ WKLV HIIHFW
RXW WKH SRWHQWLDO IRU VLJQLILFDQWO\ LPSURYLQJ D VRIWZDUH HQJLQHHU¶V
DELOLW\
VRXQGO\
VRIWZDUH
KROG
>
352%/(0$1'6,*1,),&$1&(
DLGV
7KH
*HQHUDO7HUPV
SUREOHP
XQGHU
FRQVLGHUDWLRQ
DV
LQWURGXFHG
LQ
6HFWLRQ VXSSRVHV WKDW D FRPSRQHQW SURYLGHU DOVR ZLVKHV WR SURYLGH D IRU
PDO
'HVLJQ 9HULILFDWLRQ
VSHFLILFDWLRQ
SHUKDSV
DORQJ
ZLWK
YHULILFDWLRQ
LQIRUPDWLRQ
ZKHQ D FRPSRQHQW LV GHOLYHUHG
.H\ZRUGV
:KDW LV WKH EHVW ZD\ WR SDFNDJH VSHFLILFDWLRQ DQG YHULIL
)RUPDO VSHFLILFDWLRQ UHIOHFWLRQ GHVLJQ E\ FRQWUDFW UHSUHVHQWDWLRQ
FDWLRQ LQIRUPDWLRQ IRU GLVWULEXWLRQ WR FOLHQWV DORQJ ZLWK
LQYDULDQW ZUDSSHU FODVV XQLW WHVW LQWHJUDWLRQ WHVW
D FRPSRQHQW"
2QH
,1752'8&7,21
&RPSRQHQWEDVHG
PRUH
SUHYDOHQW
SURGXFWLYLW\
VRIWZDUH
HYHU\
DQG
GD\
WKH
GHYHORSPHQW
FDUU\LQJ
ZLWK
LW
WKH
KRSH
EHFRPLQJ
IRU
IDFWRUV
SURWHFWLRQ
LQ
RI
ELQDU\
SDFNDJLQJ
SURSULHWDU\
RI
WUDGH VHFUHWV HPERGLHG LQ WKH FRPSRQHQW¶V LPSOHPHQWDWLRQ
JUHDWHU
FRQFHUQ
GRHV
QRW
DULVH
ZLWK
VSHFLILFDWLRQV
RI
FRP
LQIRUPDWLRQ
FRXUVH
7KH
RU
7KLV
FOLHQW
KDYLRUDO VSHFLILFDWLRQ XQOHVV WKH VSHFLILFDWLRQ LV FRPSOHWHO\ DFFHV
QHZO\
VLEOH
HYHQ
JUHDWHU
RIIWKHVKHOI
LV
QHQWV VKRXOG EH ZHOOVHDVRQHG ZHOOWHVWHG DQG PRUH UHOLDEOH WKDQ
$Q
,QGHHG
LV
GULYLQJ
FDQQRW UHFHLYH PDQ\ RI WKH EHQHILWV RI KDYLQJ D FRPSRQHQW¶V EH
FRGH
TXDOLW\
&%6'
SULPDU\
FRPSRQHQWV
FRPSR
ZULWWHQ
VRIWZDUH
RI
PHUFLDO
EHQHILW
SRWHQWLDOO\
FDQ
EH
³+LGLQJ´
D
VSHFLILFDWLRQ
FOHDUO\
LV
DW
GLUHFW
RGGV
ZLWK
WKH
SURYLGHG E\ ZHOOGHVLJQHG VRIWZDUH FRPSRQHQWV KRZHYHU WKH\²
YDOXH DGGHG E\ GLVWULEXWLQJ LW ZLWK D FRPSRQHQW LQ WKH ILUVW SODFH
RU
7KLV OHDGV WR WKH QDwYH YLHZ WKDW D IRUPDO VSHFLILFDWLRQ VKRXOG EH
PRUH
FRUUHFWO\
EHKDYLRU²FDQ
KHOS
WKH
DEVWUDFW
VRIWZDUH
VSHFLILFDWLRQV
HQJLQHHUV
WKDW
XQGHUVWDQG
H[SODLQ
SUHGLFW
WKHLU
DQG
GHOLYHUHG
14
LQ
KXPDQUHDGDEOH
³VRXUFH´
IRUP
(YHQ
VRPHWKLQJ
DV
VLPSOH DV D WH[W ILOH FRQWDLQLQJ WKH VSHFLILFDWLRQ LQ D VXLWDEOH IRU
WLRQV
PDO QRWDWLRQ VKRXOG VXIILFH
SDWLELOLW\
LW
VXSSRUWV
DXWRPDWLF
GXULQJ
FKHFNV
FRPSRVLWLRQ
IRU
DQG
LW
V\QWDFWLF
FDQ
HYHQ
LQWHUIDFH
VXSSRUW
FRP
JHQHUDO
SXUSRVH FRPSRQHQWOHYHO VFULSWLQJ WRROV LQ VRPH FDVHV
7KLV VLPSOH DSSURDFK WR GLVWULEXWLQJ VSHFLILFDWLRQV WUHDWV WKHP WKH
VDPH
DV
WUDGLWLRQDO
5HIOHFWIRUD0RPHQW
GRFXPHQWDWLRQ ZKLFK LV GLVWULEXWHG PRVW IUH
TXHQWO\ LQ SULQWHG IRUP DV SODLQ WH[W DV +70/ RU LQ D SODWIRUP
VSHFLILF
KHOS
ILOH
IRUPDW
%HVLGHV
VLPSOLFLW\
VRXUFH
7KH
GLVWULEXWLRQ
RI VSHFLILFDWLRQV KDV DQRWKHU VWUHQJWK LW KLJKOLJKWV DQG UHLQIRUFHV
WKH
IDFW
WKDW
VSHFLILFDWLRQV
DUH
GHVLJQHG
FRPPXQLFDWLRQ
IRU
LVQ¶W
D
IRUPDO
VSHFLILFDWLRQ
WKH
XOWLPDWH
LQ
IOHFWLRQ
RI
D
FRPSRQHQW
EHKDYLRU
>
@
RU
WR
UHVSRQG
WR
LPSOHPHQWDWLRQ
5HIOHFWLYH
TXHULHV
LV
VRIWZDUH
WKH
LV
DERXW
LWV
FRUQHUVWRQH
FDSDEOH
RI
RZQ
UH
RI
UHSUHVHQWLQJ
ZLWK
DQG
VRIWZDUH HQJLQHHUV²WKH\ DUH ZULWWHQ IRU RWKHU SHRSOH WR UHDG
HVVHQFH
DELOLW\
VWUXFWXUH
,Q
WKXV
RSHUDWLQJ
RQ
DW
&RPSXWDWLRQDO UHIOHFWLRQ
UXQWLPH
LV
WKH
VRPH
DFWLYLW\
RI
DVSHFWV
D
RI
LWVHOI
FRPSXWDWLRQDO
V\V
ULJRURXV
WHP
ZKHQ
FRPSXWLQJ
DERXW
RU
RSHUDWLQJ
RQ
DQG
WKXV
SRWHQWLDOO\
GRFXPHQWDWLRQ"
DOWHULQJ
:KLOH
WKH
YDOXH
RI
UHDGLQJ
VSHFLILFDWLRQV
FDQQRW
EH
RSSRUWXQLW\
GHYHORSPHQW
WR
DSSURSULDWHO\
WRROV
GXULQJ
OHYHUDJH
FRPSRQHQW
IRUFH
VXSSRUW
RZQ
HYHU\
&%6'
WRRO
WR
SLFN
SDUVLQJLQWHUQDOL]DWLRQ
UHSUHVHQWDWLRQ
FRPSRQHQWV
RI
WKH
RI
VRPH
WKDW
UHODWLRQV
VSHFLILFDWLRQV
FRPSRVLWLRQ
DXWRPDWHG UHDVRQLQJ RU YHULILFDWLRQ WDVNV
WR
WKRVH
DQG
LQ
VSHFLILFDWLRQ
EHWZHHQ
DQG
WLRQ
IRU
QRWDWLRQ
PDLQWDLQ
VSHFLILFDWLRQV
DQG
WKLV
SDSHU
LV
DLPLQJ
WR
VXSSRUW
ERWK
KXPDQ
>@
DQG
7KLV
KDV
WR
FRPSRQHQW
FRQFHSW
VHULRXVO\
PRGLI\
D
FDSDELOLWLHV
SURSHUWLHV
FRPSRQHQW
RU
UHDGRQO\
LQWHUFHVVRU\
DOWHU
LWV
WDWLRQDO
UHIOHFWLRQ
VWULFWHG
LQWURVSHFWLYH
DQG
PHWDSURJUDPPLQJ
SURWRFROV
>
VXSSRUWHG
E\
@
ILHG
WR LQFOXGH DFFHVV WR VSHFLILFDWLRQOHYHO GHVFULSWLRQV"
D
FRPSRQHQW¶V
FOLHQW
FDQQRW
UHDS
D VSHFLILFDWLRQ XQOHVV WKH VSHFLILFDWLRQ LV
GHOLYHUHG ZLWK WKH FRPSRQHQW
UH
,I D W\SLFDO FRPSRQHQW VD\ D -DYD%HDQ DOUHDG\ VXSSRUWV D VWDQ
IRU
RI
PRUH
FRPSRQHQW
VFDOHG GRZQ LQWURVSHFWLYH LQWHUIDFHV
KRZ
DSSDUHQW
VRPH
DQG
IHDWXUHV
LV
LQ
,Q HIIHFW ³LQWHUIDFH LQVSHF
LQWHUIDFH
EHQHILWV
WKH
PRVW
H[SRUWHG
WKH
DFFHVV
VHUYLFHV
EHKDYLRU
GDUGL]HG
RI
WKH
:KLOH LQWHUFHVVRU\ SURWRFROV DUH DW WKH KHDUW RI FRPSX
7KH VLJQLILFDQFH RI WKLV SUREOHP WR UHVHDUFKHUV LQ IRUPDOO\ VSHFL
FRPSRQHQWV
LQ
REMHFW
WLRQ´ $3,V VXSSRUWHG E\ PRVW FRPPHUFLDO FRPSRQHQWV DUH VLPSO\
WRRO FRQVXPSWLRQ DQG XVH RI VSHFLILFDWLRQV
PDQ\
DURVH
LPSDFWHG
SURYLGH
ZKLOH
WHFKQRORJLHV DUH VWLOO SRZHUIXO WRROV
$V D
UHVXOW LQ DVNLQJ ZKDW LV WKH ³EHVW´ ZD\ WR SDFNDJH VSHFLILFDWLRQV
GLVWULEXWLRQ
RQH
ZD\ >@
WLRQ RI HIIRUW DPRQJ &%6' WRRO LPSOHPHQWHUV FRQIOLFWLQJ FKRLFHV
IRU
DUHQD
LQWURVSHFWLYH
VHUYLFHV
LQVSHFWLQJ
DOORZ
LWV
8QIRUWXQDWHO\ WKLV VWUDWHJ\ LPSOLHV D KXJH GXSOLFD
PDGH LQ GLIIHUHQW WRROV DQG D QXPEHU RI RWKHU LQHIILFLHQFLHV
FRPSXWDWLRQ
ODQJXDJH
$ UHIOHFWLYH FRPSRQHQW FDQ SURYLGH WZR GLIIHUHQW IRUPV RI UHIOHF
GXULQJ
,W LV FHUWDLQO\ SRVVLEOH
QRWDWLRQ
RZQ
RULHQWHG SURJUDPPLQJ ODQJXDJH GHVLJQ
PDWHG WUHDWLQJ VSHFLILFDWLRQV DV ³SODLQ ROG GRFXPHQWDWLRQ´ PLVVHV
WKH
LWV
SURJUDPPLQJ
XQGHUHVWL
UHSRUWLQJ
GLIILFXOW
RQ
WKH
FDQ
LW
V\QWDFWLF
EH
WR
SURSHUWLHV
H[WHQG
WKDW
RI
LWV
LQWHUIDFH
3HUKDSV WKH
PRUH LQWHUHVWLQJ TXHVWLRQ LV KRZ IDU FDQ WKLV VWUDWHJ\ EH WDNHQ"
6LPLODUO\ WKH VSHFLILFDWLRQ VKRXOG
0DQ\ 22 ODQJXDJHV WKDW VXSSRUW UHIOHFWLRQ LQFOXGLQJ -DYD GR VR
EH GHOLYHUHG LQ D IRUP WKDW FRQYHQLHQWO\ VXSSRUWV DOO RI WKH DFWLYL
E\
WLHV
WKH
FOLHQW
PD\
ZLVK
WR
SHUIRUP
LQFOXGLQJ
ERWK
DVVRFLDWLQJ
HDFK
REMHFW
ZLWK
D
PHWDREMHFW
WKDW
HQFDSVXODWHV
SHRSOH
LQIRUPDWLRQ
DERXW
KRZ
WKDW
REMHFW
LV
VWUXFWXUHG
DQG
KRZ
LW
EH
RULHQWHG DQG WRRO RULHQWHG WDVNV
KDYHV
$3266,%/(62/87,215()/(&7,9(
0(7$'$7$:5$33(56
,I
SURYLGLQJ
VSHFLILFDWLRQV
DQG
RWKHU
UHODWHG
LQIRUPDWLRQ
2IWHQ LQ FODVVEDVHG 22 ODQJXDJHV DQ REMHFW¶V PHWDREMHFW
LV D VLQJOHWRQ REMHFW UHSUHVHQWLQJ LWV FODVV
PHWKRGV VXSSRUWHG E\ LQVWDQFHV RI WKH FODVV WKH QDPH DQG W\SH RI
LQVWDQFH
DV
DQG
WUDGLWLRQDO GRFXPHQWDWLRQ KDV GLVDGYDQWDJHV ZKDW DOWHUQDWLYHV DUH
VXSHUFODVVHV
DYDLODEOH"
VRU\
&RQVLGHU WKH KLVWRU\ RI VRIWZDUH FRPSRQHQWV
7KLV FODVV REMHFW VXS
SRUWV PHWKRGV WR GHWHUPLQH WKH QDPH DQG SDUDPHWHU SURILOH RI WKH
3URYLG
FODVVZLGH
DQG
FDSDELOLWLHV
VR
GDWD
RQ
VXFK
$
DV
WKH
REMHFW
FKDQJLQJ
WKH
ZD\
DQG
DOVR
PHWKRG
GLVSDWFK
TXLUHV WKH PHWDREMHFW DSSURDFK WR EH EXLOWLQ WR WKH ODQJXDJH
UHXVDEOH
FRPSRQHQWV
ZHUH
VXEURXWLQH
OLEUDULHV
RI
LQWHUFHV
³ROG
ZKHQ
LQWHUFHVVRU\
QXPEHU
RIIHU
VXSSRUWHG
GD\V´
VXSSRUWLQJ
QDPH
PD\
LQJ VSHFLILFDWLRQV LQ VRXUFH IRUP LV DQDORJRXV LQ VRPH ZD\V WR WKH
VKDUHG DV VRXUFH FRGH ILOHV DPRQJ SURJUDPPHUV
1RUPDOO\
PHPEHUV
FODVV
FDSDELOLWLHV
LV
UH
:KLOH WKH FOLHQW
%\ DQDORJ\ LW LV SRVVLEOH WR WXUQ D EHKDYLRUDO VSHFLILFDWLRQ LQWR D
FRXOG
DOZD\V
UHIHU
WR
WKH
FRGH
WKH
FULWLFDO
LQWHUIDFH
LQIRUPDWLRQ
VWDQGDORQH
FRPSRQHQW
WKDW
SURYLGHV
D
VWDQGDUG
LQWHUIDFH
IRU
LQ
WKH QDPH SDUDPHWHU SURILOH GHVFULSWLRQ DQG XVDJH RI HDFK VXE
VSHFWLQJ
URXWLQH
ZDV
W\SLFDOO\
SURYLGHG
LQ
HPEHGGHG
FRPPHQWV
RU
DOO
IDFHWV
RI
WKH
VSHFLILFDWLRQ
:KHUHDV
D
WUDGLWLRQDO
DV
223/
³FODVV´
REMHFW
UHSUHVHQWV
D
FODVV¶
VWUXFWXUDO
RU
V\QWDFWLF
VHSDUDWH GRFXPHQWDWLRQ
LQWHUIDFH D VSHFLILFDWLRQ REMHFW LQVWHDG UHSUHVHQWV D VSHFLILFDWLRQ¶V
&RPSRQHQW
VLQFH
SDFNDJLQJ
VXEURXWLQH
WUDGLWLRQDO
DQG
OLEUDULHV
GRFXPHQWDWLRQ
GLVWULEXWLRQ
ILUVW
FDPH
W\SLFDOO\
KDV
LQWR
LV
HYROYHG
XVH
HQRUPRXVO\
KRZHYHU
SURYLGHG
IRU
VWUXFWXUDO
:KLOH
FRPPHUFLDO
GHVFULSWLRQ
$OO
RI
WKH
QRUPDO
UHDVRQ
DQG KLHUDUFKLHV FRXOG DOVR EH DSSOLHG WR VSHFLILFDWLRQ REMHFWV
FRPSRQHQWV PRVW FRPPHUFLDO FRPSRQHQW WHFKQRORJLHV LQFOXGLQJ
HIIHFW
&20 &25%$ -DYD%HDQV $FWLYH; DQG 1(7 DOO SURYLGH VRPH
$3, IRU ³LQVSHFWLQJ´ D FRPSRQHQW¶V LQWHUIDFH
DQG EHKDYLRUDO
LQJ DQG VWUXFWXULQJ WHFKQLTXHV DSSOLHG WR DEVWUDFW FODVV FROOHFWLRQV
WKLV
VWUDWHJ\
WXUQV
RSHUDWLRQDO FRPSRQHQW
,Q HIIHFW D FRPSR
D
WKDW
EHKDYLRUDO
VSHFLILFDWLRQ
LQWR
,Q
DQRWKHU
FDQ EH GHOLYHUHG DORQJVLGH WKH RULJL
QDO FRPSRQHQW LW GHVFULEHV
QHQW ³NQRZV´ ZKDW LW H[SRUWV DQG D FOLHQW FDQ XVH D ZHOOGHILQHG
LQWHUIDFH
WR
³DVN´
UDPHWHUV
RI
ZKDW
W\SH
6XFK
DQ
DQG
VR
RQ
SDFNDJLQJ
,W
ZKDW
RSHUDWLRQV
DUH
QHHGHG
LQWHUIDFH
QDWXUDOO\
LV
DOORZV
D
DUH
DYDLODEOH
ZKDW
ZRQGHUIXO
DQ\
KRZ
SURSHUWLHV
ERRQ
GHYHORSPHQW
DUH
PDQ\
1RZ SURYLGLQJ VSHFLILFDWLRQ LQIRUPDWLRQ IRU FRPSRQHQWV DSSHDUV
SD
WR
SURYLGHG
HQYLURQPHQW
VXSSRUWV
³SOXJLQ´VW\OH
LQWHJUDWLRQ
RI
D
VLPSOH
PDWWHU
VLPSO\
GHVLJQ
D PHWDREMHFW V\VWHP VLPLODU
DQG DOORZ DFFHVV WR IRUPDO EHKDYLRUDO GHVFULSWLRQV LQVWHDG RI VLP
WR
SO\ V\QWDFWLF LQWHUIDFHV
LPPHGLDWHO\ PDQDJH DQG VXSSRUW DQ\ QHZO\ LQVWDOOHG FRPSRQHQW
LW
EH
WR WKDW XVHG LQ D FODVVEDVHG 223/ H[FHSW WKDW PHWDREMHFWV PRGHO
WR FRPSRQHQW
WURVSHFWLRQ
QHZ IHDWXUHV LQ DSSOLFD
FHVVRU\
15
WKLV
VHUYLFHV
,I ZH ZLVK WR OLPLW RXUVHOYHV RQO\ WR LQ
DSSURDFK
FDQQRW
PD\
HDVLO\
EH
EH
VDWLVIDFWRU\
DGGHG
+RZHYHU
WKURXJK
LQWHU
VSHFLILFDWLRQ
REMHFWV DORQH LI RQH LV ZRUNLQJ XVLQJ DQ H[LVWLQJ FRPSRQHQW WHFK
DQRWKHU
QRORJ\
QRUPDO IDVKLRQ
7KLV SRVLWLRQ LV IRXQGHG RQ WKUHH LQVLJKWV
VXSSRUWV
ZKHUH
PHWDREMHFWEDVHG
UHIOHFWLRQ
LV
QRW
EXLOWLQ
WR
WKH
FRPSRQHQW PRGHO
5HIOHFWLRQ
'HFRUDWLQJ:LWK:UDSSHUV
WLRQ
TXLUHV
OLWWOH
tion()
PRUH
WKDQ
FRPSRQHQWV
DGGLQJ
VRPH
,QWURGXFLQJ
NLQG
WKHP
LQWHUFHVVRU\
VHUYLFHV
WKDW
DOORZ
RI
FRPSRQHQWV
ERWK
GLVWULEXWHG
KXPDQUHDGDEOH
DQG
VXSSRUWV
VWDQGDUGL]HG
VPDUW
EH
DGGHG
WR
FRPSRQHQWV
DUH
5HIOHF
WRROV
ZKLOH
LW
DOVR
VXSSRUWV
XQLIRUP
DXWRPDWHG
VHUYLFHV
WKDW
HIIRUW QHFHVVLWDWHG E\ VRXUFH FRGH GLVWULEXWLRQ
2Q WKH RWKHU KDQG
FKDQJHV
WKDW
WKH
WRROEDVHG
EURZVLQJ
WR
:UDSSHUV FDQ EH XVHG WR WUDQVSDUHQWO\ DGG IHDWXUHV WR D FRP
FRPSRQHQWOHYHO
SRQHQW ZLWKRXW DIIHFWLQJ WKH XQGHUO\LQJ HQWLW\
EHKDYLRU
LQ
UHO\ RQ VSHFLILFDWLRQ GDWD ZLWKRXW UHTXLULQJ WKH GXSOLFDWLRQ RI
GetSpecifica-
RI
PHWKRG WR D FRPSRQHQW¶V LQWHUIDFH
QDWXUDOO\
>@
UH
FDQ
VHW
DQG RWKHU GRFXPHQW QDYLJDWLRQ DLGV IRU KXPDQ XQGHUVWDQGLQJ
LQJ LQWURVSHFWLYH FDSDELOLWLHV DQG IRU VKDULQJ VSHFLILFDWLRQV DPRQJ
LQWHUFKDQJHDEOH
RU
DFFHVV WR DQG DSSOLFDWLRQ RI WKH QHHGHG LQIRUPDWLRQ
6SHFLILFDWLRQ REMHFWV DUH D SRZHUIXO LGHD SDUWLFXODUO\ IRU SURYLG
EHKDYLRUDOO\
FRPSRQHQW
LPSOHPHQWHG
XVLQJ
)XUWKHU WKH\
D
DGG WKH DELOLW\ WR VXSSRUW OLPLWHG IRUPV RI LQWHUFHVVRU\ UHIOHF
QRQUHIOHFWLYH ODQJXDJH RU FRPSRQHQW WHFKQRORJ\"
WLRQ
,W
LV
SRVVLEOH
WR
DGG
VRPH
EXW
REYLRXVO\
QRW
DOO
LQWHUFHVVRU\
FDSDELOLWLHV WR DQ\ FRPSRQHQW ZLWK WKH FRUUHFW GHVLJQ
UDWRU
DW
KDQG
RSHUDWLRQV
FRQIRUP
ZRUN
WR
WKH
LQYROYHG
ZUDSV
:H
ZUDSSHU
LQ
D
WKH
LQ
WKH
FDOO
VLPSO\
UHIOHFWLYH
ZUDSSHU
RULJLQDO
FDQ
RU
DGG
VSHFLILFDWLRQ
VXFK
D
FRPSRQHQW
UHIOHFWLYH
SRQHQW
DIWHU
VRU\
LW
OD\HU
EHFRPHV
FRPSRQHQW
SRVVLEOH
ZLOO
D
SDFNDJLQJ
ZUDSSHU
GHOHJDWH
WR
WKH
$W
WR
RSHUDWLRQV
DGG
7KLV
RU
DQG
D
PLQLPXP
WKH
UHPRYH
VXSSRUWV
FKDQJLQJ
WKH
IHDWXUHV
DUH
QRW
GLUHFWO\
VXSSRUWHG
WKH
FRPSOHWHO\
LQVXODWHG
LPSOHPHQWDWLRQ
XVHG
IURP
IRU
GHSHQGHQFLHV RQ WKH FRQ
HDFK
LQVWDQFH
7KLV
FDQ
RXW ZKHQ XQQHFHVVDU\ ZLWKRXW DOWHULQJ FOLHQWV
WKLV
:KLOH
UH
D
DFFHVV WR
IHDWXUHV
EHKDYLRU
RI
EHIRUH
WKLV
LQWHUFHV
WKH
ZUDSSHU
SUHVHQWHG
UHVHDUFK
SDSHU
SURSRVHG
RU
RI
SRVLWLRQ
RI
SULRU
KHUH
LV
IRXQGHG
UHIOHFWLYH
RQ
D
ZLGHUDQJLQJ
VSHFLILFDWLRQ
ZUDSSHUV
WKH IRUP GHVFULEHG KHUH KDYH QRW \HW EHHQ LPSOHPHQWHG
XQGHUO\LQJ FRP
GHJUHH
WKH
FROOHFWLRQ
DQG
H[SORUHV
WKH
DSSURDFK
GLVWULEXWLRQ
RI
LVVXHV
ERWK
WR
DQG
SRVVLELOLWLHV
KLJKOLJKW
VSHFLILFDWLRQV
WKH
DULVLQJ
SUREOHP
RI
IURP
DQG WR VXJJHVW D SRWHQWLDO VROX
WLRQ IRU H[SORUDWLRQ
WLRQV LV GLVFXVVHG LQ 6HFWLRQ ,I
XQGHUO\LQJ
FRPSRQHQW
$SSURSULDWHO\
WKH
SDFNDJLQJ
WKLV FXVWRPL]DWLRQ IURP WKH SRLQW RI YLHZ RI EHKDYLRUDO VSHFLILFD
WKH
LQ
,QVWHDG
:+$70(7$'$7$$1'6(59,&(6
$5(1(('('"
RI
HQ
UHIOHFWLRQ VHUYLFHV FDQ EH HPSOR\HG ZKHQ QHHGHG RU VWULSSHG
LW
E\ WXUQLQJ VRPH IHDWXUHV RQ RU RII UDWKHU WKDQ PRGLI\LQJ WKH EH
KDYLRU
LQ
FDSVXODWH DQG HYHQ SDUDPHWHUL]H ZUDSSLQJ GHFLVLRQV VR WKDW
)XUWKHU E\ LQWHUSRVLQJ D VHSD
FOLHQW
VXFK
UHIOHFWLYH VSHFLILFDWLRQ
ZUDSSHU
WKH
RI
LV
FUHWH
VKRXOG
DOO
ZKHQ
,I FRPSRQHQW LQVWDQFHV DUH FUHDWHG XVLQJ IDFWRULHV >@ FOLHQW
FRGH
WKH
FRPSRQHQW
GetSpecification()
EHWZHHQ
FXVWRPL]DWLRQ²KHUH
EXW
E\
7KLV
RSHUDWLRQV
D VWDQGDORQH VSHFLILFDWLRQ REMHFW
SURFHVVLQJ
LQWHUIDFH
FRPSRQHQW
RULJLQDO
IOHFWLYH ZUDSSHU SURYLGHV WKH
UDWH
GHFR
SDWWHUQ >@ VXJJHVWV D VLPSOH DSSURDFK WKDW LV VXLWDEOH WR WKH
VLWXDWLRQ
QHZ
7KH
HYHQ
WKH XQGHUO\LQJ FRPSRQHQW WHFKQRORJ\
H[SORLWLQJ
RQH
ZLVKHV
WR SURYLGH VSHFLILFDWLRQ DQG YHULILFDWLRQ LQIRUPD
WLRQ WKURXJK D UHIOHFWLRQ LQWHUIDFH HPERGLHG LQ D ZUDSSHU FRPSR
:KLOH
QHZ
QHLWKHU
LGHD
WKH
JUDPOHYHO
FDWLRQ
WKH
XVH
QRYHOW\
RI
ZUDSSHUV
OLHV
LQ
QRU
LQIRUPDWLRQ
PRUH
XVH
WKH
LV
FOHDUO\
WXUQHG
LQWR
RSHUDWLRQV
DQG
GDWD
LQVLGH
RI
WZR
DFFHVV WR VSHFLILFDWLRQ LQIRUPDWLRQ
FDQ EH GHOLYHUHG DORQJVLGH WKH RULJLQDO
LQJ
WKH
FRPELQLQJ
UHIOHFWLRQ
WR
SURYLGH
LV
D
QHQW
SUR
)LUVW WKH VSHFLIL
DQRWKHU
FRPSRQHQW
XQGHUO\LQJ
QH[W
WR
LVVXH
VXSSRUW
WR
IDFH
WKURXJK
LV
WKH
WKLV
TXHVWLRQ
LQWHUIDFH
RI
$V
ZKDW
LV
GDWD
DQGRU
WUDGLWLRQDO
ZLWK
UHIOHFWLRQ WKH FRPSRQHQW LQIRUPDWLRQ ZH DUH FRQFHUQHG ZLWK KHUH
WKDW
LV
)XUWKHU UDWKHU WKDQ SODF
WKH
WKH
VHUYLFHV
PHWDGDWD
WUXO\
FRPSRQHQW
FRPSRQHQW
DQG
LQ
KRZ
WKH
LW
VHQVH
WKDW
EHKDYHV
LQ
LW
GHVFULEHV
FRQWUDVW
FRPSRQHQW FRPSXWHV ZLWK RU WUDQVIRUPV
VXFK D ZUDSSHU LVRODWHV WKHVH IHDWXUHV LQ D VHSDUDWH OD\HU EHWZHHQ
WR
WKH
WKH
QDWXUH
GDWD
RI
WKH
WKDW
WKH
%XW H[DFWO\ ZKDW PHWD
GDWD RU LQWHUFHVVRU\ VHUYLFHV VKRXOG EH VXSSRUWHG"
WKH FRPSRQHQW DQG LWV FOLHQWV ZKLFK QRZ PD\ LQFOXGH D KRVW RI
GHYHORSPHQW
WRROV
LQ
DGGLWLRQ
WR
RWKHU
DSSOLFDWLRQ
FRGH
$&RPSRQHQW¶V)RUPDO6SHFLILFDWLRQ
7KLV
DSSURDFK ZKLFK LV PRUH LQOLQH ZLWK REMHFWRULHQWHG GHVLJQ VHSD
7KH PRVW REYLRXV PHWDGDWD WR SURYLGH LV VRPH UHSUHVHQWDWLRQ RI D
UDWHV
WKH
DGGHG
IHDWXUHV
IURP
WKH
XQGHUO\LQJ
FRGH
LQ
D
ZD\
WKDW
FRPSRQHQW¶V IRUPDO VSHFLILFDWLRQ
-XVW DV D FRQYHQWLRQDO PHWDRE
FDQ EH PDGH FRPSOHWHO\ WUDQVSDUHQW WR WKH UHPDLQGHU RI WKH DSSOL
MHFW SURWRFRO SURYLGHV LQWURVSHFWLYH DFFHVV WR DQ REMHFW¶V FODVV LWV
FDWLRQ WKDW VXSSRUWV HDV\ LQVHUWLRQ RU UHPRYDO RI WKH DGGHG FDSD
PHWKRGV
ELOLWLHV
DQG
WKDW
QDWXUDOO\
ILWV
ZLWK
FRQYHQWLRQDO
FRPSRQHQW
DQG
LWV
SURYLGH
LQWURVSHFWLYH
WULEXWLRQ WHFKQLTXHV
PDOO\ VSHFLILHG
3ODFLQJ
VSHFLILFDWLRQRULHQWHG
UHIOHFWLRQ
IHDWXUHV
LQ
D
ILHOGV
D
UHIOHFWLYH
VSHFLILFDWLRQ
ZUDSSHU
VKRXOG
GLV
DFFHVV
WR
DOO
DVSHFWV
H[SRUWHG LQWHUIDFH
RI
D
FRPSRQHQW¶V
IRU
7KLV LV WKH UROH RI WKH VSHFL
ILFDWLRQ REMHFWV LQWURGXFHG LQ 6HFWLRQ VHSDUDWH
FODVV RU FRPSRQHQW LV D VLPSOH LGHD EXW LW UHIRFXVHV DWWHQWLRQ ZLWK
)RU D PRGHOEDVHG FRPSRQHQW VSHFLILFDWLRQ >@ WKH VSHFLILFDWLRQ
GUDPDWLF UHVXOWV
,W HOHYDWHV WKH UHIOHFWLRQ IHDWXUHV IURP WKH OHYHO
REMHFW FRXOG SURYLGH DFFHVV WR WKH REMHFW¶V
RI RQH RU WZR PHWKRGV LQ D FRPSRQHQW LQWHUIDFH XS WR WKH OHYHO RI
D
VHSDUDWHO\
XVHIXO
FRPSRQHQW
DEVWUDFWLRQ
7KLV
HOHYDWLRQ
VKLIWV
REMHFW¶V
DWWHQWLRQ
WR
WKH
TXHVWLRQ
RI
H[DFWO\
ZKDW
³PHWD´
GDWD
RU
DEVWUDFW PRGHO
SUH DQG SRVWFRQGLWLRQ IRU HDFK RSHUDWLRQ
DEVWUDFW LQYDULDQW
,I
DQ
WR WKH
RU PHWKRG DQG WR WKH
DOJHEUDLF
VSHFLILFDWLRQ
DS
VHUYLFHV
SURDFK
ZHUH
XVHG
DFFHVV
ZRXOG
LQVWHDG
EH
RULHQWHG
WRZDUG
D[L
VKRXOG EH SURYLGHG E\ D UHIOHFWLYH VSHFLILFDWLRQ ZUDSSHU
RPV DQG DOJHEUDV
6XPPDUL]LQJWKH3URSRVHG6ROXWLRQ
VSHFLILFDWLRQV VXFK DV LQKHULWDQFH SHUKDSV DOVR QHHG EH FRQVLG
7KH SRVLWLRQ HVSRXVHG LQ WKLV SDSHU LV WKDW D FRPSRQHQW¶V VSHFLIL
HUHG
FDWLRQ
DQG
RWKHU
VXSSRUWLQJ
LQIRUPDWLRQ
VKRXOG
EH
SURYLGHG
%H\RQG WKH EDVLFV DFFHVV WR SXEOLFO\ DYDLODEOH
ILHOGV RU SURSHUWLHV H[FHSWLRQ EHKDYLRU DQG UHODWLRQVKLSV WR RWKHU
DV
16
+RZHYHU
DV
FRPSRQHQW
QHQW
LV
D
6]\SHUVNL
WKDQ
XQLW
MXVW
RI
QRWHV
DQ
LQ
KLV
H[SRUWHG
FRPSRVLWLRQ
GHILQLWLRQ
LQWHUIDFH
ZLWK
WKHUH
³$
FRQWUDFWXDOO\
WKDW
LV
DOVR
LQ
VKDUHG
DGGLWLRQ
VKRXOG
DOVR
E\
WR
WKH
SURYLGH
SRUWHG LQWHUIDFH
WKH
&
H[SRUWHG
LV
WKH
FRQWUDFW
LQWHUIDFH
EHWZHHQ
IRUPV
WKH
D
>@
$V
LQWHUIDFH
LQWURVSHFWLYH
WKDW
SODFHV RQ LWV HQYLURQPHQW
WKH
PRGHO
DFFHVV
H[SOLFLW
D
D
WR
PRUH
LW
UHIOHFWLYH
D
D
LQWHU
7KLV SHUVSHF
UHVXOW
LV
FRQWUDFWV
DQG
LWV
EHWZHHQ
FOLHQW
D
WKH
LP
DQG
5HSUHVHQWDWLRQ LQYDULDQW FKHFNV
XVHIXO
DQG
PDO
DQG
H[SRUW
FRPHV
WR
LQWHUIDFHV
VSHFLILFDWLRQ
LQWHUIDFH
WR
D
LQIRUPDWLRQ
2Q
VHSDUDWH
DQG
VHHPV
SDFNDJLQJ
WKH
DQG
RWKHU
KDQG
FRPSRQHQW
VHUYLFHV
WKDW
OLNH
WKH
EXON
GLVWULEXWLQJ
FDQ
RI
WKH
WKH
DWWHQWLRQ
SURYLGHG
RQ
WKH
WKURXJK
RWKHU
VXFK
RQH¶V
LQLWLDO
FRQFHUQ
LQIRUPDWLRQ
YHULILHG"
ZLOO
%\
ZLOO
SURRI
RU
SURRI
DOVR
KDQG"
FKHFNLQJ XVHG LQVWHDG"
GXULQJ
FKHFNLQJ
XVHIXO
@
DXWKRU
>
@
WR
ZKLOH
FRPSRQHQW
FDQ
DOVR
EH
DQG
FROOHDJXHV
3RVWFRQGLWLRQ
WKH
FRPSRQHQW
SUHFRQGLWLRQ
LQWHJUDWLRQ
XVHIXO
WR
>@
DQG
LQ
SURYLGHU
FKHFNV
DUH
3RVWFRQGLWLRQ
WKH
FOLHQW
LQ
GHIHFW
WR
EH
HQDEOHG
RU
GLVDEOHG
SHUKDSV
RQ
D
SHURSHUDWLRQ
6LPLODUO\ D FRPSRQHQW PLJKW HYHQ RIIHU GLIIHUHQW OHYHOV RI
VORZ
DQ
EXW
WKDW
FKHFNV
WHGLRXVO\
SURYLGHV
LW
FDQ
D
WKRURXJK
V\VWHPDWLF
SURYLGH
DV
ZHOO
FKHFNV
ZD\
DV
WR
IRU
H[DPSOH
TXHU\
HQDEOH
RU
WKH
$Q
ZUDSSHU
GLVDEOH
WKHP
LQWHU
IRU
DW
WKH
GHVLJ
QDWHG OHYHOV ZRXOG DOORZ FRPSRQHQW FRPSRVLWLRQ HQYLURQPHQWV WR
QHFHVVDULO\
EH
ZLWK
6HOI7HVWLQJ6HUYLFHV
GLVWULEXWLQJ
&RPSRQHQWEDVHG
EH
XVHIXO
:LWK
WRRO
:DV
D
FRPSRQHQW
DVVLVWDQFH"
:DV
IRU
DYDLODEOH"
8SRQ
ZKDW
EHIRUH
WLRQ
PDNLQJ
D
SXUFKDVLQJ
UHDVRQLQJ
SURSHUW\
>@
LV
HQVXUHG
E\
FULWLFDO
GHFLVLRQ
DOO
GHWDLOV E\ WKH FOLHQW DIWHU SXUFKDVH
YHULILFDWLRQ
WLRQOHYHO
GHWDLOV
YHULILFDWLRQ
RI
DUH
LPSRUWDQW
LQ
VXSSRUWLQJ
FRPSRVLWLRQV
FRPSR
LQ
VHUYLFHV
DGGUHVV
YHULILFDWLRQ
VXSSRUWLQJ
EXW
DQ
VRPH
DVSHFWV
DGGLWLRQDO
DSSOLFDWLRQ
RI
WHVWLQJ
GHYHORS
9LROD
WHVWLQJEDVHG
VXSSRUW
LQ
WKH
FDQ
EH
SURFHVV
RI
,W LV SRVVLEOH IRU D UHIOHFWLYH ZUDSSHU WR SURYLGH VHOIWHVWLQJ FDSD
ELOLWLHV LQ DGGLWLRQ WR YLRODWLRQ FKHFNLQJ VHUYLFHV
)RU H[DPSOH D
VHOHFWLRQ RI FRPSRQHQW GHYHORSHUSURYLGHG WHVW VXLWHV IURP VKRUW
DSSOLFD
)XUWKHU
,QWHU
YHULI\LQJ DQ DSSOLFDWLRQ LQ FRPELQDWLRQ ZLWK D FRPSRQHQW
+RZHYHU ZLWKRXW ORFDO FHUWL
FRPSRQHQW
FKHFNLQJ
FRPSRQHQW
,Q PDQ\ FDVHV WKLV LQIRUPDWLRQ
FRPSRQHQW
QHQWV LQ DQ DSSOLFDWLRQ WKHUH ZRXOG EH OLWWOH QHHG IRU YHULILFDWLRQ
ILDELOLW\
,Q DQ LQYLWHG SDSHU DW WKH LGHQWLILHG WHVWLQJ WHFKQLTXHV IRU FRPSRQHQWEDVHG V\VWHPV DV RQH
)XUWKHU LQ WKH LGHDO VLWXDWLRQ ZKHUH ORFDO FHUWLILDELOLW\ DOVR FDOOHG
PRGXODU
KLJKOLJKW
RI WKH IXQGDPHQWDO UHVHDUFK DUHDV ULSH IRU H[SORUDWLRQ >@
LV FOHDUO\ RI LQWHUHVW WR WKH FOLHQW
XVHIXO
FRQVWUXFWLRQ
ODLG RXW D URDGPDS IRU WKH IXWXUH RI VRIWZDUH WHVWLQJ UHVHDUFK DQG
LV
7KH H[WHQW DQG TXDOLW\ RI YHULILFDWLRQ SHUIRUPHG RQ D FRPSRQHQW
PRVW
VRIWZDUH
QDWLRQDO &RQIHUHQFH RQ 6RIWZDUH (QJLQHHULQJ 0DU\ -HDQ +DUUROG
,V
DVVXPSWLRQV
WR
QG
QLFDWLRQ DPRQJ FRPSRQHQWV
PRGHO
2U ZDV D WHVWLQJEDVHG DSSURDFK XVHG"
IUDJPHQW
DSSURDFKHV
WKH QHHG IRU GHWHFWLQJ IDLOXUHV WKDW DULVH DV D UHVXOW RI PLVFRPPX
WKH YHULILFDWLRQ EDVHG"
WKH
H[WUHPHO\
>
WKH
GLUHFWO\ VXSSRUW VXFK VHUYLFHV LQ D XQLIRUP ZD\
ILFDWLRQ
LV
FKHFNV
IDFH
VSHFLILFDWLRQ LQIRUPDWLRQ LQ WKH ORQJ WHUP FRQVLGHUDWLRQ RI YHUL
D
FOLHQW
LQYDULDQW
VXV
UHIOHFWLRQ
$&RPSRQHQW¶V9HULILFDWLRQ+LVWRU\
PDOO\
WKH
E\
VXFFHVV
FKHFNLQJ IRU VRPH FRQGLWLRQV²IDVW EXW OHVV ULJRURXV FKHFNV YHU
IRU
REMHFW
:KLOH
DUH
GHYHORSPHQW
WR
EDVLV
SUREOHP
FRPSRQHQW¶V
HOHYDWLQJ
IRFXVHV
EH
D
FKHFNLQJ
SURSRVHG
VRPH
$ FDUHIXOO\ GHVLJQHG UHIOHFWLYH ZUDSSHU FRXOG DOORZ HDFK FDWHJRU\
RI
LW
ZLWK
WKH
7DNHQ WRJHWKHU SURYLGLQJ SURJUDPOHYHO DFFHVV WR D FRPSRQHQW¶V
ZKHQ
RULJLQDOO\
XVHG
ORFDOL]DWLRQ GXULQJ DSSOLFDWLRQ WHVWLQJ
RWKHU ORZHUOHYHO FRPSRQHQWV RQ ZKLFK LW LV EXLOW
LPSRUW
LGHD
EHHQ
GXULQJ
LW
LPSRUWHG
FRPSRQHQW
x
YDULDQW
:KLOH WKH H[SRUWHG LQWHUIDFH FDSWXUHV
FRPSRQHQW
$EVWUDFW LQYDULDQW FKHFNV
KDV
ZUDSSHU
GHSHQGHQFLHV
x
7KLV
FOHDU
FRPSRQHQW¶V
FRQWH[W
WR
FRPSR
VSHFLILHG
IDFHV DQG H[SOLFLW FRQWH[W GHSHQGHQFLHV RQO\´ >@
WLYH
LV
VRIWZDUH
DQG VLPSOH WR ORQJ DQG WKRURXJK FRXOG EH HPERGLHG LQ WKH UHIOHF
LI
WLYH
IRUPDO YHULILFDWLRQ LV QRW XVHG V\VWHPDWLFDOO\ WKURXJKRXW DQ DSSOL
ZUDSSHU
6HOIWHVWLQJ
FDQ
WKHQ
EH
SHUIRUPHG
E\
H[HFXWLQJ
D
VHOHFWHG WHVW VXLWH RQ WKH ZUDSSHG FRPSRQHQW²SHUKDSV ZKLOH DOVR
FDWLRQ FRPSRQHQWOHYHO YHULILFDWLRQ LQIRUPDWLRQ PD\ EH XVHIXO LQ
HQDEOLQJ LQWHUIDFH YLRODWLRQ FKHFNLQJ
ORFDOL]LQJ GHIHFWV GXULQJ WHVWLQJ
6XFK D WHVWLQJ DSSURDFK SURYLGHV D QDWXUDO LQFUHPHQWDO DSSURDFK
9LRODWLRQ&KHFNLQJ6HUYLFHV
WR
SHUVSHFWLYHV
>@
RI
WKH
FRPSRQHQWSURYLGHU
DQG
WKH
SRQHQWXVHU
RQ
WKH
RWKHU
KDQG
PXVW
DOVR
EH
FRPHV
ZLWK
WKH
WLRQ
ELQDWLRQ ZLWK WKH FRPSRQHQW
DSSURDFK
WR
DGGUHVVLQJ
FRQWUDFWV IRU YLRODWLRQV
VSHFLILFDWLRQ
DQG
GDWD
,I
DQG
HDFK
ZLWK
FRPSRQHQW
YLRODWLRQ
FRPHV
FKHFNLQJ
SUH
VHUYLFHV
DQ
LGHDO
³UHDO
ZRUOG´
WHVW
IRU
WKH
ORZHUOHYHO
FRPSRQHQWV
6XFK DQ DSSURDFK FRXOG HYHQ EH H[SDQGHG WR VXSSRUW WKH LQWHJUD
VHUYLFHV DQG LQIRUPDWLRQ QHFHVVDU\ WR WHVW KHU DSSOLFDWLRQ LQ FRP
2QH
LQWHJUDWLRQ
WHVW
RQ ZKLFK LW GHSHQGV
7KH FRP
SURYLGHG
ZLWK
DFWLQJ LQ WKH UROH RI WHVW RUDFOH D FRPSRQHQW¶V RZQ VHOIWHVW EH
FRPSRQHQWXVHU
,W LV LPSRUWDQW WR SURYLGH SRZHUIXO FDSDELOLWLHV IRU HVWDEOLVK
LQJ D FRPSRQHQW¶V TXDOLW\ WR WKH FRPSRQHQWSURYLGHU
DSSOLFDWLRQ
SDFNDJHG
&RPSRQHQWEDVHG GHYHORSPHQW KLJKOLJKWV WKH GLIIHULQJ QHHGV DQG
RI
FOLHQWZULWWHQ
WHVW
VXLWHV
LQWR
WKH
VHOIWHVWLQJ
VFKHPH
%UXFH :HLGH KDV DOVR VXJJHVWHG WKDW VXFK D ZUDSSHU FRXOG SRWHQ
ERWK
FRQFHUQV
LV
FKHFNLQJ
WLDOO\
LQWHUIDFH
YHULILFDWLRQ
LQIRUPDWLRQ
D
UHIOHFWLYH
EH
DXJPHQWHG
WR
SURYLGH
RSHUDWLRQ
FDOOSDUDPHWHU
UHFRUG
DQG SOD\EDFN FDSDELOLWLHV >@
,Q DGGLWLRQ WR VLPSO\ SURYLGLQJ DFFHVV WR
ZUDSSHU
$W WKLV SRLQW WKH EHQHILW RI LQWHUFHVVRU\ VHUYLFHV IURP WKH SRLQW RI
FDQ
DOVR
SURYLGH
FRQWUDFW
FKHFNLQJ IHDWXUHV
%HFDXVH RI WKH ZD\
YLHZ
RI
DWHO\
VWUXFWXUHG
FRPSRQHQW
VSHFLILFDWLRQV
EHFRPHV
FOHDU
$Q
DSSURSUL
WKH ZUDSSHU LV LQWHUSRVHG EHWZHHQ WKH FOLHQW DQG WKH FRPSRQHQW LW
UHIOHFWLYH
ZUDSSHU
FDQ
SURYLGH
IRU
FKDQJHV
LQ
LWV
LV HDV\ WR DGG DQ\ RU DOO RI WKH IROORZLQJ UXQWLPH FKHFNV
RZQ
x
x
EHKDYLRU²LW
WLRQV
3UHFRQGLWLRQ FKHFNV
WKH
3RVWFRQGLWLRQ FKHFNV
WKDW
RFFXU
ZUDSSHG
FDQ
DOORZ
RQH
LPPHGLDWHO\
LPSOHPHQWDWLRQ
WR
HQDEOH
EHIRUH
RU
RU
DIWHU
$OWKRXJK
GLVDEOH
LW
WKLV
VSHFLILF DF
GHOHJDWHV
FDOOV
GRHV
VXSSRUW
QRW
WR
LQWHUFHVVRU\ DFWLRQV RQ WKH XQGHUO\LQJ FRPSRQHQW VLPSO\ DGGLQJ
RU
17
UHPRYLQJ
FHUWDLQ
DFWLRQV
EHIRUH
DQG
DIWHU
GHOHJDWLQJ
WR
WKH
/,0,7$7,216
ZUDSSHG FRPSRQHQW VXSSRUWV PDQ\ SRZHUIXO FDSDELOLWLHV RULHQWHG
WRZDUG FRPSRQHQW FRPSRVLWLRQ DQG WHVWLQJEDVHG YHULILFDWLRQ
7KHUH DUH D QXPEHU RI GUDZEDFNV WR H[SORUH ZKHQ FRQVLGHULQJ WKH
$EVWUDFW9DOXH0DQLSXODWLRQ
7KH
FRPSRQHQW
ZUDSSLQJ
VFKHPH
SUHYLRXVO\
ZUDSSHU DSSURDFK SURSRVHG KHUH
SURSRVHG
IRU
LQWHU
HDFK FRPSRQHQW ZRXOG QRZ EH DFFRPSDQLHG E\ RQH RU PRUH VXS
IDFH YLRODWLRQ FKHFNLQJ >@ XVHV D QRYHO DSSURDFK WR LPSOHPHQWLQJ
FKHFNV
FKHFNV
EHIRUH
LQ
DQG
WHUPV
XQGHUO\LQJ
RI
DIWHU
WKH
RSHUDWLRQV
FRQFUHWH
FRPSRQHQW
DQG
,QVWHDG
RI
LPSOHPHQWDWLRQ
WKXV
YLRODWLQJ
SOHPHQWDU\ FODVVHV WR SURYLGH LWV ZUDSSHU WHVWLQJ VXSSRUW DEVWUDFW
LPSOHPHQWLQJ
YDOXHV
YDOXH PDQLSXODWLRQ DQG RWKHU VHUYLFHV
LQVLGH WKH
HQFDSVXODWLRQ
DEVWUDFWLRQ
FODVVHV
WKDW
IXQFWLRQ
RU
FRUUHVSRQG
DEVWUDFWLRQ
WR
WKH
UHODWLRQ
YDULRXV
WKH
WKH
OHYHO
FRPSRQHQW
YDOXHV
7KH
DUH
XVHG
UHVXOW
LV
WR
UHSUHVHQW
WKDW
WKH
DEVWUDFW
ZUDSSHU
ZKHQ
VSHFLILFDWLRQ
LQIRUPDWLRQ
DERXW
FRP
SRQHQWV LV PRVW YDOXDEOH UDWKHU WKDQ DIWHU GHOLYHU\ ZKHQ FRPSR
QHQW VSHFLILFDWLRQV DUH RI OLWWOH RU QR XVH WR WKH HQG XVHU
PRGHOLQJ
WKHVH
W\SHV XVHG LQ GHILQLQJ WKH VWDWH PRGHO DQG SUH DQG SRVWFRQGLWLRQV
IRU
GHYHORSPHQW
GXULQJ
3URJUDPOHYHO
PDWKHPDWLFDO
7KH FULWLFDO DVSHFW RI WKH
ZUDSSHU DSSURDFK LV WKDW DOO RI WKHVH VHUYLFHV DUH GHVLJQHG IRU XVH
FRPSRQHQW LV UHTXLUHG WR SURYLGH WKH FRPSXWDWLRQDO HTXLYDOHQW RI
DQ
2QH LPPHGLDWH FRQFHUQ LV WKDW
WKLV DSSURDFK PD\ OHDG WR FRGH EORDW LQ WKH ILQDO DSSOLFDWLRQ VLQFH
DGGLWLRQDO
VHUYLFHV
ZUDS
WKH
XQGHUO\LQJ
%HFDXVH
FRPSRQHQW
GXULQJ
GHYHORSPHQW LW LV D VLPSOH PDWWHU WR UHPRYH WKHP IRU ILQDO UHOHDVH
VSHFLILFDWLRQ
EXLOGV ZLWKRXW UHTXLULQJ DFFHVV WR WKH FRPSRQHQW¶V VRXUFH FRGH
DVNV WKH FRPSRQHQW
$QRWKHU
FRQFHUQ
EO\
WR
LV
ZKHWKHU RU QRW WKLV DSSURDFK ZLOO GHPRQVWUD
WR ³SURMHFW´ DQ DEVWUDFW YDOXH RI LWV FXUUHQW VWDWH DV D VHSDUDWH RE
MHFW
OHDG
EHWWHU
TXDOLW\
FRPSRQHQWV
+RZHYHU
WKH
SRVLWLRQ
LQ
$OO FKHFNLQJ DQG DQDO\VLV LV WKHQ GRQH RQ WKLV REMHFW ZKLFK
WKLV
SDSHU
LV
WKDW
UHIOHFWLYH
ZUDSSHUV
DUH
GHVLJQHG
WR
SURYLGH
D
LV GHVLJQHG WR PLPLF WKH FRUUHVSRQGLQJ PDWKHPDWLFDO DEVWUDFWLRQ
PHFKDQLVP WR GHOLYHU DQG ODWHU DFFHVV D FRPSRQHQW¶V VSHFLILFDWLRQ
7KLV DEVWUDFWLRQ UHODWLRQ DSSURDFK FDQ EH FRRSWHG IRU D UHIOHFWLYH
SDUWLFXODUO\ E\ GHYHORSPHQW WRROV
VSHFLILFDWLRQ
HVVDU\ WR DOORZ GHYHORSHUV RI FRPSRQHQWEDVHG VRIWZDUH WR OHYHU
WLHV
,I
EDVHG
D
ZUDSSHU
WR
FRPSRQHQW
SURMHFWLRQ
FRUUHVSRQGLQJ
SURYLGH
ZHUH
WR
IXQFWLRQ
DGGLWLRQDO
SURYLGH
LQWHUFHVVRU\
ERWK
DQ
FDSDELOL
DEVWUDFWUHODWLRQ
³FRQYHUWWRDEVWUDFWPRGHO´
LQMHFWLRQ
IXQFWLRQ
DQG
DJH
D
³FRQYHUWIURPDEVWUDFW
WR
PRGHO´ WKHQ LW ZRXOG EH SRVVLEOH IRU D GHYHORSPHQW HQYLURQPHQW
RU
RWKHU
WRRO
RI
WR
GLUHFWO\
DFFHVV
VWDWH
D
WKH
RI
DQG
PDQLSXODWH
FRPSRQHQW
DQ
)XUWKHU
DEVWUDFW
IRUPDO
VKRXOG
WKH
VSHFLILFDWLRQV
FUHDWHG
E\
FRPSRQHQW
GHYHORSHUV
QRW PDNH WKH PLVWDNH RI SUHVXPLQJ WKDW DQ\ VROXWLRQ
VSHFLILFDWLRQ
SDFNDJLQJ
DQG
GLVWULEXWLRQ
SUREOHP
DEVWUDFW
UHSUHVHQWDWLRQ
FRXOG
WKHQ
EH
³SXPSHG
EDFN
PRUH
VLJQLILFDQW
FRQFHUQ
LV
WKH
TXHVWLRQ
RI
KRZ
VSHFLILFDWLRQV
RI
WKH
FRPSRQHQW
LWVHOI
7KLV
DSSURDFK
ZRUNV
QDWXUDOO\
UHSUHVHQWDWLRQ
ZKHUH
WKH
DEVWUDFWLRQ
UHODWLRQ
LV
D
RQHWRRQH
RI
VSHFLILFDWLRQ
IHDWXUHV
LV
QHFHVVDU\
IRU
IRU WKLV VWUDWHJ\ WR ZRUN
FRPSRQHQWV
$ SURJUDP
GRZQ´
PDQLSXODEOH
LQWR
E\
UHSUH
PDQLSXODWLRQV
ZLOO EH FRPPXQLFDWHG WKURXJK WKH ZUDSSHU LQWHUIDFH
WKDW
ZLOO
LWVHOI EH VXIILFLHQW WR JXDUDQWHH DQ LQFUHDVH LQ VRIWZDUH TXDOLW\
$
VHQWDWLRQ
WKH
2QH
6ROYLQJ WKLV SUREOHP LV QHF
2QH SRVVLELOLW\ LV WR XVH WKH ([WHQVLEOH
PDS
0DUNXS /DQJXDJH ;0/ >@ WR UHSUHVHQW VSHFLILFDWLRQ LQIRUPD
SLQJ
)RU
PDQ\WRRQH
RU
PDQ\WRPDQ\
PDSSLQJV
IURP
UHSUH
WLRQ ZKLFK ZRXOG UHTXLUH WKH GHYHORSPHQW RI RQH RU PRUH DSSUR
VHQWDWLRQV
WR
DEVWUDFW
YDOXHV
SUDFWLFDO
FRQYHUWIURPDEVWUDFW
SULDWH 'RFXPHQW 7\SH 'HILQLWLRQV '7'V
PRGHO
LQMHFWLRQ
IXQFWLRQV
DUH
QRW
DOZD\V
SRVVLEOH
DQG
VR
VXFK
6XFK D UHSUHVHQWDWLRQ
D
PXVW EH JHQHUDOO\ DFFHSWDEOH LQ RUGHU IRU WRROV WR VXSSRUW LW
,W LV
IHDWXUH FDQQRW EH UHTXLUHG IRU DOO UHIOHFWLYH ZUDSSHUV
GLIILFXOW
LPSDFW
LV
LQ
GHYHORSPHQW
VWDQGDUG
WKH
OLNHO\
FRQWH[W
WR
DQG
IRU
FRPSRQHQWEDVHG
IURP
HQYLURQPHQW
LQWHUIDFH
SURWRW\SLQJ
RI
DFFUXH
$OO
SOXJJLQJ
WHVWLQJ
XVLQJ
XVH
VXFK
D
FRPSRQHQWV
LQWR
DQG
VWDWH
IRU
VRIWZDUH
FDSDELOLW\
ZRXOG
QRZ
YLVXDOL]DWLRQ
LQWHUIDFLQJ
KDYH
WRROV
ZLWK
,QVWHDG
JUHDWHU
ZLWKLQ
LPDJLQH
WKDW
RQH
UHSUHVHQWDWLRQ
FRXOG
ZRUN
IRU
WKH
P\ULDG RI VSHFLILFDWLRQ DSSURDFKHV DQG QRWDWLRQV DYDLODEOH WRGD\
:KLOH VXFK DQ LQWHUIDFH FDQ EH XVHG IRU FHUWDLQ NLQGV RI PHWDSUR
JUDPPLQJ
WR
VXFK
D
UHSUHVHQWDWLRQ
ZRXOG
PRVW
OLNHO\
UHTXLUH
GLIILFXOW
FKRLFHV DERXW WKH VSHFLILFDWLRQ DSSURDFK WR EH XVHG
D
D
)LQDOO\
IRU
LW
LV
FOHDU
WKDW
SDFNDJLQJ
DQG
GHOLYHU\
RI
VSHFLILFDWLRQV
XVLQJ WKH ZUDSSHU DSSURDFK ZLOO UHTXLUH DGGLWLRQDO ZRUN E\ FRP
PRGHO
SRQHQW
FKHFNLQJ WRROV
GHYHORSHUV
FDWLRQV
PDQ\
'RFXPHQWDWLRQ"
DERYH DQG EH\RQG VLPSO\ FUHDWLQJ WKH VSHFLIL
*HQHUDWLRQ RI ZUDSSHU ERLOHUSODWH DQG LPSOHPHQWDWLRQ RI
ZUDSSHU
VHUYLFHV
LQFOXGLQJ
UHSUHVHQWLQJ
DQG
DFFHVVLQJ
VSHFLILFDWLRQ GHWDLOV FDQ EH DXWRPDWHG VR WKDW QR DGGLWLRQDO ZRUN
7R FRPH IXOO FLUFOH RQH FDQ DOVR FRQVLGHU LQFRUSRUDWLQJ SURJUDP
LV
OHYHO
DOO RI WKH IHDWXUHV GHVFULEHG LQ 6HFWLRQ ZLOO UHTXLUH VRPH PDQXDO
DFFHVV
LQWHUIDFH
WR
DV
FRPSRQHQW
RSSRVHG
WR
GRFXPHQWDWLRQ
SURYLGLQJ
WKURXJK WUDGLWLRQDO GRFXPHQWDWLRQ
GRFXPHQWDWLRQ
VWUDWHJLHV
SXVK
WKH
WKURXJK
D
VSHFLILFDWLRQ
UHIOHFWLYH
LQIRUPDWLRQ
HIIRUW
-DYD'RF DQG RWKHU HPEHGGHG
GRFXPHQWDWLRQ
GRZQ
LQWR
UHTXLUHG
RI
7KH
FRPSRQHQW
SULPDU\
GHYHORSHUV
VHUYLFHV
WKDW
+RZHYHU IXOO\ VXSSRUWLQJ
PD\
UHTXLUH
DGGLWLRQDO
GHYHO
RSHUVXSSOLHG FRGH DUH
WKH
x
VRXUFH FRGH LQ D ZD\ WKDW DOORZV WRROV WR H[WUDFW IRUPDW SDFNDJH
3UHFRQGLWLRQ
SRVWFRQGLWLRQ
DQG
LQYDULDQW
FKHFNV
IRU
YLROD
WLRQFKHFNLQJ VHUYLFHV
DQG
QDYLJDWH
FDQ
LPDJLQH
LW
fication()
DQG
IRU
IRU
WKH
KXPDQ
UHDGDELOLW\
VSHFLILFDWLRQ
SURYLGLQJ
SHUSDUDPHWHUOHYHO
FRPSLODWLRQ
LQWR
REMHFW
,Q
WKH
REWDLQHG
FRPSRQHQWOHYHO
GRFXPHQWDWLRQ
RQOLQH
VDPH
IURP
PDQQHU
FXUUHQW
ZLOO
EH
FRPSRQHQWV
QHHGHG
DFFHVVLEOH
IRU
LW
VRPH
VWULQJV
GRFXPHQWDWLRQ
GRFXPHQWDWLRQ
LV
OLNHO\
WKDW
SXUSRVHV
LQ
XVH
D
LQ
WKURXJK
D
SULQWHG
EXW
x
IRUP
D
VWDQGDUG
x
VXLWDEOH
FRPSRQHQW
LQWHUIDFH
SHUKDSV
HYHQ
FRQVWUXFWLRQ
RI
WHVW
VXLWHV
IRU
$EVWUDFW PRGHO SURMHFWLRQ DQG LQMHFWLRQ IXQFWLRQV WR VXSSRUW
DEVWUDFW YDOXH PDQLSXODWLRQ
7R PDNH WKLV DSSURDFK SUDFWLFDO LW LV FOHDU WKDW D ³VOLGLQJ VFDOH´ RI
ZUDSSHU IXQFWLRQDOLW\ ZKHUH D JLYHQ ZUDSSHU SURYLGHV RQO\ VRPH
SURJUDP
PD\
DQG
$V
GRFXPHQWDWLRQ
SURYLGLQJ
6HOHFWLRQ
VHOIWHVWLQJ VHUYLFHV
SHURSHUDWLRQOHYHO
SURSHUW\ EURZVHU RU XVH LQ D GRFXPHQWDWLRQ VHDUFK GDWDEDVH
ZLWK
RQH
GetSpeci-
VXEVHW
KDYH
DEOH
XQH[SORUHG EHQHILWV
RI
WKH
UHIOHFWLYH
&RPSRQHQW
VHUYLFHV
GHYHORSHUV
GHVFULEHG
ZKR
ZLVK
LQ
WR
6HFWLRQ
GHYRWH
WKH
LV
GHVLU
UHVRXUFHV
QHFHVVDU\ IRU LPSOHPHQWLQJ PRUH FRPSUHKHQVLYH ZUDSSHU IHDWXUHV
18
PLJKW
WKHQ
KDYH
DQ
DGYDQWDJH
LQ
FRPSHWLQJ
IRU
PRUH
IRU
GHPDQGLQJ
-DYD
SURJUDPV
$33
DOORZV
VHSDUDWHO\
GHILQHG
FKHFNLQJ
RS
FXVWRPHUV
HUDWLRQV WR EH FRPSLOHG LQWR RU RXW RI & FRGH IRU DVVHUWLRQ FKHFN
5(/$7(':25.
LQJ
7KH
ZUDSSHU
PDWLRQ
ZDV
EHKDYLRUDO
HQG
DSSURDFK
LQLWLDOO\
WR
SURYLGLQJ
LQVSLUHG
E\
D
DFFHVV
SULRU
WR
VSHFLILFDWLRQ
IUDPHZRUN
IRU
LQIRU
SHFW-
UXQWLPH
VSHFLILFDWLRQEDVHG
WHVWLQJ
>@
7KLV
SULRU
DV
VSHFLILFDWLRQEDVHG
WHVWLQJ
DQG
SDUDPHWHUL]HG
UH
PDQ\
%HFDXVH
RI
QR
OHYHO
RQH
WKHQ
LQWR
ZD\V
GLVWLQFWLRQ
DQG
WR
FUHDWH
FKRRVH
D
WKH
D
ZKHWKHU
LV
RU
YDOXHV
DW
WKH
LPSOHPHQWDWLRQ
VHSDUDWH
QRQFKHFNLQJ
$VSHFW-
EHWZHHQ
FRQFUHWH
DVSHFW
QRW
WR
FRQWDLQLQJ
ZHDYH
LPSOHPHQWDWLRQ
SKLORVRSKLFDOO\
DEVWUDFW
OHYHO
WKLV
DW
FORVHVW
FURVVFXWWLQJ
EXLOG
WR
$V
FKHFNLQJ
WLPH
WKH
,Q
DSSURDFK
DGYRFDWHG KHUH
SURJUDP
7KH
PLQJ
DQG
GHFLVLRQ
VHDUFK LV DOVR UHODWHG WR IRUPDO VSHFLILFDWLRQ DQG WR YHULILFDWLRQ DV
ZHOO
PDNHV
DOORZV
FRGH
FRQWUDFW FKHFNLQJ >@ DQG D ODUJHU VWUDWHJ\ IRU HQGWR
DXWRPDWHG
EXW
VSHFLILFDWLRQ
VHOIWHVWLQJ
FRQFHSWV
IROGHG
LQWR
WKH
UHIOHFWLYH
ZUDSSHUV SUR
WKH VZHHSLQJ QDWXUH RI WKH SRVLWLRQ DGYRFDWHG
SRVHG KHUH KDYH EHHQ PRVW KHDYLO\ LQIOXHQFHG E\ FXUUHQW UHVHDUFK
KHUH LW LV UHODWHG WR DQG KDV EHHQ LQIOXHQFHG E\ D ZLGH YDULHW\ RI
LQ DXWRPDWHG VSHFLILFDWLRQEDVHG WHVWLQJ >@
7KH LGHD RI SURYLG
H[LVWLQJ ZRUN DFURVV D VHOHFWLRQ RI WRSLFV LQ GHVLJQ SURJUDPPLQJ
LQJ
VHOIWHVWLQJ
FDSDELOLWLHV
WKURXJK
D
VWDQGDUG
LQWHUIDFH
LV
RU
DQG
WKH
ODQJXDJHV IRUPDO VSHFLILFDWLRQ WHVWLQJ DQG VRIWZDUH UHXVH
WKRJRQDO
5HIOHFWLRQ
KDV
D
\HDU
KLVWRU\
LQ
SURJUDPPLQJ
ODQJXDJHV
WR
WKH
DSSURDFKHV
XVHG
WR
JHQHUDWH
DSSURDFKHV XVHG WR DVVHVV FRUUHFWQHVV
>@
WHVW
VXLWHV
$V D UHVXOW YLUWXDOO\ DQ\
WHVWLQJ DSSURDFK FRXOG EH LQWHJUDWHG LQWR WKH ZUDSSHU VWUDWHJ\
DQG KDV EHHQ ZLGHO\ GLVFXVVHG DW 2236/$ DW WKH $QQXDO :RUN
VKRSV RQ 2EMHFW2ULHQWHG 5HIOHFWLRQ DQG 0HWDOHYHO $UFKLWHFWXUHV
6800$5<
DQG PRUH UHFHQWO\ DW WKH ,QWHUQDWLRQDO &RQIHUHQFH RQ 0HWD/HYHO
$UFKLWHFWXUHV
DQG
5HIOHFWLRQ
.LF]DOHV
KDV
SURYLGHG
RQH
RI
WKH
)RU
PRVW LQIOXHQWLDO GLVFXVVLRQV RI WKH VXEMHFW LQ WKH FRQWH[W RI &/26
>@
)HUEHU GHVFULEHG DOWHUQDWLYH DSSURDFKHV WR VXSSRUWLQJ FRP
SXWDWLRQDO
UHIOHFWLRQ
LQ
FODVVEDVHG
223/V
>@
7KH
SURSRVDO
FOLHQWV
WLRQV
ZLWK
LQ
WR
WKRVH
WKH
UHFHLYH
WKH
EHQHILWV
VSHFLILFDWLRQV
FRPSRQHQWV
PXVW
WKH\
SURYLGHG
EH
E\
IRUPDO
GLVWULEXWHG
GHVFULEH
7KH
WR
VSHFLILFD
FOLHQWV
GLVFXVVLRQ
DORQJ
SUHVHQWHG
KHUH H[SORUHV VRPH RI WKH LVVXHV VXUURXQGLQJ WKH TXHVWLRQ RI KRZ
WKLV SDSHU DGGV QRWKLQJ QHZ WR WKH UHDOP RI UHIOHFWLRQ²LQVWHDG LW
EHVW WR SDFNDJH DQG GHOLYHU VXFK VSHFLILFDWLRQ LQIRUPDWLRQ
DLPV WR WDNH ZKDW KDV EHHQ OHDUQHG DERXW UHIOHFWLRQ LQ WKH GHVLJQ
RI
REMHFWRULHQWHG
SUREOHP
ODQJXDJHV
SDFNDJLQJ
PDWLRQ
DQG
UHODWHG
SURDFK
SURSRVHG
DQG
DQG
VHUYLFHV
KHUH
UHDSSO\
SURYLGLQJ
LV
7KH
WKDW
WKRVH
DFFHVV
WR
SULPDU\
PDQ\
XVHIXO
LQVLJKWV
WR
D
VSHFLILFDWLRQ
GLIIHUHQFH
UHIOHFWLRQ
LQ
7KH
QHZ
WLRQ
LQIRU
WKH
VLPSO\
E\
XVLQJ
ZUDSSHUV
UHIOHFWLRQ FDQQRW RI FRXUVH
FDWLRQ
DQG
UHIOHFWLRQ
VSHFLILFDWLRQ
KDV
WHFKQLTXH
RU
DOWKRXJK
JHQHUDO
WLYH
FDSDELOLWLHV
7KLV
RQ
KRZ
IRFXVHG
WR
RQ
VSHFLI\
UHIOHFWLRQ
UHIOHFWLYH
DV
WDNHQ
RWKHU
LQ
SRVLWLRQ
ZUDSSHU
WKLV
SDSHU
VXSSRUWLQJ
VSHFLILFDWLRQ
LV
KXPDQRULHQWHG
FRPSXWDWLRQDO
3DVW ZRUN LQYROYLQJ IRUPDO VSHFLIL
SULPDULO\
DQG
DQRWKHU FRPSRQHQW
DS
FDQ EH SURYLGHG ZLWKLQ D IUDPHZRUN WKDW GRHV QRW VXSSRUW UHIOHF
WLRQ
SRVLWLRQ
WKDW
D
FRPSRQHQW¶V
VKRXOG
EH
VSHFLILFD
DV
SURYLGHG
RU VHW RI FRPSRQHQWV FRQVLVWLQJ RI D UHIOHF
ZUDSSHU
EDVHG
DQG
DSSURDFK
LV
LQIRUPDWLRQ
RQ
DQG
WKUHH
DVVRFLDWHG
LQVLJKWV
WRRORULHQWHG
FOHDQO\
DOORZV
VSHFLILFDWLRQ
UHIOHFWLRQ
DFFHVV
WKH
WR
DGGLWLRQ
REMHFWV
VXSSRUWV
ERWK
VSHFLILFDWLRQV
RI
LQWHUIDFH
D
IXQF
WLRQDOLW\ DQG RSHQV XS SRZHUIXO UHIOHFWLRQ FDSDELOLWLHV HYHQ ZKHQ
D
WKH XQGHUO\LQJ FRPSRQHQW WHFKQRORJ\ GRHV QRW VXSSRUW UHIOHFWLRQ
EHKDYLRU
DQG WKH ZKROH VFKHPH FDQ EH LPSOHPHQWHG LQ D PDQQHU WUDQVSDU
> @
HQW WR FOLHQW FRGH
:LWKLQ WKH UHXVH FRPPXQLW\ WKH LVVXH RI SURYLGLQJ SURJUDPOHYHO
DFFHVV
WR
VSHFLILFDWLRQ
IHDWXUHV
KDV
UHFHLYHG
OLWWOH
DWWHQWLRQ
*LYHQ
7KH
RI
IURP
WKH
³FRPSRQHQW
UHXVH
FHUWLILFDWLRQ´
FRPPXQLW\
>
SURYLGH
PXFK
LQVLJKW
@
LQWR
SHUV
/HVVRQV
ZKDW
SRVLWLRQ
FRXOG
SRWHQWLDOO\
FKHFNLQJ
NLQGV
QDWXUDOO\
WUDFW
LQJ
PHVKHV
>@
UXQWLPH
VXFK
YLRODWLRQ
$
ZLWK
%HUWUDQG
YLRODWLRQ
FKHFNLQJ
FKHFNV
RI
IURP
FKHFNLQJ
0H\HU¶V
FKHFNLQJ
VXFK
DSSURDFK
FRQWUDFWXDO
HLWKHU
RI
WKH
GHVFULEHG
YLHZ
ZUDSSHU
LV
RI
SDUWLHV
KHUH
GHVLJQ
LQWHQGHG
REOLJDWLRQV
E\
>@
FRGH
IURP
SURPRWLQJ
FRQFHUQV
DQG
LW
WR
DERXW
GHWUDFWLQJ
ZKLOH
ERWK
D
FOLHQW
VHSDUDWHO\
FOXWWHU
IURP
DOORZLQJ
WKH
RQH
WKH
WR
DQG
FRQ
WR
SURYLGH
ZKLOH
VHSDUDW
LQYROYHG
PDQDJHDEOH
H[SUHVVLRQ
IRFXV
HDVLO\
WKH
RI
RI
WKH
LQFOXGH
EDVH
7KH
7KLV
FRPSOH[
XQGHUO\LQJ
7KH
SRVLWLRQ
PHFKDQLVP
WLRQ
LQ
GUHVVHG
DGGUHVVHV
VHUYLFHV
FRQGLWLRQV
XVHG
DQG
WKLV
DUH
LQ
DSSURDFKHV
>@
WR
L&RQWUDFW
UXQWLPH
>@
DVVHUWLRQ
5RVHQEOXP¶V
FKHFNLQJ
LQFOXGH
$QQRWDWLRQ
3URFHVVRU $33 >@ DQG .LF]DOHV¶ $VSHFW- >@
:KLOH
SDSHU
DVVHUWLRQV
WXUHV
SKUDVHG
L&RQWUDFW
LQ
SURYLGHV
WHUPV
RI
VHUYLFHV
SXEOLFO\
VLPLODU
WR
RQH
PDQ\
H[SRUWHG
RI
VHUYLFHV
DEVWUDFW
FODVV
(LIIHO
RI
FDQ
RQO\
YDOXH
IRU
YLRODWLRQ
PDQLSXODWLRQ
WKH
FDSLWDOL]H
HQRXJK
RXWOLQHV
GHOLYHULQJ
RQH
SRVVLEOH
VSHFLILFDWLRQ
LQIRUPD
VHUYLFHV
VLJQLILFDQW
RQ
WKDW
DQG
UHVHDUFK
WKH
FDSDELOLWLHV
LVVXHV
ZUDSSHU
SURJUHVV
FDQ
IRUHPRVW
WKLV
UHSUHVHQWLQJ
UHVHDUFK
VSHFLILFDWLRQ
³SODLQ
LVVXH
IHDWXUHV
PXVW
ROG
EH
IHD
WKDW
VSHFLILFDWLRQ
EXW
19
DG
DSSURDFK
WKH
PDGH
VSHFLILFDWLRQV´
VROYHG
IRU
WKH
LQFUH
RQH
LV
QHFHVVDU\
DQG
HV
IRU
WKLV
VWUDWHJ\
DQG
WR
ZRUN²
6XFK D UHSUHVHQWDWLRQ PXVW EH JHQ
UHSUHVHQWDWLRQ
DSSURDFKHV
)LUVW
SRVLWLRQ
$ SURJUDPPDQLSXODEOH UHSUHVHQWDWLRQ
HUDOO\ DFFHSWDEOH LQ RUGHU IRU WRROV WR VXSSRUW LW
LPDJLQH
VXJ
EH
EH
WR
1HYHUWKHOHVV WKH FRUQHUVWRQH RI WKH DSSURDFK LQYROYHV
DQG
SHUKDSV RQH EDVHG RQ ;0/
(LIIHO VXSSRUWV
WKRVH
SURYLGH
SDSHU
DQG
UHTXLUH
RUWKRJRQDO
FDSWXULQJ
RI
3UH
FRPSLOHUJHQHUDWHG UXQWLPH FKHFNV EDVHG RQ XVHUSURYLGHG %RR
OHDQ
WR
HYHQ
WKLV
SRXVHG KHUH WR EH YLDEOH
(LIIHO
VHU
,Q DGGL
$OWKRXJK VXFK UHIOHFWLYH VSHFLILFDWLRQ ZUDS
SDFNDJLQJ
EHIRUH
PHQWDOO\
LPSOHPHQWDWLRQ
RU H[FOXGH FKHFNV RQ D SHU
WDNHQ
IRU
KRZHYHU
JHVWHG
DQG
FRPSRQHQW EDVLV LQ D SOXJDQGSOD\ IDVKLRQ
$OWHUQDWLYH
LQWHUFHVVRU\
SRWHQWLDO GHVHUYHV IXUWKHU LQYHVWLJDWLRQ
YDOXH
FRPSRQHQW
FODVV
PRUH
DQG
SHUV KDYH QRW EHHQ LPSOHPHQWHG LQ WKH IRUP SURSRVHG KHUH WKHLU
DGGHG E\ WKH ZUDSSHU DSSURDFK UHVXOWV IURP VHSDUDWLQJ WKH FKHFN
LQJ
EH
VHOIWHVWLQJ
D UHIOHFWLYH ZUDSSHU
LQWHUIDFH
LQWURVSHFWLYH
(YHQ GRFXPHQWDWLRQ FRXOG EH DFFHVVHG SURJUDPPDWLFDOO\ WKURXJK
RI LQIRUPDWLRQ PD\ EH XVHIXO WR FOLHQWV LQ WKLV UHJDUG
7KH
SRWHQWLDO
WLRQ WR VSHFLILFDWLRQ DQG YHULILFDWLRQ LQIRUPDWLRQ UHIOHFWLYH ZUDS
YHULILFDWLRQ KLVWRU\ KRZHYHU KDV EHHQ GLVFXVVHG ZLGHO\ XQGHU WKH
WRSLF
WKLV
YLFHV IRU UHIOHFWLYH VSHFLILFDWLRQ ZUDSSHUV ZHUH H[SORUHG
TXHVWLRQ RI KRZ DQG ZKDW WR GHVFULEH LQ UHODWLRQ WR D FRPSRQHQW¶V
FRXOG
QRWDWLRQV
ZRUN
,W LV GLIILFXOW WR
IRU
DYDLODEOH
WKH
P\ULDG
WRGD\
RI
,QVWHDG
VXFK
D
UHSUHVHQWDWLRQ
ZRXOG
PRVW
OLNHO\
UHTXLUH
GLIILFXOW
>@
FKRLFHV
DERXW WKH VSHFLILFDWLRQ DSSURDFK WR EH XVHG
DQG *ULVZROG :*
:HLGH
0XUDOL
6LWDUDPDQ
DQG
>@
-RVHSK
+ROOLQJVZRUWK
KDYH
DUH
DFNQRZOHGJH
ILQDQFLDO
1DWLRQDO
6FLHQFH
JUHDWO\
DSSUHFLDWHG
VXSSRUW
)RXQGDWLRQ
IURP
XQGHU
,Q
DGGLWLRQ
9LUJLQLD
JUDQW
7HFK
ZH
JUDWHIXOO\
DQG
IURP
&&5
.UDPHU 5
L&RQWUDFW²WKH -DYD GHVLJQ E\ FRQWUDFW WRRO
,Q
3URF 7HFKQRORJ\ RI 2EMHFW2ULHQWHG /DQJXDJHV 722/6
DOO FRQWULEXWHG WR WKH EDVLF DSSURDFK SURSRVHG LQ WKLV SDSHU WKHLU
FRQWULEXWLRQV
$VSHFWRULHQWHG SURJUDPPLQJ ZLWK $V
SHFW- $YDLODEOH RQOLQH DW KWWSZZZDVSHFWMRUJ
$&.12:/('*0(176
%UXFH
.LF]DOHV * +LOVGDOH ( +XJXQLQ - .HUVWHQ 0 3DOP -
>@
WKH
,((( &6 3UHVV SS .XULKDUD 0 DQG 2KXFKL $
UHIOHFWLYH ODQJXDJH
$Q\
$Q DOJHEUDLF VSHFLILFDWLRQ RI D
WK
3URF ,Q
$QQXDO ,QW¶O &RPSXWHU
6RIWZDUH DQG $SSOLFDWLRQV &RQI &2036$& RSLQLRQV FRQFOXVLRQV RU UHFRPPHQGDWLRQV H[SUHVVHG LQ WKLV SDSHU
,((( &6
3UHVV SS DUH WKRVH RI WKH DXWKRU DQG GR QRW QHFHVVDULO\ UHIOHFW WKH YLHZV RI
>@
16) RU 9LUJLQLD 7HFK
/DWRXU / :KHHOHU 7 DQG )UDNHV %
'HVFULSWLYH DQG SUH
GLFWLYH DVSHFWV RI WKH &V PRGHO 6(7$ ZRUNLQJ JURXS
5()(5(1&(6
>@
(GZDUGV 6+
7RROV IRU $GD
%ODFNER[ WHVWLQJ XVLQJ IORZJUDSKV $Q H[
>@
SHULPHQWDO DVVHVVPHQW RI HIIHFWLYHQHVV DQG DXWRPDWLRQ
SRWHQWLDO
6RIWZDUH 7HVWLQJ 9HULILFDWLRQ DQG 5HOLDELOLW\
(GZDUGV 6+
>@
>@
$ IUDPHZRUN IRU SUDFWLFDO DXWRPDWHG EODFN
6RIWZDUH 7HVWLQJ
-XQH 6RIWZDUH 5HXVH
1RY &RQFHSWV DQG H[SHULPHQWV LQ FRPSXWDWLRQDO UHIOHF
$&0 6,*3/$1 1RWLFHV 3URF 2236/$ ¶
'HF
>@
$ IUDPHZRUN IRU GHWHFWLQJ LQWHUIDFH YLROD
WLRQV LQ FRPSRQHQWEDVHG VRIWZDUH ,Q
0DHV 3
WLRQ
(GZDUGV 6 6KDNLU * 6LWDUDPDQ 0 :HLGH %: DQG
+ROOLQJVZRUWK -
5HIOHFWLRQV RQ PHWDSURJUDP
,((( 7UDQV 6RIWZDUH (QJLQHHULQJ
ER[ WHVWLQJ RI FRPSRQHQWEDVHG VRIWZDUH
9HULILFDWLRQ DQG 5HOLDELOLW\
6\PS (QYLURQPHQWV DQG
6SULQJ /HH $+ DQG =DFKDU\ -/
PLQJ
'HF >@
VW
$GD /HWWHUV 3URF VXPPDU\
0H\HU % $SSO\LQJ ³GHVLJQ E\ FRQWUDFW´
&RPSXWHU
2FW
3URF WK ,QW
O &RQI
>@
,((( &6 3UHVV /RV $ODPLWRV &$ SS
2EMHFW2ULHQWHG 6RIWZDUH &RQVWUXFWLRQ QG
0H\HU %
(GLWLRQ
3UHQWLFH +DOO 375 8SSHU 6DGGOH 5LYHU 1HZ -HU
>@
(GZDUGV 6+ DQG :HLGH %:
WK
:,65 VH\ >@
$QQXDO :RUN
VKRS RQ 6RIWZDUH 5HXVH 6XPPDU\ DQG ZRUNLQJ JURXS UH
SRUWV
3RXOLQ - DQG 7UDF] :
WK
:,65
$QQXDO :RUNVKRS RQ
6RIWZDUH 5HXVH 6XPPDU\ DQG ZRUNLQJ JURXS UHSRUWV
$&0 6,*62)7 6RIWZDUH (QJLQHHULQJ 1RWHV
6,*62)7 6RIWZDUH (QJLQHHULQJ 1RWHV
$&0
-DQ)HE 6HSW2FW >@
)HUEHU -
RULHQWHG ODQJXDJHV
6/$¶
>@
$&0 6,*3/$1 1RWLFHV 3URF 223
&HUWLILFDWLRQ RI UHXVDEOH VRIWZDUH FRPSRQHQWV 6XPPDU\ RI
ZRUN LQ SURJUHVV ,Q
5HIOHFWLYH IDFLOLWLHV LQ 6PDOO
$&0 6,*3/$1 1RWLFHV 3URF 2236/$¶
2FW
>@
*DPPD ( +HOP 5 -RKQVRQ 5 DQG 9OLVVLGHV -
0- +DUUROG 7HVWLQJ $ URDG PDS ,Q
ZDUH (QJLQHHULQJ
'HVLJQ
>@
7KH )XWXUH RI 6RIW
WK
VLJQ
>@
3URF $&0 6,*62)7 WK ,QW¶O 6\PSRVLXP RQ WKH
5HIOHFWLYH VSHFLILFDWLRQ
,Q
,QW¶O :RUNVKRS RQ 6RIWZDUH 6SHFLILFDWLRQ DQG 'H
6PLWK %
5HIOHFWLRQ DQG VHPDQWLFV LQ D SURFHGXUDO ODQ
7HFKQLFDO 5HSRUW 0DVVDFKXVHWWV ,QVWLWXWH RI
7HFKQRORJ\ /DERUDWRU\ IRU &RPSXWHU 6FLHQFH &DPEULGJH
6DQ 'LHJR &$ 1R
0$ >@
6XSSOHPHQW WR ,((( 6WDQGDUG IRU ,QIRUPDWLRQ 7HFK
6]\SHUVNL &
&RPSRQHQW 6RIWZDUH %H\RQG 2EMHFW
2ULHQWHG 3URJUDPPLQJ
QRORJ\²6RIWZDUH 5HXVH²'DWD 0RGHO IRU 5HXVH /LEUDU\ ,Q
WHURSHUDELOLW\ $VVHW &HUWLILFDWLRQ )UDPHZRUN
-DQ ,((( &6 3UHVV SS JXDJH
YHPEHU $&0 SS ,(((
6DHNL 0 +LURL 7 DQG 8JDL 7
3URF SHULHQFH UHSRUW 8VLQJ 5(62/9(& IRU FRPPHUFLDO VRIW
>@
$ SUDFWLFDO DSSURDFK WR SURJUDPPLQJ ZLWK
,((( 7UDQV 6RIWZDUH (QJ
$SSO\LQJ D UHIOHFWLYH ODQJXDJH WR IRUPDO VSHFLILFDWLRQ
+ROOLQJVZRUWK -( %ODQNHQVKLS / DQG :HLGH %: ([
,Q
,((( &6 3UHVV $ )LQNHOVWHLQ HG $&0 3UHVV 1HZ
)RXQGDWLRQV RI 6RIWZDUH (QJLQHHULQJ
5RVHQEOXP '6
DVVHUWLRQV
<RUN 1< SS ±
ZDUH
,((( ,QW¶O &RQ (QJLQHHULQJ
SS
$GGLVRQ:HVOH\ >@
QG
3URF RI &RPSOH[ &RPSXWHU 6\VWHPV
3DWWHUQV (OHPHQWV RI 5HXVDEOH 2EMHFW2ULHQWHG 6RIWZDUH
>@
5RKGH 6/ '\VRQ .$ *HULQHU 37 DQG &HULQR '$
2FW )RRWH % DQG -RKQVRQ 5(
WDON
>@
>@
&RPSXWDWLRQDO UHIOHFWLRQ LQ FODVV EDVHG REMHFW
>@
,((( 6WG
$GGLVRQ:HVOH\ :HLGH %: +H\P :' DQG +ROOLQJVZRUWK -( 5HYHUVH
HQJLQHHULQJ RI OHJDF\ FRGH H[SRVHG
,Q
WK
3URF ,QW¶O &RQI
D $SU >@
6RIWZDUH (QJLQHHULQJ
.LF]DOHV * GHV 5LYLHUHV - %REURZ '*
0HWDREMHFW 3URWRFRO
7KH $UW RI WKH
$&0 6HDWWOH :$ $SU SS
>@
0,7 3UHVV :HLGH %: +H\P :' DQG 2JGHQ :) ³0RGXODU UH
JUHVVLRQ WHVWLQJ´ &RQQHFWLRQV WR FRPSRQHQWEDVHG VRIWZDUH
,Q
20
WK
3URF $QQXDO :RUNVKRS RQ 6RIWZDUH 5HXVH
-DQ >@
:LQJ -0
>@
6HSW :RKOLQ & DQG 5XQHVRQ 3
SRQHQWV
>@
$ VSHFLILHU
V LQWURGXFWLRQ WR IRUPDO PHWKRGV
,((( &RPSXWHU
&HUWLILFDWLRQ RI VRIWZDUH FRP
,((( 7UDQV 6RIWZDUH (QJLQHHULQJ
-XQH 21
ZZZ[PORUJ
Architectural Reasoning in ArchJava
Jonathan Aldrich
Craig Chambers
Department of Computer Science and Engineering
University of Washington
Box 352350
Seattle, WA 98195-2350 USA
+1 206 616-1846
{jonal, chambers}@cs.washington.edu
Abstract
Software architecture is a crucial part of the specification of
component-based systems. Reasoning about software architecture
can aid design, program understanding, and formal analysis.
However, existing approaches decouple implementation code
from architecture, allowing inconsistencies, causing confusion,
violating architectural properties, and inhibiting software
evolution. ArchJava is an extension to Java that seamlessly
unifies a software architecture with its implementation.
ArchJava’s type system ensures that the implementation conforms
to the architectural constraints. Therefore, programmers can
visualize, analyze, reason about, and evolve architectures with
confidence that architectural properties are preserved by the
implementation.
1. Introduction
Software architecture [GS93][PW92] is the organization of a
software system as a collection of interacting components. A
typical architecture includes a set of components, connections
between the components, and constraints on how components
interact.
Describing architecture in a formal architecture
description language (ADL) [MT00] can make designs more
precise and subject to analysis, as well as aid program
understanding, implementation, evolution, and reuse.
Existing ADLs, however, are loosely coupled to implementation
languages, causing problems in the analysis, implementation,
understanding, and evolution of software systems. Some ADLs
[SDK+95][LV95] connect components that are implemented in a
separate language. However, these languages do not guarantee
that the implementation code obeys architectural constraints, but
instead rely on developers to follow style guidelines that prohibit
common programming idioms such as data sharing. Architectures
described with more abstract ADLs [AG97][MQR95] must be
implemented in an entirely different language, making it difficult
to trace architectural features to the implementation, and allowing
the implementation to become inconsistent with the architecture
as the program evolves. Thus, analysis in existing ADLs may
reveal important architectural properties, but these properties are
not guaranteed to hold in the implementation.
In order to enable architectural reasoning about an
implementation, the implementation must obey a consistency
property called communication integrity [MQR95][LV95]. A
system has communication integrity if implementation
components only communicate directly with the components they
are connected to in the architecture.
22
This paper presents ArchJava, a small, backwards-compatible
extension to Java that integrates software architecture smoothly
with Java implementation code. Our design makes two novel
contributions:
•
ArchJava seamlessly unifies architectural structure and
implementation in one language, allowing flexible
implementation techniques, ensuring traceability between
architecture and code, and supporting the co-evolution of
architecture and implementation.
•
ArchJava also guarantees communication integrity in an
architecture’s implementation, even in the presence of
advanced architectural features like run time component
creation and connection.
The rest of this paper is organized as follows. After the next
section’s discussion of related work, section 3 introduces the
ArchJava language. Section 4 formalizes ArchJava’s type system
and outlines a proof of soundness and communication integrity in
ArchJava. Section 5 briefly describes our initial experience with
ArchJava. Finally, section 6 concludes with a discussion of future
work.
2. Related Work
A number of architecture description languages have been defined
to describe, model, check, and implement software architectures
[MT00]. Many ADLs support sophisticated analysis, such as
checking for protocol deadlock [AG97] or formal reasoning about
correct refinement [MQR95]. Some ADLs allow programmers to
fill in implementation code to make a complete system
[LV95][SDK+95]. However, there is no guarantee that the
implementation respects the software architecture unless
programmers adhere to certain style guidelines.
Tools such as Reflexion Models [MNS01] have been developed
to show an engineer where an implementation is and is not
consistent with an architectural view of a software system. These
tools are particularly effective for legacy systems, where rewriting
the application in a language that supports architecture directly
would be prohibitively expensive.
The UML is an example of specification languages that support
various kinds of structural specification. UML’s class diagrams
can show the relationships between classes, and UML’s object
diagrams show relationships between object instances. However,
in most UML tools, these diagrams are only intended to show
some of the ways in which classes and objects can interact—they
cannot be used to argue that no other kinds of interaction are
possible, and thus do not support communication integrity.
Object hierarchies can be expressed using composition
relationships, but this relationship does not enforce
communication integrity either, because elements of the
composition can still interact with outside objects.
A number of computer-aided software engineering tools allow
programmers to define a software architecture in a design
language such as UML, ROOM, or SDL, and fill in the
architecture with code in the same language or in C++ or Java.
While these tools have powerful capabilities, they either do not
enforce communication integrity or enforce it in a restricted
language that is only applicable to certain domains. For example,
the SDL embedded system language prohibits all data sharing
between components via object references. This restriction
ensures communication integrity, but it also makes these
languages very awkward for general-purpose programming.
Many UML tools such as Rational Rose or I-Logix Rhapsody, in
contrast, allow method implementations to be specified in a
language like C++ or Java. This supports a great deal of
flexibility, but since the C++ or Java code may communicate
arbitrarily with other system components, there is no guarantee of
communication integrity in the implementation code.
Component-based infrastructures such as COM, CORBA, and
JavaBeans provide sophisticated services such as naming,
transactions and distribution for component-based applications.
Some commercial tools even provide graphical ways to connect
components together, allowing simple architectures to be
visualized. However, these systems have poor support for
structural specification of dynamically changing systems, and
have no concept of communication integrity. Communication
integrity can only be enforced by programmer discipline following
guidelines such as the Law of Demeter [LH89] that states, “only
talk to your immediate friends” in a system.
Advanced module systems such as MzScheme’s Units [FF98] and
ML’s functors [MTH90] can be used to encapsulate components
and to describe the static architecture of a system. The FoxNet
project [B95] shows how functors can be used to build up a
network stack architecture out of statically connected components.
However, these systems do not guarantee communication integrity
in the language; instead, programmers must follow a careful
methodology to ensure that each module communicates only with
the modules it is connected to in the architecture.
More recently, the component-oriented programming languages
ComponentJ [SC00] and ACOEL [Sre01] extend a Java-like base
language to explicitly support component composition. These
languages can be used to express components and static
architectures.
However, neither language makes dynamic
architectures explicit, and neither enforces communication
integrity.
3. The ArchJava Language
ArchJava is designed to investigate the benefits and drawbacks of
a relatively unexplored part of the ADL design space. Our
approach extends a practical implementation language to
incorporate architectural features and enforce communication
integrity. Key benefits we hope to realize with this approach
include better program understanding, reliable architectural
reasoning about code, keeping architecture and code consistent as
they evolve, and encouraging more developers to take advantage
of software architecture. ArchJava’s design also has some
limitations, discussed below in section 3.6.
23
public component class Parser {
public port in {
provides void setInfo(Token symbol,
SymTabEntry e);
requires Token nextToken()
throws ScanException;
}
public port out {
provides SymTabEntry getInfo(Token t);
requires void compile(AST ast);
}
void parse(String file) {
Token tok = in.nextToken();
AST ast = parseFile(tok);
out.compile(ast);
}
void parseFile(Token lookahead) { ... }
void setInfo(Token t, SymTabEntry e) { ... }
SymTabEntry getInfo(Token t) { ... }
...
}
Figure 1. A parser component in ArchJava. The Parser
component class uses two ports to communicate with other
components in a compiler. The parser’s in port declares a
required method that requests a token from the lexical
analyzer, and a provided method that initializes tokens in
the symbol table. The out port requires a method that
compiles an AST to object code, and provides a method that
looks up tokens in the symbol table.
A prototype compiler for ArchJava is publicly available for
download at the ArchJava web site [ACN01a]. Although in
ArchJava the source code is the canonical representation of the
architecture, visual representations are also important for
conveying architectural structure. This paper uses hand-drawn
diagrams to communicate architecture; however, we have also
constructed a simple visualization tool that generates architectural
diagrams automatically from ArchJava source code. In addition,
we intend to provide an archjavadoc tool that would
automatically construct graphical and textual web-based
documentation for ArchJava architectures.
To allow programmers to describe software architecture, ArchJava
adds new language constructs to support components,
connections, and ports. The rest of this section describes by
example how to use these constructs to express software
architectures. Throughout the discussion, we show how the
constructs work together to enforce communication integrity,
culminating in a precise definition of communication integrity in
ArchJava. Reports on the ArchJava web site [ACN01a] provide
more information, including the complete language semantics and
a formal proof of communication integrity in the core of
ArchJava.
3.1 Components and Ports
A component is a special kind of object that communicates with
other components in a structured way. Components are instances
of component classes, such as the Parser component class in
Figure 1. Component classes can inherit from other components.
A component instance communicates with external components
through ports. A port represents a logical communication channel
connected together. Figure 2 shows how a compiler’s architecture
can be expressed in ArchJava. The example shows that the parser
communicates with the scanner using one protocol, and with the
code generator using another. The architecture also implies that
the scanner does not communicate directly with the code
generator. A primary goal of ArchJava is to ease program
understanding tasks by supporting this kind of reasoning about
program structure.
Compiler
out in
scanner
out in
parser
codegen
public component class Compiler {
component Scanner scanner;
component Parser parser;
component CodeGen codegen;
3.2.1 Subcomponents
connect scanner.out, parser.in;
connect parser.out, codegen.in;
A subcomponent is a component instance that is declared inside
another component class. Components can invoke methods
directly on their subcomponents. However, subcomponents
cannot communicate with components external to their containing
component. Thus, communication patterns among components
are hierarchical.
public static void main(String args[]) {
new Compiler().compile(args);
}
public void compile(String args[]) {
// for each file in args do:
...parser.parse(file);...
}
}
Figure 2. A graphical compiler architecture and its
ArchJava representation. The Compiler component class
contains three subcomponents—a Scanner, a Parser,
and a CodeGen. This compiler architecture follows the
well-known pipeline compiler design [GS93].
The
scanner, parser, and codegen components are
connected in a linear sequence, with the out port of one
component connected to the in port of the next component.
between a component instance and one or more components that
it is connected to.
Ports declare three sets of methods, specified using the
requires, provides, and broadcasts keywords.
Provided methods can be invoked by other components connected
to the port. The component can invoke a disjoint set of required
methods through the port. Each required method is implemented
by a component that the port is connected to. Broadcast methods
are just like required methods, except that they must return void
and may be connected to an unbounded number of
implementations.
A port specifies both the services implemented by a component
and the services a component needs to do its job. Required
interfaces make dependencies explicit, reducing coupling between
components and promoting understanding of components in
isolation. Ports also make it easier to reason about a component’s
communication patterns.
Each port is a first-class object that implements its required and
broadcast methods, so a component can invoke these methods
directly on its ports. For example, the parse method calls
nextToken on the parser’s in port. These calls will be bound
to external components that implement the appropriate
functionality.
3.2 Component Composition
In ArchJava, software architecture is expressed with composite
components, which are made up of a number of subcomponents 1
1
Note: the term subcomponent indicates composition, whereas
the term component subclass would indicate inheritance.
24
Subcomponents are declared using a component field—a field of
component type inside a component class, declared using the
component keyword. For example, the compiler component
class defines scanner, parser, and code generator subcomponents.
To enable effective static reasoning about subcomponents,
component fields are treated as protected, final, and not
static. Subcomponents are automatically instantiated when the
containing component is created—programmers can use a new
expression in the field initializer in order to call a non-default
constructor.
3.2.2 Connections
The connect primitive connects two or more subcomponent
ports together, binding each required method to a provided
method with the same name and signature. Connections are
symmetric, and several connected components may require the
same method. Required methods must be connected to exactly
one provided method. However, invoking a broadcast method
results in calls to each connected provided method with the same
name and signature.
Provided methods can be implemented by forwarding invocations
to subcomponents or to the required methods of another port. The
semantics of method forwarding and broadcast methods are given
in the language reference manual on the ArchJava web site
[ACN01a].
Alternative connection semantics, such as
asynchronous communication, can be implemented in ArchJava
by writing custom “smart connector” components that take the
place of ordinary connections in the architecture.
3.3 Communication Integrity
The compiler architecture in Figure 2 shows that while the parser
communicates with the scanner and code generator, the scanner
and code generator do not directly communicate with each other.
If the diagram in Figure 2 represented an abstract architecture to
be implemented in Java code, it might be difficult to verify the
correctness of this reasoning in the implementation. For example,
if the scanner obtained a reference to the code generator, it could
invoke any of the code generator’s methods, violating the
intuition communicated by the architecture.
In contrast,
programmers can have confidence that an ArchJava architecture
accurately represents communication between components,
because the language semantics enforce communication integrity.
Communication integrity in ArchJava means that components in
an architecture can only call each others’ methods along declared
connections between ports. Each component in the architecture
can use its ports to communicate with the components to which it
is connected. However, a component may not directly invoke the
methods of components other than its children, because this
communication may not be declared in the architecture—a
violation of communication integrity. We define communication
integrity more precisely in section 3.5.
3.4 Dynamic Architectures
The constructs described above express architecture as a static
hierarchy of interacting component instances, which is sufficient
for a large class of systems. However, some system architectures
require creating and connecting together a dynamically
determined number of components.
Furthermore, even in
programs with a static architecture, the top-level component must
be instantiated at the beginning of the application.
workers
request
Communication integrity places restrictions on the ways in which
component instances can be used. Because only a component’s
parent can invoke its methods directly, it is essential that typed
references to subcomponents do not escape the scope of their
parent component. This requirement is enforced by prohibiting
component types in the ports and public interfaces of components,
and prohibiting ordinary classes from declaring arrays or fields of
component type. Since a component instance can still be freely
passed between components as an expression of type Object, a
ComponentCastException is thrown if an expression is
downcast to a component type outside the scope of its parent
component.
3.4.2 Connect expressions
Dynamically created components can be connected together at run
time using a connect expression. For instance, Figure 3 shows a
web server architecture where a Router component receives
incoming HTTP requests and passes them through connections to
Worker components that serve the request.
The
requestWorker method of the web server dynamically creates
a Worker component and then connects its serve port to the
workers port on the Router.
Communication integrity requires each component to explicitly
document the kinds of architectural interactions that are permitted
between its subcomponents. A connection pattern is used to
describe a set of connections that can be instantiated at run time
using connect expressions. For example, connect pattern
r.workers, Worker.serve describes a set of connections
between the component field r and dynamically created Worker
components.
Each connect expression must match a connection pattern
declared in the enclosing component. A connect expression
matches a connection pattern if the connected ports are identical
and each connected component instance is either the same
25
Router
serve
Worker
public component class WebServer {
component Router r;
connect r.request, create;
connect pattern r.workers, Worker.serve;
public void run() { r.listen(); }
private port create {
provides r.workers requestWorker() {
Worker newWorker = new Worker();
r.workers connection
= connect(r.workers, newWorker.serve);
return connection;
}
}
3.4.1 Dynamic Component Creation
Components can be dynamically instantiated using the same new
syntax used to create ordinary objects. For example, Figure 2
shows the compiler’s main method, which creates a Compiler
component and calls its invoke method. At creation time, each
component records the component instance that created it as its
parent component. For components like Compiler that are
instantiated outside the scope of any component instance, the
parent component is null.
WebServer
create
}
public component class Router {
public port interface workers {
requires void httpRequest(InputStream in,
OutputStream out);
}
public port request {
requires this.workers requestWorker();
}
public void listen() {
ServerSocket server = new ServerSocket(80);
while (true) {
Socket sock = server.accept();
this.workers conn = main.requestWorker();
conn.httpRequest(sock.getInputStream(),
sock.getOutputStream());
}
}
}
public component class Worker extends Thread {
public port serve {
provides void httpRequest(InputStream in,
OutputStream out) {
this.in = in; this.out = out; start();
}
}
public void run() {
File f = getRequestedFile(in);
sendHeaders(out);
copyFile(f, out);
}
// more method & data declarations...
}
Figure 3. A web server architecture. The Router
subcomponent accepts incoming HTTP requests, and pass
them on to a set of Worker components that respond.
When a request comes in, the Router requests a new
worker connection on its requestWorker port. The
WebServer then creates a new worker and connects it to
the Router. The Router assigns requests to Workers
through the workers port.
component field specified in the pattern, or an instance of the type
specified in the pattern. The connect expression in the web server
example matches the corresponding connection pattern because
the newWorker component in the connect expression is of static
type Worker, the same type declared in the pattern.
about the temporal order of architectural events, or about
component multiplicity.
3.4.3 Port Interfaces
ArchJava’s definition of communication integrity supports
reasoning about communication through method calls between
components. Program objects can also communicate through data
sharing via aliased objects, static fields, and the runtime system.
However, existing ways to control communication through shared
data often involve significant restrictions on programming style.
Future work includes developing ways to reason about these
additional
communication
channels
while
preserving
expressiveness. Meanwhile, our experience (described below)
suggests that rigorous reasoning about architectural control flow
can aid in program understanding and evolution, even in the
presence of shared data structures.
Often a single component participates in several connections
using the same conceptual protocol. For example, the Router
component in the web server communicates with several Worker
components, each through a different connection. A port
interface describes a port that can be instantiated several times to
communicate through different connections at run time.
Each port interface defines a type that includes all of the required
methods in that port. A port interface type combines a port’s
required interface with an instance expression that indicates
which component instance the type allows access to. For
example, in the Router component, the type this.workers
refers to an instance of the workers port of the current Router
component (in this case, this would be inferred automatically if
it were omitted). The type r.workers refers to an instance of
the workers port of the r subcomponent. This type can be used
in method signatures such as requestWorker and local
variable declarations such as conn in the listen method.
Required methods can be invoked on expressions of port interface
type, as shown by the call to httpRequest within
Router.listen.
Port interfaces are instantiated by connect expressions. A connect
expression returns a connection object that represents the
connection.
This connection object implements the port
interfaces of all the connected ports. Thus, in Figure 3, the
connection object connection implements the interfaces
Worker.serve and r.workers, and can therefore be
assigned to a variable of type r.workers.
Provided methods can obtain the connection object through which
the method call was invoked using the sender keyword. The
detailed semantics of sender and other language features are
covered in the ArchJava language reference available on the
ArchJava web site [ACN01a].
3.4.4 Removing Components and Connections
Just as Java does not provide a way to explicitly delete objects,
ArchJava does not provide a way to explicitly remove components
and connections. Instead, components are garbage-collected
when they are no longer reachable through direct references or
connections. For example, in Figure 3, a Worker component
will be garbage collected when the reference to the original
worker (newWorker) and the references to its connections
(connection and conn) go out of scope, and the thread within
Worker finishes execution.
3.5 Limitations of ArchJava
There are currently a number of limitations to the ArchJava
approach. Our technique is presently only applicable to programs
written in a single language and running on a single JVM,
although the concepts may extend to a wider domain.
Architectures in ArchJava are more concrete than architectures in
ADLs such as Wright, restricting the ways in which a given
architecture can be implemented—for example, inter-component
connections must be implemented with method calls. Also, in
order to focus on ensuring communication integrity, we do not yet
support other types of architectural reasoning, such as reasoning
26
4. ArchJava Formalization
In this section, we discuss the formal definition of communication
integrity and ArchJava’s semantics. The next subsection defines
communication integrity in ArchJava and intuitively explains how
it is enforced. Subsection 5.2 gives the static and dynamic
semantics of ArchFJ, a language incorporating the core features of
ArchJava.
Finally, subsection 5.3 outlines proofs of
communication integrity, subject reduction, and progress for
ArchFJ.
4.1 Definition of Communication Integrity
Communication integrity is the key property of ArchJava that
ensures that the implementation does not communicate in ways
that could violate reasoning about control flow in the architecture.
Intuitively, communication integrity in ArchJava means that a
component instance A may not call the methods of another
component instance B unless B is A’s subcomponent, or A and B
are sibling subcomponents of a common component instance that
declares a connection or connection pattern between them.
We now precisely define communication integrity in ArchJava.
Let the execution scope of component instance A on the run time
stack, denoted escope(A), be any of A’s executing methods and
any of the object methods they transitively invoke, until another
component’s method is invoked.
Definition 1 [Dynamic Execution Scope]: Let m be an executing
method with stack frame mf. If m is a component method, then
mf ∈ escope(this). Otherwise, mf ∈ escope(caller(mf)).
Now we can define communication integrity:
Definition 2 [Communication Integrity in ArchJava]: Let :< be
the subtyping relation over component classes. A program has
communication integrity if, for all run time method calls to a
method m of a component instance b in an executing stack frame
mf, where mf ∈ escope(a), either:
1.
a = b, or
2.
a = parent(b), or
3.
parent(a) = parent(b) ∧ “connect [pattern]
(f|t)1.p1,...,(f|t)n.pn” ∈ class(parent(a))
∧ ∃i,j ∈ 1..n s.t. (parent(a).fi = a ∨ type(a)<:ti) ∧
(parent(a).fj = b ∨ type(b)<:tj) ∧
m ∈ requiredmethods(pi) ∧
m ∈ providedmethods(pj)
Syntax:
CL
CP
K
M
R
X
e
Types:
_ _
_
::= class C extends C {C f; K M}
T
::= component class P extends
[P|Object] {C f; K M R X}
_ _
_
_
_
::= E(C f) {super(f); this.f = f;}
_ _
::= T m(T x) { return e; }
_ _
::= required T m(T x)
_
::= connect pattern (P)
::=
|
|
|
|
|
|
|
|
|
::= P
| e.PR
| E
_
| U(e.PR)
Subtyping:
x
e.f _
e.m(e,_this)
new C(e)
new P(e, <fresh>, eparent)
(C)e
(e.PR)e
cast(this, P, e)
connect(e, this)
error
T <: T
(S-REFLEX)
S <: T
T <: V
S <: V
(S-TRANS)
P <: Q
e1.PR <: e2.QR
(S-REQUIRED)
T <: Object
(S-OBJECT)
e.PR ∈ e.PR
(S-UNION)
U(e.PR) <: e.PR
CT (E) = [component] class E
extends F { ... }
E <: F
Figure 4. ArchFJ Syntax
4.2 Formalization as ArchFJ
We would like to use formal techniques to prove that the
ArchJava language design guarantees communication integrity,
and show that the language is type safe—that is, show that certain
classes of errors cannot occur at run time. Unfortunately, proofs
of type safety in a language like Java are extremely tedious due to
the many cases involved, and to our knowledge the full Java
language has never been formalized and proven type safe.
Therefore, a standard technique, exemplified by Featherweight
Java [IPW99], is to formalize a core language that captures the
key typing issues while ignoring complicating language details.
We have modified Featherweight Java (FJ) to capture the essence
of ArchJava in ArchFJ.
ArchFJ makes a number of
simplifications relative to ArchJava. ArchFJ leaves out ports;
instead, each component class has a set of required and provided
methods. Static connections and component fields are left out, as
they are subsumed by dynamically created connections
components. We also omit the sender keyword and broadcast
methods. As in Featherweight Java (FJ), we omit interfaces.
These changes make our type soundness proof shorter, but do not
materially affect it otherwise.
4.2.1 Syntax
Figure 4 presents the syntax of ArchFJ. The metavariables C and
D range over class names; E and F range over component and
class names; S, T, and V range over types; P and Q range over
component classes; f and g range over fields; d and e range over
expressions; l ranges over labels generated by <fresh>; and M
ranges over methods. As a shorthand, we use an overbar to
represent a sequence. We assume a fixed class table CT mapping
regular and component classes to their definitions. A program,
then, is a pair (CT, e) of a class table and an expression.
ArchFJ includes the features of FJ plus a few extensions. Regular
classes extend another class (which can be Object, a predefined
class) and define a constructor K and a set of fields f and
methods M . Component classes can extend another component
27
(S-EXTENDS)
Figure 5. ArchFJ Types and Subtyping Rules
class, or Object (as in FJ, there are no interfaces). Component
classes also declare a set of required methods R and a set of
connection patterns X between their subcomponents.
Expressions include field lookup, method calls, object and
component creation, various casts, a connect expression, and an
error expression. These are extended from FJ in a few small
ways:
• All method calls capture the current object this in an
additional psuedo-argument which comes last and is not
passed on to the callee.
• Components are labeled with a fresh label when they are
created (labels in a method body are freshly generated when
a method call is replaced with the method’s body). This
label allows us to reason about object identity in an
otherwise functional language (assignment is not relevant to
our type system or definition of communication integrity).
Components also keep track of their parent, and which of
their parent’s component fields they were created with.
• In addition to regular casts to a class type, there are two new
cast forms: one that allows casting to the required interface
of a component (i.e., the set of methods the component
requires), and another that allows casting to a component
field type. The first cast accepts an instance expression type,
while the latter cast includes an argument that captures the
value of this in the current scope. Both arguments are
used to verify the casts in the dynamic semantics.
• A connect expression conceptually creates a connection
object on which components can invoke their required
methods. The connect expression captures this, the parent
object that created the connection.
no cycles in the induced subtype relation. Required interface
types follow the subtyping relation of components (ignoring the
instance expressions, which are reasoned about separately from
subtyping). Finally, every type is a subtype of Object, and a
union is a subtype of all its member types.
Computation:
fields(E) = C f
(R-FIELD)
(new E(e,…)).fi → ei
mbody( m,C) = (x,e0 )
4.2.3 Reduction Rules
(R-INVK)
(new C(e)).m(d, d this)→
The reduction relation, defined by the reduction rules given in
Figure 6, is of the form e e’, read “expression e reduces to
expression e’ in one step.” We write * for the reflexive,
transitive closure of . The only unusual reduction rule is RXINVK, which allows method invocation on connection
expressions. The mbody helper function does a lookup to
determine the correct method body to invoke. Two error rules are
defined representing casts that are not guaranteed to succeed by
the type system presented below. The reduction rules can be
applied at any point in an expression, so we also need appropriate
congruence rules (such as if e e’ then e.f e’.f), which we
omit here. Furthermore, we assume an order of evaluation that
follows Java’s normal evaluation rules.
[d x, new C(e) this]e0
Æ
E <: C
(C)(new E(…)) → new E(…)
(R-CAST)
e = new E(…)</: C ∨ e = connect(…)
(C)(e) → error
(E-CAST)
mbody( m,P) = (x,e0 )
dthis = e ∨ dthis = eparent
e.m(d, d this)→[d x, e this]e0
e = new P(e, l, ethis)
P <: Q
cast(ethis, Q, e)→ e
(R-PINVK)
Most of the typing rules given in Figure 7 are standard. Typing
judgments are given in an HQYLURQPHQW + D ILQLWH PDSSLQJ IURP
variables to types. Rule T-INVK places constraints on passing
connection objects to an argument position declared with a
required interface and instance expression of this, to ensure that
the connection object does indeed connect the receiver object.
Rule T-PNEW introduces qualified component types. Rule TCONNECT introduces union types for connections. In addition,
T-CONNECT verifies that some connection pattern in the current
component matches the types of the connected objects; this will
be important later for establishing that reduction cannot get stuck
due to an illegal connection.
(R-PCAST)
e = connect(…) ∨
where ethis ≠ eparent ∨ P </: Q)
cast(ethis, Q, e) → error
P <: Q
(E-PCAST)
(R-RCAST)
(ecast.QR)(connect(e,ethis))
Class, method, and connection typing rules check for well-formed
class definitions, and have the form “class declaration E is OK,”
and “method/connection X is OK in E.” The rules for class and
method typing are similar to those in FJ. In the case of
component classes, the typing rule verifies that only subclasses of
Object may define required methods—as in ArchJava,
component subclasses may only inherit existing required methods
from their component superclass. The connection typing rule
verifies that each required method has a unique provided method
with the right signature, and that every method name has only one
signature across all the required methods.
→ connect(e,ethis)
e = new E(…) ∨
e = connect(e,ethis)
where ecast ∉ e ∨ ecast = new F(…) </: Q
(ecast.QR)(e) → error
dthis ∈ e
(E-RCAST)
legal (connect(e,ethis))
mbody( m,connect(e,ethis)) = (x,e0,ei )
Æ
4.2.4 Typing Rules
(e = new P(e, l, eparent)
ecast ∈ e
Æ
Æ
e = new P(e, l, eparent)
ecast = new P(…)
Æ
(R-XINVK)
(connect(e,ethis)).m(d, dthis)
→[d x, ei this]e0
Figure 6. ArchFJ Reduction Rules
• We represent failed dynamic checks (such as casts) with an
explicit error value, to make our progress theorem cleaner
to state.
4.2.2 Types and Subtypes
ArchJava’s types and subtyping rules are given in Figure 5.
Types include class and component types (E), required interface
types of components (e.PR), and union types of multiple required
interfaces. Subtyping of classes and components is defined by the
reflexive, transitive closure of the immediate subclass relation
given by the extends clauses in CT. We require that there are
28
We have made one significant simplification relative to FJ. We
do not distinguish between upcasts, downcasts, and so-called
“stupid casts” which cast one type to an unrelated one. This
means that our type system does not check for “stupid casts” in
the original typing derivation, as Java’s type system does.
However, the change shortens our presentation and proofs
considerably, and the stupid casts technique from FJ can be easily
applied to our system to get the same checks that are present in
Java.
Expression Typing:
Field lookup:
Γ l-- x ∈ Γ(x)
fields(Object) = ”
(T-VAR)
fields(C0 ) = C f
Γ l-- e0 ∈ C0
Γ l-- e0.fi ∈ Ci
CT (E) =[component] class E extends F
(T-FIELD)
{C f; K M [R X]}
fields(F) = D g
Γ l-- e0 ∈ T0
mtype( m,T0[,ethis]) = T → T
fields(E) = D g, C f
S <: T
Γ l-- e ∈ S
Γ l-- ethis ∈ Tthis
Connection lookup:
Ti = this.PRi implies Si = e0.SRi
Γ l-- e0.m(e, ethis)∈ T[e0 / this]
connects(Object) = ”
(T-INVK)
CT (P) = component class P extends E
fields(C) = D f
Γ l-- e ∈ C
C <: D
fields(P) = D f
Γ l-- e ∈ C
Γ l-- ep ∈ Tp
connects(E) = X0
connects(P) = X0, X
C <: D
(T-PNEW)
Γ l-- new P(e, < fresh >, ep)∈ P
Γ l-- ethis ∈ Pthis
{C f; K M R X}
(T-NEW)
Γ l-- new C(e)∈ C
Γ l-- e ∈ P
Method type lookup:
CT (E) =[component] class E extends F {… M …}
P <: Q
connect pattern(Q)∈ connects(Pthis )
Γ l-- connect(e, ethis)∈ U(e.PR)
T m (T x) {return e;}∈ M
mtype( m,E) = T → T
(T-CONNECT)
CT (E) =[component] class E extends F {… M …}
Γ l-- e ∈ T0
Γ l-- ([ecast.PR |C])e ∈[ecast.PR |C]
(T-CAST)
Γ l-- e ∈ T
Γ l-- ethis ∈ Pthis
Γ l-- cast(ethis,Q,e)∈ Q
(T-PCAST)
m is not defined in M
mtype( m,E) = mtype( m,F)
CT (P) = component class P extends E {…R …}
required T m (T x)∈ R
mtype( m,P) = T → T
Class Typing:
CT (P) = component class P extends E {…R …}
K = F(D g, C f) {super(g); this.f = f;}
fields (E) = D g
M[,X] OK IN P
E = Object ∨ # (R ) = 0
[component] class F extends E
m is not declared in R
mtype( m,e.PR ) = mtype( m,e.ER )
(T-CLASS)
ethis = ei
{C f; K M [R X]} OK
Method Typing:
Figure 8. ArchFJ Auxiliary Definitions
x:T, this:E l-- e ∈ S
S <: T
CT (E) =[component] class E extends F {…}
override( m, F, T → T)
T,T not components
4.2.5 Auxiliary Definitions
Most of the auxiliary definitions shown in Figures 8 and 9 are
straightforward and are taken from FJ. The connection typing
rule verifies that the passed-in this expression is one of the
instance expressions in the union type. The connection method
lookup rule chooses the component i providing the method with
mtype, based on the static types in the original connection
declaration. It is guaranteed to choose a unique component
because the connection typing rule implies that mtype is only
defined for one of the types in the connection. It then picks the
actual method body dynamically using the usual mbody rule.
Finally, it returns the expression to be passed as this in the
method call.
(T-METH)
T m(T x) { return e; } OK in E
Connection Typing:
∀i mtype( m,PRi ) = T → T implies
∃j ≠ i s.t. mtype( m,Pj ) = T → T
∧ ∀k ≠ j mtype( m,Pk ) not defined
∀i, j mtype( m,PRi ) = T → T ∧ mtype( m,PRj ) = S → S
implies T = S ∧ T = S
mtype( m,ei.PRi ) = T → T
mtype( m,U(e.PR ),ethis ) = T → T
(T-X)
connect pattern(P) OK IN Q
The legal rule checks that a connect expression corresponds to a
connection pattern. It also verifies that the connect expression
was created inside the parent component of each sibling.
Figure 7. ArchFJ Static Semantics
29
Proof sketch: The main property required is the following termsubstitution lemma:
Method body lookup:
CT (E) =[component] class E extends F {… M …}
Γ l-- d ∈ S1
mbody( m,E) = (x,e)
mtype( m,Pi ) = T → T
mbody( m,Qi ) = (x,e0 )
The only tricky case is to show that the preconditions of T-INVK
still hold after a reduction step. This can be shown based on a
case analysis on the introduction of required component types (TINVK, T-CONNECT, and T-CAST), and a lemma that term
substitution preserves the required relationships among instance
expressions.
mbody( m,connect(e, ethis)) = (x,e0,ei )
Legal Connections:
ei = new Qi(di,li,epi)
Theorem [Progress]: Suppose e is a well-typed expression.
Then either e has an error subexpression, or e is a value made
up of only new and connect expressions, or e e’.
connect pattern(P)∈ connects(Pthis )
Q <: P
for some
The theorem itself can then be proved by induction on the
derivation of e0 → e1 , with a case analysis on the last rule used.
Lemma 1 is useful in many of the steps, and especially for the
congruence rules.
e = new Q(…)
connect pattern(P)∈ connects(Pthis )
ethis = new Pthis(…)
Γ l-- [d x]e ∈ T1
Lemma 1 is proved by induction on the derivation of
Γ, x:S0 l-- e ∈ T0 .
m is not defined in M
mbody( m,E) = mbody( m,F)
Q <: P
where S1 <: S0 , then
T1 <: T0 .
CT (E) =[component] class E extends F {… M …}
ethis = new Pthis(…)
If Γ, x:S0 l-- e ∈ T0 and
Lemma 1 [Term Substitution]:
C m (C x) {return e;}∈ M
Æ
∀i ei = ethis ∨ epi = ethis
legal(connect(e,ethis))
Proof sketch: The theorem is proved by induction on the
derivation of the reduction of e. For each reduction rule, we
show that any valid typing for the subexpressions in the left-handside, together with the assumption of progress for the
subexpression, implies the preconditions for the reduction rule.
In most cases the implication is clear, but two interesting lemmas
are necessary for rules R-PINVK and R-XINVK, respectively.
Valid method overriding:
mtype( m, E) = T → T0 , implies S = T and S0 = T0
override( m, E, S → S0 )
Lemma 2 [An expression of component type reduces to this
or a direct child component of this]:
Figure 9. More Auxiliary Definitions
4.3 Theorems
We state three main theorems: communication integrity, subject
reduction, and progress. Subject reduction and progress together
imply that the ArchJava type system is sound. First, the reduction
rules ensure communication integrity:
Theorem [Communication Integrity in ArchFJ]:
1. For all direct method invocations on a component P that
succeed, either P or P’s parent component is the current
component this.
2. For all method invocations on a connection that succeed, the
current component P is part of the connection, P and the
component Q being invoked either have the same parent or
one is the parent of the other, and the parent P’ declared a
connection pattern between P and Q.
Proof: Part 1 of communication integrity is ensured by the
precondition dthis=e ∨ dthis=eparent of R-PINVK. Part 2 of
communication integrity is ensured by the precondition d this ∈ e
of R-XINVK as well as the definition of legal.
The presentation of our Subject Reduction and Progress theorems
is adapted from FJ [IPW99].
Theorem [Subject Reduction]: If Γ l-- e0 ∈ T0 and e0 → e1 , then
Γ l-- e1 ∈ T1 for some T1 <: T0 .
Consider an expression
et.m(e,…)
where et=new
E(…),
mbody(m,E) = (x,e0), and e0 has a subexpression e1.m(e1, this).
x:T, this:E l-- e1 ∈ P
If
and
[d/x, et/this]e1 → * new Q(…,eparent) , then either e1 = this
or eparent
Æ*
et.
This lemma can be proved by a case analysis of the last typing
rule used in the typing derivation of e1. There are only three rules
that result in a component type: T-VAR, T-PNEW, and T-PCAST
(methods cannot return component type, by the well-formed
method rule). The T-VAR rule gives a component type to a
variable x, but the only way a component type can be introduced
LQWR + LV E\ WKH FRPSRQHQW PHWKRG W\SLQJ UXOH ZLWK x = this. If
the component type was introduced in T-PNEW, e1 = new
Q(…,this) and so eparent = et. If the component type came
from T-PCAST, e1 must be of the form cast(this, P, new
Q(…,eparent)),
and
so
the
derivation
of
[d/x, et/this]e1 → * new Q(…,eparent)
must include a
reduction rule R-PCAST which verifies that eparent = et in the
final expression.
Lemma 3 [Well-typed connection expressions are legal]: If
Γ l-- connect(e,ethis)∈ T then legal (connect(e,ethis)) .
The typing rule T-CONNECT, together with Lemma 2,
demonstrates that all the required properties in legal hold.
30
5. Evaluation
We have written a prototype compiler for ArchJava, which is
available for download from the ArchJava web site [ACN01a]. In
order to determine whether the ArchJava language enables
effective component-oriented programming, we undertook a case
study applying ArchJava to Aphyds, a 12,000-line circuit design
application written in Java.
Results from our case study [ACN01b] indicate that for this
program, the developer’s architecture can be expressed in
ArchJava with relatively little effort (about 30 programmer hours).
The resulting architecture yields insight into the program’s
communication patterns, and may be useful in eliminating
software defects.
6. Conclusion and Future Work
ArchJava allows programmers to effectively express software
architecture and then seamlessly fill in the implementation with
Java code. This paper has motivated and outlined a language
design integrating architecture and implementation, and proved
type soundness and communication integrity in a formalization of
ArchJava. At every stage of development and evolution,
ArchJava enforces communication integrity, ensuring that the
implementation conforms to the specified architecture. Thus,
ArchJava helps to promote effective architecture-based design,
implementation, program understanding, and evolution.
In future work, we intend to extend the case study to larger
programs, to see if ArchJava can be successfully applied to
programs of 100,000 lines and up. We will also investigate
extending the language design to enable more advanced reasoning
about component-based systems, including temporal ordering
constraints on component method invocations and constraints on
data sharing between components.
7. Acknowledgements
We would like to thank David Notkin, Todd Millstein, Vassily
Litvinov, Vibha Sazawal, Matthai Philipose, and the anonymous
reviewers for their comments and suggestions. This work was
supported in part by NSF grant CCR-9970986, NSF Young
Investigator Award CCR-945776, and gifts from Sun
Microsystems and IBM.
8. References
[ACN01a] Jonathan Aldrich, Craig Chambers, and David Notkin.
ArchJava
web
site.
http://www.cs.washington.edu/homes/jonal/archjava/
[ACN01b] Jonathan Aldrich, Craig Chambers, and David Notkin.
Component-Oriented Programming in ArchJava.
In
Proceedings of the OOPSLA ’01 Workshop on Language
Mechanisms for Programming Software Components, July
2001.
Available
at
http://www.cs.washington.edu/homes/jonal/archjava/
31
[AG97] Robert Allen and David Garlan. A Formal Basis for
Architectural Connection. ACM Transactions on Software
Engineering and Methodology, 6(3):213---249, July 1997.
[B95] Jeremy Buhler. The Fox Project. ACM Crossroads 2.1,
September 1995.
[FF98] M. Flatt and M. Felleisen. Units: Cool modules for HOT
languages. In PLDI'98 - ACM Conf. on Programming
Language Design and Implementation, pages 236--248,
1998.
[GS93] David Garlan and Mary Shaw. An Introduction to
Software Architecture. In Advances in Software Engineering
and Knowledge Engineering, I (Ambriola V, Tortora G,
Eds.) World Scientific Publishing Company, 1993.
[IPW99] Atsushi Igarishi, Benjamin Pierce, and Philip Wadler.
Featherweight Java: A minimal core calculus for Java and
GJ. In Proceedings of ACM Conference on Object Oriented
Languages and Systems, November 1999.
[LH89] Karl Lieberherr and Ian Holland. Assuring Good Style
for Object-Oriented Programs. IEEE Software, Sept 1989.
[LV95] D.C. Luckham, J. Vera. An Event Based Architecture
Definition Language. IEEE Transactions on Software
Engineering Vol. 21, No 9, September 1995.
[MNS01] Gail C. Murphy, David Notkin, and Kevin J. Sullivan.
Software Reflexion Models: Bridging the Gap Between
Design and Implementation. To appear in IEEE Transactions
on Software Engineering, 2001.
[MQR95] M. Moriconi, X. Qian, A.A. Riemenschneider. Correct
Architecture Refinement. IEEE Transactions on Software
Engineering, Vol. 21, No 4, April 1995.
[MT00] Nenad Medvidovic and Richard N. Taylor. A
Classification and Comparison Framework for Software
Architecture Description Languages. IEEE Transactions on
Software Engineering, vol. 26, no. 1, pp. 70-93, January
2000.
[MTH90] R. Milner, M. Tofte, and R. Harper. The Definition of
Standard ML. The MIT Press, Cambridge, Massachussetts,
1990.
[PW92] Dewayne E. Perry and Alexander L. Wolf. Foundations
for the Study of Software Architecture. ACM SIGSOFT
Software Engineering Notes, 17:40--52, October 1992.
[SC00] J. C. Seco and L. Caires. A Basic Model of Typed
Components.
Proc. European Conference on ObjectOriented Programming, 2000.
[SDK+95] M. Shaw, R. DeLine, V. Klein, T.L. Ross, D.M.
Young, G. Zelesnik. Abstractions for Software Architecture
and Tools to Support Them. IEEE Transactions on Software
Engineering, Vol. 21, No 4, April 95.
[Sre01] V. C. Sreedhar. ACOEL: A Component-Oriented
Extensional Language. Unpublished manuscript, July 2001.
Using Message Sequence Charts for Component-Based
Formal Verification
Bernd Finkbeiner
Ingolf Krüger
Computer Science Department
Stanford University
Stanford, CA 94305, USA
Department of Informatics
Technical University of Munich
80290 Munich, Germany
[email protected]
[email protected]
ous approach to software development. Instead, we add the
component's observable behaviors as part of our interface
notion. Approaches at component-oriented system development, such as ROOM [32] and UML-RT [33], have a similar
but more informal interface notion. Our goal is to exploit
the extra information our interface notion oers during system verication in the context of pragmatic and industrially
accepted engineering approaches.
It is easy to describe the signature part of a component's
interface. But how to capture, represent, and systematically develop the behavioral aspects of an interface? Message Sequence Charts (MSCs) have gained wide acceptance
for scenario-based specications of component interaction
behavior (see, for instance, [20, 8, 31, 6, 29]). Due to their
intuitive notation MSCs have proven useful as a communication tool between customers and developers, thus helping to
reduce misunderstandings from the very early development
stages.
In this paper we investigate if MSCs can also serve as a
specication and reasoning technique for the composition
of systems from components. When used in a formal setting, MSCs could provide the link between the verication
of individual components and the correctness proof for the
complete system.
MSCs capture the communication or collaboration among
a set of components. Typically, an MSC consists of a set of
axes, each labeled with the name of a component. An axis
represents part of the existence of its corresponding component. Arrows in MSCs denote communication. An arrow
starts at the axis of the sender or initiator of the communication; the axis at which the head of the arrow ends designates
the communication's recipient or destination. Intuitively,
the order in which the arrows occur within an MSC denes
sequences of interaction among the depicted components.
Figure 1 shows an MSC that displays a sequence of interactions among three components in a simple communication
protocol.
The information that an MSC captures includes several
structural and behavioral aspects. The separate axes indicate logical or physical component distribution. The presence of an arrow between two axes indicates the existence
of a communication link between the corresponding components, as well as the occurrence of interaction itself. Finally, some MSC dialects, such as [31, 22, 10], allow the
developer also to indicate state changes of individual components contained in an MSC. Composite MSCs (C-MSCs)
extend the MSC language with additional structure, such as
ABSTRACT
Message sequence charts (MSCs) are are a popular tool to informally explain the behavioral embedding of a component
in its environment. In this paper we investigate if MSCs
can also serve as a specication and reasoning technique
for the composition of systems from components. We identify three challenges: (1) Semantic Duality: MSCs express
global coordination properties as well as requirements on
individual components for their correct participation in an
interaction pattern. We show that the two semantics do
not always agree and suggest syntactic constraints that ensure the represented property can be decomposed. (2) Completeness: we dene a decompositional proof rule based on
MSCs. We show that the rule is incomplete and discuss reasons and possible improvements. (3) Compositionality: in
component-oriented system development, the dierent parts
of the system are designed independently of each other. We
suggest a composition operator for MSC specications of
such components and outline dierences to operators used
for the composition of scenarios.
1.
INTRODUCTION
Component-based software development shortens the design process by allowing the software engineer to use blackbox components. A prerequisite for the composition of systems from components is adequate information about their
interface.
Here, with the notion of interface we associate not only
the signatures of the operations a component oers to its
environment; although popular, this interface notion oers
much too little information to be of value in a more rigorThis research was supported in part by NSF grant
CCR-99-00984-001, by ARO grants DAAG55-98-1-0471
and DAAD19-01-1-0723, by ARPA/AF contracts F3361500-C-1693 and F33615-99-C-3014 and by the Deutsche
Forschungsgemeinschaft within the priority program \SoftSpez" (SPP 1064) under project name InTime.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
OOPSLA 2001 Workshop on Specification and Verification of ComponentBased Systems Oct. 2001 Tampa, FL, USA
Copyright 2001 Bernd Finkbeiner and Ingolf Krüger.
32
msc Communication Protocol
Sender
Medium
msgSM
ackMS
Receiver
msgMR
ackRM
Figure 1: Basic MSC specifying a communication
protocol.
loops, alternatives, or sequential composition. The example
in Figure 2 shows a communication protocol with two alternative outcomes: the \Receiver" process may report success
(\ack") or failure (\fail").
msc Communication Protocol With Failure
Sender
Medium
msgSM
alt
ackMS
failMS
Receiver
msgMR
ackRM
failRM
Figure 2: C-MSC specifying a communication protocol with failure.
MSCs describe the embedding of individual components
into their environments, i.e., how components cooperate to
achieve a certain task in a distributed system. They hide
most of the details of local state changes of individual components and, instead, convey the \big picture" of the collaborations among the referenced components. This abstract,
and integrated view on system behavior has resulted in the
application of MSCs for use case specications, particularly
in object-oriented analysis and design, as well as for testcase specications and simulation-run visualizations, especially in tools for telecommunication and embedded systems.
In a sense, MSCs represent projections of the overall system
behavior onto particular services or tasks of the system; automata, another popular description technique for behav33
ioral aspects, typically represent projections of the overall
system behavior onto individual components.
Of increasing importance is the use of MSCs as a description technique for complete behavior patterns, instead of
for mere exemplary interaction scenarios, because this facilitates the MSC's seamless integration into an overall development process for distributed systems (cf. [24, 22], and
the references contained therein). This is a particularly useful approach for the specication for component interfaces
(as opposed to complete component behavior), because of
the typically limited size of the corresponding interaction
protocols.
An MSC describes both the global system behavior, and
how each individual component should perform to establish
the desired result. In this paper we explore how this duality can be used in the verication of distributed systems.
Formally, MSCs here assume the role of a decompositional
proof rule. They decompose a global specication into local
specications which are satised by the individual components. In the verication literature, this technique is known
as the assumption-commitment paradigm (cf. [12, 7]): the
environment of a component is specied only to the extent
that is necessary so that the component can guarantee its
correct operation; any implementation details about the environment are left unspecied at this point. Assumptioncommitment reasoning shifts the burden of formal verication from the system-level down to the component-level.
While the motivation for MSC-based descriptions and
assumption-commitment specications is similar, there is a
gap in the degree of formalization oered that must be closed
before MSCs can be used as a formal reasoning tool. In the
following sections we will discuss three challenges.
1. Semantic Duality: MSCs express global coordination
properties as well as requirements on individual components for their correct participation in an interaction pattern. We say an MSC has the decomposition
property if the two semantics agree. The decomposition property is necessary for MSCs used in component oriented proofs, since we infer the validity of a
global property from the validity of local properties.
Unfortunately, not all MSCs have the decomposition
property. We suggest syntactic constraints that ensure
the represented property can be decomposed.
2. Completeness: For MSCs that have the decomposition
property, we can formulate a decompositional proof
rule that reduces the proof of a global property to the
verication of local component properties. The rule is
incomplete: not all valid system properties can actually be proven with the rule. We discuss reasons for
the incompleteness and possible improvements.
3. Compositionality: In component-oriented system development, the dierent parts of the system are designed independently of each other. Correspondingly,
their MSC specications are unlikely to be identical
and we need a process to resolve dierences. We suggest such a composition operator and discuss dierences to operators used for the composition of scenarios.
In the following section we introduce MSCs formally, and
give a simple semantics based on !-automata; we address
the three challenges in Sections 3, 4 and 5.
2.
MESSAGE SEQUENCE CHARTS
MSCs have a wide spectrum of applications in the development process, ranging from analysis to implementation
support. Correspondingly, many dierent interpretations
have been proposed in the literature. An MSC language
supporting requirements capture and analysis of interaction
patterns requires a very liberal underlying semantics denition; it should, for instance, not exclude other possible
interaction patterns too early in the development process.
In this paper, we focus on the verication of universal
properties. Correspondingly, we are interested in the exclusion of undesired behaviors. In this section we describe a
semantics that achieves this by identifying all possible interaction patterns: behaviors other than the ones that are
explicitly depicted will be excluded.
We base our semantics on !-automata. The !-regular
languages form a particularly useful class since it is closed
under complementation and intersection, it is decidable and
in fact well-supported by verication algorithms (cf. [13,
18]). We will work with a simplied denition of basic message sequence charts. Similar denitions appear in [2, 3]; a
semantics for a richer dialect is given in [22].
Definition 1 (Message sequence charts). A (basic) message sequence chart (MSC) M = hP; M; E; C; Oi
is a labeled graph with the following components:
processes: a nite set P of processes or components;
messages: a nite set M of messages, we assume
that the messages
S can be partitioned according to their
senderSM = p2P Sp and according to their recipient
M = p2P Rp ; let Mp denote the union Sp [ Rp ;
events: a nite set E of events, each process p 2 P has
Definition 3 (Accepting paths). For an innite sequence of input symbols : s0 ; s1 ; s2 ; : : : an innite sequence
of transitions = (n0 ; s0 ; n1 ); (n1 ; s1 ; n2 ); : : : is a path of
A on if n0 2 I . A path is accepting if some edge in F
occurs innitely often in .
Definition 4 (Language). The language L(A) of an
automaton A is the set of all innite sequences of input
symbols that have an accepting path in A.
We represent an MSC as an automaton by using sets of
\simultaneously active" events as states. There is a transition for each interprocess edge and an additional -transition
that simulates an internal computation step. We assume
zero-delay communication: the transitions respect the partial order on the intraprocess edges as well as the synchronization introduced by the interprocess edges.
Definition 5 (Global semantics). Given a basic
MSC M = hP; M; E; C; Oi the global semantics is given as
the associated global automaton A = hN; ; I; T; Fi with
N = 2E[f?g,
= M [ f g,
I = f fep j p 2 P g g,
T contains a set of self-loops f(n; ; n) j n 2 N g and
a set of transitions reacting to messages: f(n1 ; s; n2 )g
such that
{ for each e1 2 n1 one of the following holds:
e1 2 0n2 and there
is no event e0 with
(e1 ; s; e ) 2 C or (e0 ; s; e1 ) 2 C ,
O(e1 ) 20 n2 and there0 is an event e0 2 n1 with
(e1 ; s; e ) 2 C or (e ; s; e1 ) 2 C , and
{ for each e2 2 n2 one of the following holds:
e2 2 n10 and there 0 is no event e0 2 E with
(e1 ; s; e ) 2 C or (e ; s; e1 ) 2 C
there is an event e1 2 n01 such that e20 = O(e1 )
and there is an event e with (e1 ; s; e ) 2 C or
(e0 ; s; e1 ) 2 C ,
a single initial event ep ;
interprocess edges: a set of directed edges connecting
events, labeled by messages between processes C E M E ; we assume that each event appears on exactly
one edge;
intraprocess edges: a function O : E ! E [ f?g connecting events in the order in which they are displayed.
? indicates that there is no subsequent event.
The !-regular languages are recognized by !-automata.
Dierent types of !-automata are distinguished according to
their acceptance conditions, in the following we will use the
fairly simple Buchi acceptance condition on the transitions
(for a survey on !-automata see [36]).
 chi automaton). A
Definition 2 (Bu
tomaton is a tuple A = hN; ; I; T; Fi with
Buchi
au-
nodes: a nite set N of nodes,
input alphabet: a nite set of input symbols,
initial nodes: a subset I N ,
transitions: a nite set T N N of labeled edges
connecting nodes,
acceptance condition:
a subset
F T.
Acceptance of an input sequence is determined as follows.
34
F = f(f?g; ; f?g)g.
Figure 3a shows the automaton associated with the MSC
from Figure 1. Accepting transitions are depicted with
double edges. The semantics of C-MSC constructs can be
described as the corresponding transformations on the automata. Here we restrict ourselves to sequential composition, nondeterministic alternatives, and nite as well as
innite loops; these language constructs suÆce for the purposes of this paper. We refer the reader to [22] for similar
constructions for almost all of the MSC-96 standard [20].
Definition 6
(Automata transformations).
For two Buchi automata A1 = hN1 ; ; I1 ; T1 ; F1 i
and A2 = hN2 ; ; I2 ; T2 ; F2 i we dene the result
hN 0 ; ; I 0; T 0 ; F 0 i of the following transformations:
sequential composition A1 ;A2 :
{ N 0 = N1 [ N2 ,
{ I 0 = I1 ,
1
msgSM
1
msgSM
2
msgMR
2
msgMR
3
ackRM ackRM
4
4
ackMS
5
3
(a)
MSCs describe both the system behavior and how each
individual component should perform to establish the desired result. A semantics reecting this duality thus has
both a global language and a local language for each process
involved in the depicted collaboration.
In this section we study the relationship between the two
languages. In a rst step we distinguish the messages in
whose sending or receipt a certain process is directly involved, and those that are sent and received in the process's
environment. The local semantics reects the fact that all
messages that are not either sent or received by a given
process are hidden : the process behavior is independent of
hidden messages.
For each transition (n; s; m) in the global automaton with
a hidden message s we add all transitions (n; s0 ; m) with
s0 2 (M Mp ) [ ff gg: from the process's point of view
it is indistinguishable if it was message s that was sent, or
some other hidden message, or even no message at all.
msgMR
6
failRM
7
ackMS
3. CHALLENGE 1: SEMANTIC DUALITY
failMS
5
8
(b)
Figure 3: Automata associated with (a) the MSC
from Figure 1 and (b) the C-MSC from Figure 2.
{
T0
[
T 0 = f(n; s; n0 ) j (n; s; n0 ) 2 T and s 2 Mp [ f gg
[ f(n; s0 ; n0 ) j (n; s; n0 ) 2 T and
s 2 Mp f g and s0 2 Mp g
T2
F 0 = f(n; s; n00) j 0(n; s; n0 ) 20 F and s 2 Mp [ f gg
[ f(n; s ; n ) j (n; s; n ) 2 F and
s 2 Mp f g and s0 2 Mp g
{ N 0 = N1 [ N2 ,
{ I 0 = I1 [ I2 ,
{ T 0 = T1 [ T2 ,
{ F 0 = F1 [ F2 ,
In component-oriented proofs, we infer the validity of a
global property from the validity of local properties. Hence,
we require that the global and local semantics are in agreement. However, not all MSCs have this property.
More formally, we say that an MSC has the decomposition
property if the following equation holds for the global automaton A, processes P and the local automata Ap , p 2 P :
\
L(Ap ) = L(A)
{ F = F1 [ F2 ,
alternative alt(A1 ; A2 ):
0
= T1 f(n1 ; s; f?g) 2 T1 g
[ f(n1 ; s; n2 ) j (n1 ; s; f?g) 2 T1 ; n2 2 I2 g
Definition 8 (Local semantics). For an MSC with
processes P and global automaton A = hN; ; I; T; Fi, the
local semantics for a process p 2 P0 is 0given as the associated
local automaton Ap = hN; ; I; T ; F i with
nite loop loop(A1 ):
{ N 0 = N1 ,
{ I 0 = I1 [ ff?gg,
{ T 0 = T1 [ f(n; s; m) j (n; s; f?g) 2 T1 ; m 2 I1 g,
{ F 0 = F1 ,
innite loop loop(A!1 ):
{ N 0 = N1 ,
{ I 0 = I1 ,
{ T 0 = f(n; s; m) j (n; s; m) 2 T1 ; m 6= f?gg
[ f(n; s; m) j (n; s; f?g) 2 T1 ; m 2 I1 g,
{ F 0 = f(n; s; m) j (n; s; m) 2 F1 ; m 6= f?gg
[ f(n; s; m) j (n; s; f?g) 2 T1 ; m 2 I1 g.
p2P
Figure 4 shows an MSC that does not have the decomposition property: consider an implementation in which
process \A" rst sends message \A1" and process \C" then
sends message \C2": this interaction is not allowed by
the global semantics. It is, however, accepted by all local
automata.
As an example consider again the C-MSC from Figure 2:
its associated automaton is shown in Figure 3b. Note that
both the paths that stay in node 5, and the paths that stay
in node 8 are accepting.
Definition 7
(Global Language). A (nite or innite) sequence of messages is accepted by an MSC M if
there is an innite sequence 0 of symbols in M [ f g such
that 0 with all occurrences of removed is equal to and
0 is accepted by the automaton associated with M .
35
Since equivalence between Buchi automata can be checked
with standard verication techniques (cf. [13]), a practical
solution is to check the decomposition property whenever
the MSC is intended to be used in a decompositional proof.
An alternative solution is to restrict the MSC syntax so
that the decomposition property is guaranteed. Causality is
such a restriction. Consider again the example in Figure 4.
There is an implicit causal relationship between messages
\A1" and \C1," and \A2" and \C2," respectively. If the
causalities were made explicit (for example with an extra
message between process \A" and and process \C" in one
of the alternatives), the decomposition property would hold.
We now give a syntactic characterization of a class of
causal MSCs. We introduce a few auxiliary notions: the
msc Non-Causal
A
B
C
D
alt
A1
C1
A2
C2
Figure 4: Non-causal MSC.
initial events init(M ) of an MSC M are those events that
do not causally depend on any other event in M ; dually, the
terminal events term(M ) are those events that do not cause
any other events in M . These sets of events serve as the basis for determining whether all message sequences expressed
by an MSC are causally connected. Moreover, our aim is to
distinguish clearly between dierent alternatives within a CMSC by considering only the rst message occurring within
such an alternative; therefore, we also introduce a formal
characterization for the set of rst messages exchanged between two processes of an MSC.
We start by dening a causal order for the messages depicted in an MSC M . This serves as the basis for dening
the sets init(M ) and term(M ), below.
Let an MSC
We dene an order
E E on M 's events as follows. Let e; f 2 E , then
M
Definition 9
(Causal Ancestor).
= hP; M; E; C; Oi be given.
ef
(e = f ) _ (9m 2 M : (e; m; f ) 2 C ) _ (f = O(e))
If we have e f , we call e direct causal ancestor of f . By
we denote
the reexive, transitive closure of . If we
have e f , we call e causal ancestor of f .
Thus, e 2 E is a direct causal ancestor of f 2 E , if either
e and f
coincide, or e and f are the send and corresponding
receive event of the same message transmission, or e occurs
immediately before f on the axis of the same process in the
corresponding
MSC M = hP; M; E; C; Oi. The causal order
captures indirect causal dependencies. This allows us to
dene initial and terminal events by structural induction on
the MSC syntax.
Definition 10
(Initial and terminal events).
For a basic MSC M = hP; M; E; C; Oi and its associated causal order we call an event e 2 E initial, if
8f 2 E : e f holds; similarly, we call e terminal, if
we have 8f 2 E : f e. If e is M 's initial event, we
set init(M ) = feg; if M has no initial event we dene
init(M ) = ;. Similarly, we set term(M ) = feg if e is M 's
terminal event, and term(M ) = ; if no terminal event
exists in M .
36
For a C-MSC M the initial and terminal events are given
as follows:
init(M1 ;M2 ) = init(M1 );
term(M1 ;M2 ) = term(M2 );
init(alt(M1 ; M2 )) = init(M1 ) [ init(M2 );
term(alt(M1 ; M2 )) = term(M1 ) [ term(M2 );
init(loop(M1 );M2) = init(M1 ) [ init(M2 );
term(M1 ;loop(M2 )) = term(M1 ) [ term(M2 );
init(loop(M1 )) = init(M1 );
term(loop(M1 )) = term(M1 )
init(loop(M1! !)) = init(M1 );
term(loop(M1 )) = ;.
In the denition of causal MSCs we will also constrain
what messages may occur as a rst message between two
processes. We denote the set of rst messages between process p and process q in the MSC M as fm(M; p; q). Formally,
let edges(p; q) denote the set of interprocess edges between
two processes p and q in a basic MSC:
edges(p; q) = f(e1 ; s; e2 ) 2 C; e1 ; e2 2 Ep [ Eq g:
The set of rst messages is then dened as follows.
Definition 11
(First messages).
For a basic MSC
M and two processes p; q with no interprocess edges between
p and q , edges(p; q ) = ;, the set of rst messages is empty:
fm(M; p; q) = ;. For non-empty edges(p; q), we call the edge
(e1 ; s; e2 ) 2 edges(p;0 q) where0 e10 is0 a causal ancestor to all
other send events e1 with (e1 ; s ; e2 ) 2 edges(p; q ) the rst
interprocess edge and the message s the rst message between p and q : fm(M; p; q ) = fsg. For C-MSCs the rst
messages are the following sets:
fm(M1 ;M2 ; p; q) = fm(M1 ; p; q) if fm(M1 ; p; q) 6= ; and
fm(M2 ; p; q) otherwise;
fm(alt(M1 ; M2 ); p; q) = fm(M1 ; p; q) [ fm(M1 ; p; q)
fm(loop(M1 );M2 ; p; q) = fm(M1 ; p; q) [ fm(M1 ; p; q)
fm(loop(M1 ); p; q) = fm(M1 ; p; q)
fm(loop(M1! ); p; q) = fm(M1 ; p; q)
Intuitively, each process in a causal MSC should always be
able to infer which branch of the MSC is currently executed.
This is ensured with the following syntactic constraints.
Definition 12
(Causal MSC).
An MSC M is a
causal MSC if one of the following conditions holds.
M is a basic MSC and has an initial event;
msgSM ack
RM
msg
SM
2
msgMR
msgSM
3
1
2
ackRM
M is an alternative between two causal MSCs,
M = alt(M1 ; M2 ), and for all processes p and q ,
fm(M1 ; p; q) \ fm(M2 ; p; q) = ;
ackMS ack
RM
msg
5 SM ackMS
Related work. The diÆculty in mapping global properties to responsibilities of individual components has been
considered in the literature (cf. [25, 26, 1] among others),
sometimes under the keyword \nonlocal choice." Besides
syntactic constraints as done for causal MSCs here, the problem can also be solved by partial or total distribution of an
automaton representing the global property to all or part
of the component implementation [19]; this ensures that all
components synchronize their actions via the global automaton. This comes at the cost of increasing the complexity of
the individual components considerably.
CHALLENGE 2: COMPLETENESS
In formal verication, we prove that a system satises its
specication. If the system is the composition of a set of
components S = fCp j p 2 P g and the specication is given
as an MSC M , verifying S j= M corresponds to checking
the language inclusion
\
L(Cp) L(A)
p2 P
where L(Cp ) is the language accepted by the component
implementing process p and A is the global automaton associated with M .
Analysis techniques for this problem are computationally
expensive; the complexity of model checking [9], for instance,
is exponential in n. It has therefore long been recognized
that verication must be based on the decomposition of the
system into its components.
We now discuss a decompositional proof rule for MSCs.
Following the assumption-commitment paradigm, such a
rule supplies two automata for each component: the assumption on the component's environment, represented by
37
(a)
2
ackMS
msgMR msgMR msg
MR
ackMS
3
3
ackRM ack
RM
msgSM
4
M is a nite loop loop(M1 ) or an innite loop
loop(M1! ) of a causal MSC M1 .
msgMR
ackMS
1
msgSM msgSM
M is a sequential composition M = M1 ;M2 , M1 has a
terminal event e1 , M2 has an initial event e2 and e1
and e2 belong to the same process;
The MSC in Figure 4 is not causal, because the sendevents for messages \A1" and \C1" do not have a common
causal ancestor. In fact, the MSC would remain non-causal
if were to remove the second alternative, even though
the decomposition property holds for the resulting MSC.
Causality is hence a suÆcient but not necessary condition
for the decomposition property.
4.
1
ackRM
ackRM
msgMR
4 4
ackMS msg
MR
ack
MS
5 5
(b)
(c)
Figure 5: (a) environment-safety automaton, (b)
environment-liveness automaton, (c) environment
automaton for the \Medium" process from Figure 1.
an environment automaton Ep, and the commitment, represented by the associated local automaton from the previous
section. To prove S j= M for a system S = fCp j p 2 P g
and an MSC
M with global automaton A we nd a second
MSC M 0 that has the decomposition property. Let A0 be
the global automaton associated with M 0 , and A0p and Ep0 ,
the local automata and environment automata, respectively,
for processes p 2 P . The following rule reduces the global
property to local proof obligations for each component:
Decompositional proof rule
if
(1) for all p 2 P , L(Ep ) \ L(Cp ) L(A0p )
0
and (2)
L(A)
\L(A )
then
(
C
)
L p
L(A)
p2P
Since the component can rely on the environment to cooperate, we can exclude behaviors from the environment
automaton in which the environment either illegaly sends
a message (safety violation) or in which the component is
kept waiting for the next message innitely (liveness violation). We construct two automata, the environment-safety
automaton S that recognizes all behaviors where the environment violates safety, and the environment-liveness automaton L, that recognizes all behaviors where the environment violates liveness. Behaviors accepted by either automaton need not be considered in the verication of the
component.
Safety violations can be recognized by considering nite
prexes of input sequences. Let A = hN; ; I; T; Fi be the
global automaton associated with an MSC M . The set of
all nite prexes of sequences in L(A), the prex language
of M , is accepted by the automaton hN; ; I; T; T i. Because
of the trivial acceptance condition it is possible to construct
a deterministic Buchi automaton PA that accepts the prex
language (cf. [36]).
Definition 13 (Environment-safety). Let the automaton PA = hN; ; I; T; Fi be a deterministic Buchi automaton that accepts the prex language of an MSC. The
environment-safety automaton for process p is the automaton Sp = hN 0 ; ; I; T 0 ; F 0 i with
[ f
g
T 0 = T [ f(n; s; ) j s 2 M Sp and
@n0 2 N : (n; s; n0 ) 2 T g
[ f(
; s; ) j s 2 g
0
F = f(
; s; ) j s 2 g
N0 = N
B
tickAB
tickBA
Definition 14 (Environment-liveness). Let the automaton PA = hN; ; I; T; Fi be a deterministic Buchi automaton that accepts the prex language of an MSC. The
environment-liveness automaton for process p is the automaton Lp = hN; ; I; T; F 0 i with
F 0 = f(n; ; n) j @n0 2 N; s 2 Sp : (n; s; n0 ) 2 T and
Sp ) : (n; s; n0 ) 2 T g
Finally, the environment automaton Ep contains all behaviors in which the environment commits neither a safety
nor a liveness violation. In the example, this combination
results in the environment automaton shown in Figure 5c.
(Environment automaton). Let
be the environment-safety automaton and Lp the
environment-liveness automaton for a process p. The
environment automaton Ep accepts the language
Sp
A
alt
Figure 5a shows the environment-safety automaton for the
\Medium" process from the communication protocol example. Note that the accepting paths stay in node ; a transition to occurs whenever the environment illegally sends
a message.
Figure 5b shows the environment-liveness automaton for
the \Medium" process. The accepting paths stay in nodes
1 and 3: in node 1, the \Medium" process can count on
the \Sender" process to eventually send a message; in node
3, the \Medium" process awaits the acknowledgement from
the \Receiver" process.
9n0 2 N; s 2 (M
msc Incompleteness
Definition 15
L(Ep) = L(Sp) [ L(Lp )
We can now analyze the completeness of our rule. The
decompositional proof rule is complete if for any system S
and MSC M with S j= M , there is an MSC M 0 such that
the conditions of the rule hold. So far, we have made no
assumptions about the components allowed in the system
composition. In this generality, the decompositional proof
rule is clearly incomplete.
In Figure 6, the specication is satised if the two
processes \A" and \B" exchange exactly one message.
Now consider the following implementation: component
\A" chooses at each point nondeterministically whether
or not to send its message to \B" (unless it receives a
message from \B" rst). \B," on the other hand, applies
a timeout-mechanism that guarantees that
eventually a
message is sent. There is no MSC M 0 such that the
conditions of the decompositional proof rule hold: none of
the two alternatives in Figure 6 can be removed since either
message may occur.
38
Figure 6: Incompleteness example.
The incompleteness of the proof rule stems from the difference in expressiveness of the MSCs we have considered so
far, and the components implementing individual processes.
This leaves us with two options for achieving completeness:
one is to restrict our attention to a smaller class of systems,
the other is to add to the expressiveness of MSCs.
Examples for restrictions are regularity: the language accepted by each component is !-regular, reactivity: every
component exchanges innitely many messages with its environment, and I/O directedness: a component has control
only over its output messages. If such restrictions are inadequate, it is certainly possible to make MSCs more expressive, for example with an explicit assignment of progress
responsibilities: the property in Figure 6 could be proven
for the described implementation by indicating in Figure 6
that process \B" is responsible for the progress beyond the
interprocess edge (resulting in an appropriately modied environment automaton for process \A").
In practice, components often accept a non-regular
language. Suggestions in the literature to extend MSCs to
non-regular languages include extensions with data states
[6, 22], as well as performance and real-time constraints
(cf. [16, 17, 31]). However, any extension to the MSC's
expressiveness comes at the price of increased complexity:
many extended MSCs are undecidable. Care is also required to avoid syntactic clutter and to maintain the MSCs'
intuitive appearance.
Related work. Decompositional proofs have been studied for a long time, starting with the rely-guarantee formalism [21] and proofs for networks of processes [27]. Since
then, many assumption-commitment rules have been proposed, see [12] for an overview and [30] for a discussion of
their completeness. Our decomposition of MSC properties
into an assumption-commitment specication for individual
components is similar to the one in [7]; the semantic framework used there includes the reactivity and I/O directedness requirements mentioned above. We are not aware of
any work that formally analyzes the completeness of MSC
languages. A closely related topic, however, is the \reverse
engineering" of MSCs from systems; this is studied in [28].
5.
CHALLENGE 3: COMPOSITIONALITY
In the preceding sections we have addressed the properties expressed by individual MSCs with respect to a certain system under consideration. Now we turn our attention to the composition of specications from several, possibly non-orthogonal MSCs. Intuitively, two MSCs are nonorthogonal, if one contains a segment of an interaction pattern depicted by the other. We deal with this problem from
two perspectives. First, we study the composition of \othe-shelf" components specically in the context of verication; here, the basic problem is to relate the already xed
interface specications of already existing components. Second, we consider MSC composition in the more general context of scenario specications.
In component-oriented system development, the dierent
parts of a system are designed independently of each other;
components may be retrieved from a database that was put
together long before the system's conception. It is therefore
unrealistic to expect that the MSCs documenting the dierent components will agree, and we need a process to resolve
any dierences.
In our communication protocol example, assume the
\Sender" component is described by the simple MSC from
Figure 1, and the \Medium" component has the richer functionality depicted in Figure 2. Which MSC describes the
embedding of the composition of the two components in the
system? Or should this combination of components be rejected altogether?
In assumption-commitment reasoning, the environment of
a component is expected to show at most the behavior allowed by the environment assumption (cf. [12]). Hence, the
combination of \Sender" and \Medium" component in our
communication protocol example would be rejected, since
the \Medium" component may send a \fail" message which
is not allowed in the MSC of the \Sender" component. Semantically, this analysis corresponds to a pessimistic view
of the environment [11]: The combination of two components is rejected because an environment exists that would
violate the specication of one of the components. In this
example, there is an implementation of the (so far not analyzed) \Receiver" process that corresponds to the MSC of
the \Medium" component, but that would cause a violation
of the MSC of the \Sender" component. A more liberal optimistic view allows the combination of two components as
long as an implementation for the remaining environment
exists that would allow all specications to be satised.
The optimistic point of view can be implemented in a process for the composition of component MSCs. Given a system S and an MSC MA specifying the behavior of a subset
of the components A S , and an MSC MB specifying the
components B S , we construct an MSC MA[B specifying
A [ B . In this chart only those behaviors of S (A [ B ) are
allowed that do not cause the components in A to violate
environment assumptions of the components in B , or, vice
versa, cause the components in B to violate environment
assumptions of components in A.
There are automata-based solutions for optimistic composition (cf. [11]). It would be desirable to have purely syntactic combination operations for MSCs that implement this
semantic construction and combinations for more expressive
MSC languages. This would constitute a rst step towards
a thorough, seamless usage of MSCs as a specication and
verication aid in the context of component composition.
39
We now turn to questions of MSC composition in a more
general setting including analysis and design in addition to
verication. As we have argued in the preceding sections we
need a very strict MSC interpretation for promising MSC
application in the verication task. The well-established
usage of MSCs for capturing scenarios, on the other hand,
is an example of a very liberal MSC interpretation. A
scenario captures one possible segment of an overall system
execution, projected onto the components referenced in
the MSC. Because scenarios describe usually very specic
instances of behavior, a corresponding composition operator
must be very permissive; it cannot exclude alternative or
even interleaved behaviors prematurely. [22] contains a
composition operator, called \join", which matches the
messages shared by the two operand MSCs; the resulting
MSC's semantics contains only behaviors where this match
is possible. This form of composition explicitly supports
the combination of overlapping specications; it is easily
transferred into the semantic framework we have established
in this paper.
Related work. The distinction between \optimistic"
and \pessimistic" compositionality has been made in the
verication literature, for example in lazy compositional verication [34] and, more recently, within the formalism of interface automata [11]. In the MSC literature certain dialects
can be seen as closer to the pessimistic or optimistic point of
view. [22] discusses MSC interpretations in the range from
scenarios to exact component behavior; the latter excludes
behaviors other than the explicitly depicted ones.
6. CONCLUSIONS AND OUTLOOK
Message sequence charts have been used for quite some
time to informally describe the embedding of a component
in its environment. In this paper we have formulated criteria the MSC language should satisfy so that the embedding
furthermore qualies as a formal proof: if this is achieved,
then the correctness of the system is guaranteed once each
individual component is veried.
Certain compromises must be made when choosing an
MSC language. The simple MSCs described in Section 2
are attractive because their semantics is well-supported by
verication methods; however, they do not provide a complete proof technique as discussed in Section 4. More expressive languages, such as the ones mentioned at the end
of Section 4, on the other hand, are hard to analyze or even
undecidable. For a given system and component model, a
good compromise would be to rst select a language on the
basis of its completeness and then identify fragments according to their expressiveness.
Using MSCs as a verication tool as suggested in this
paper should feel natural to designers familiar with MSCbased scenario descriptions. There is also a close resemblance to verication tools such as generalized verication
diagrams [4, 5]: verication diagrams are similarly based
on !-automata, and they can also be used for componentoriented proofs [14]. MSCs and verication diagrams work,
however, on dierent levels: verication diagrams are complete proofs of a certain property. MSCs, on the other hand,
do not constitute complete proofs by themselves, since they
are constructed independently of implementation details.
Instead, they integrate the verication of individual properties in the correctness proof of the overall system.
Compositionality may be the hardest remaining challenge
for a practical application of MSCs in component-based verication. In this paper we have addressed the composition of
MSC specications referencing concrete components of the
system under consideration. Often, however, similar interaction patterns occur over and over again within the same
system among dierent sets of components, and also within
other systems. We can also identify and describe these interaction patterns by means of MSCs: we only have to interpret the axes of the MSCs more liberally. By parameterizing
MSCs with respect to their axis labelings, i.e., the components they reference, we obtain a exible language for such
recurring interaction patterns. Instead of a single concrete
component of a particular system under consideration, an
axis then represents the \role" of a participant in the interaction pattern. The resulting MSCs describe interaction
patterns abstractly, without references to concrete participants of a collaboration. We also speak of \connectors",
when referencing abstract interaction protocols (cf. also [37,
33, 35, 7, 6]).
To use MSCs successfully in describing connectors (cf. [6,
7, 23, 15]) we need a way to relate abstract connectors and
concrete component interfaces. One way to do so is to instantiate the roles in connectors by concrete components,
whose interfaces are also specied by MSCs; in a second
step we then have to match the behaviors allowed by the
connector with those of the instantiating components.
Exploiting the information contained in a connector during component-oriented verication displays much potential
for reducing the overall verication complexity, and is a
promising area of future research.
Acknowledgments
The authors are grateful to Manfred Broy, Cesar Sanchez,
Bernhard Schatz and Henny Sipma for helpful discussions
and comments on causality and MSCs in general.
7.
REFERENCES
[1] R. Alur, K. Etessami, and M. Yannakakis. Inference of
Message Sequence Charts. In Proceedings of 22nd
International Conference on Software Engineering,
pages 304{313, 2000.
[2] R. Alur, K. Etessami, and M. Yannakakis.
Realizability and verication of MSC graphs. In 28th
International Colloquium on Automata, Languages
and Programming, LNCS. Springer-Verlag, 2001.
[3] R. Alur, G. J. Holzmann, and D. Peled. An analyzer
for message sequence charts. Software | Concepts
and Tools, 17:70 { 77, 1996.
[4] A. Browne, Z. Manna, and H. B. Sipma. Generalized
temporal verication diagrams. In 15th Conference on
the Foundations of Software Technology and
Theoretical Computer Science, volume 1026 of LNCS,
pages 484{498. Springer-Verlag, 1995.
[5] A. Browne, Z. Manna, and H. B. Sipma. Hierarchical
verication using verication diagrams. In 2nd Asian
Computing Science Conf., volume 1179 of LNCS,
pages 276{286. Springer-Verlag, Dec. 1996.
[6] M. Broy, C. Hofmann, I. Kruger, and M. Schmidt. A
graphical description technique for communication in
software architectures. Technical Report TUM-I9705,
Technische Universitat Munchen, 1997.
40
[7] M. Broy and I. Kruger. Interaction Interfaces {
Towards a scientic foundation of a methodological
usage of Message Sequence Charts. In J. Staples,
M. G. Hinchey, and S. Liu, editors, Formal
Engineering Methods (ICFEM'98), pages 2{15. IEEE
Computer Society, 1998.
[8] F. Buschmann, R. Meunier, H. Rohnert,
P. Sommerlad, and M. Stal. A System of Patterns.
Pattern-Oriented Software Architecture. Wiley, 1996.
[9] E. Clarke, O. Grumberg, and D. Peled. Model
Checking. MIT Press, 1999.
[10] W. Damm and D. Harel. LSCs: Breathing Life into
Message Sequence Charts. In FMOODS'99 IFIP
TC6/WG6.1 Third International Conference on
Formal Methods for Open Object-Based Distributed
Systems, 1999.
[11] L. de Alfaro and T. Henzinger. Interface automata. In
Proceedings of the Ninth Annual Symposium on
Foundations of Software Engineering. ACM Press,
2001.
[12] W.-P. de Roever, H. Langmaack, and A. Pnueli,
editors. Compositionality: The Signicant Dierence.
COMPOS'97, volume 1536 of LNCS. Springer-Verlag,
1998.
[13] B. Finkbeiner. Language containment checking using
nondeterministic bdds. In Tools and Algorithms for
the Construction and Analysis of Systems, volume
2031 of LNCS. Springer-Verlag, 2001.
[14] B. Finkbeiner, Z. Manna, and H. B. Sipma. Deductive
verication of modular systems. In de Roever et al.
[12], pages 239{275.
[15] J. Grabowski, P. Graubmann, and E. Rudolph.
HyperMSCs with Connectors for Advanced Visual
System Modelling and Testing. In SDL Forum 2001,
pages 129{147. Springer, 2001.
[16] R. Grosu, I. Kruger, and T. Stauner. Hybrid sequence
charts. Technical Report TUM-I9914, Technische
Univeritat Munchen, 1999.
[17] R. Grosu, I. Kruger, and T. Stauner. Requirements
Specication of an Automotive System with Hybrid
Sequence Charts. In WORDS'99F, Fifth International
Workshop on Object-oriented Real-time Dependable
Systems. IEEE, 1999.
[18] R. Hardin, Z. Har'El, and R. Kurshan. COSPAN. In
R. Alur and T. A. Henzinger, editors, Proc. 8th Intl.
Conference on Computer Aided Verication, volume
1102 of LNCS, pages 423{427. Springer-Verlag, July
1996.
[19] D. Harel and H. Kugler. Synthesizing object systems
from lcs specications, 1999. (submitted).
[20] ITU-TS. Recommendation Z.120 : Message Sequence
Chart (MSC). Geneva, 1996.
[21] C. Jones. Tentative steps toward a development
method for interfering programs. ACM TOPLAS,
5(4):596{619, 1983.
[22] I. Kruger. Distributed System Design with Message
Sequence Charts. PhD thesis, Technische Universitat
Munchen, 2000.
[23] I. Kruger. Notational and Methodical Issues in
Forward Engineering with MSCs. In T. Systa, editor,
Proceedings of OOPSLA 2000 Workshop:
Scenario-based round trip engineering. Tampere
[24]
[25]
[26]
[27]
[28]
[29]
University of Technology, Software Systems
Laboratory, Report 20, 2000.
I. Kruger, R. Grosu, P. Scholz, and M. Broy. From
MSCs to Statecharts. In DIPES'98. Kluwer, 1999.
P. B. Ladkin and S. Leue. Interpreting Message Flow
Graphs. Formal Aspects of Computing, (5):473{509,
1995.
S. Leue. Methods and Semantics for
Telecommunications Systems Engineering. PhD thesis,
Universitat Bern, 1995.
J. Misra and K. M. Chandy. Proofs of networks of
processes. IEEE Transactions on Software
Engineering, SE-7(4):417{426, 1981.
A. Muscholl and D. Peled. From nite state
communication protocols to high level message
sequence charts. In 28th Int. Col. on Automata
Languages and Programming (ICALP'2001), volume
2076 of LNCS, pages 720{731. Springer-Verlag, 2001.
R. Nahm. Designing and documenting componentware
with message sequence charts. In T. Jell, editor,
Component-based Software Engineering, pages
111{116. Cambridge University Press, 1998.
41
[30] K. S. Namjoshi and R. J. Treer. On the completeness
of compositional reasoning. In 12th International
Conference on Computer Aided Verication, volume
1855 of LNCS, pages 139{153. Springer-Verlag, 2000.
[31] Unied modeling language, version 1.1. Rational
Software Corporation, 1997.
[32] B. Selic, G. Gullekson, and P. T. Ward. Real-Time
Object-Oriented Modeling. Wiley, 1994.
[33] B. Selic and J. Rumbaugh. Using UML for modeling
complex real-time systems.
http://www.objectime.com/otl/technical, April
1998.
[34] N. Shankar. Lazy compositional verication. In
de Roever et al. [12].
[35] M. Shaw and D. Garlan. Software architectures.
perspectives on an emerging discipline, 1996.
[36] W. Thomas. Automata on innite objects. In J. van
Leeuwen, editor, Handbook of Theoretical Computer
Science, volume B, pages 133{191. Elsevier Science
Publishers (North-Holland), 1990.
[37] A. C. Wills and D. D'Souza. Objects, Components,
and Frameworks with UML{ The Catalysis Approach.
Addison Wesley, 1998.
Reasoning about Composition:
A Predicate Transformer Approach
[Position Paper]
Michel Charpentier
Department of Computer Science
University of New Hampshire
[email protected]
ABSTRACT
As interest in components and composition-related methods
is growing rapidly, it is not always clear what the goals (and
the corresponding difficulties) actually are. If composition
is to become central in the future of software engineering,
we need to better identify the fundamental issues that are
related to it, before we attempt to solve them as they occur in object-oriented systems or in concurrent and reactive
systems. In this paper, we present our formulation of some
of the composition problems in a context of formal methods
and program specification and verification. This formalization is based on predicate calculus and predicate transformers and aims at remaining as general as possible. This way,
we hope to better understand some of the fundamental issues of composition and component-based reasoning.
1. INTRODUCTION
Composition is receiving a lot of attention these days: Components are everywhere and everything is (or ought to be)
“compositional ”. What is meant by that, though, is far
from being clear, and there is a wide range of opinions
on what is still to be done. Some might argue that the
composition problem is now solved at a fundamental level
and that actual techniques and tools just need to be put
in place. At the other end of the spectrum, some might believe that composition, as we understand it today, cannot be
achieved in software engineering and that other approaches
must be sought. And, between these two extremes, are research projects, mostly independent from one another, that
focus on specific instances of this composition problem, be
it a type system in an object-oriented context or a temporal
logic for reactive systems.
A possible reason for this apparent contradiction and confusion is that composition is a broad concept and that the
composition problem might not be unique. There are many
42
issues related to composition, some are easier to tackle than
others, and many must be dealt with before the problem
can be considered solved (or unsolvable). In this paper, we
advocate the idea that an important step today is to identify those composition problems and to understand how they
relate to each other.
We restrict our attention to composition in a formal methods
context. Other contexts, such as for instance programming
languages, lead to other composition problems and all have
to be solved in order to make composition viable as a whole.
Furthermore, we choose a static point of view: we reason
about properties of systems and components whereas a dynamic point of view would focus on the process of building
systems from components.
These choices, however, leave us in a broad background
where fundamental questions related to many forms of composition can be explored: What are components? How are
they composed? How are they described and specified?
What do we expect from such specifications? What is the relationship between systems and components specifications?
What does it mean to be “compositional ”? How can we obtain compositional specifications? Can composition lead to
simpler correctness proofs? How does composition relate to
reuse? How does it relate to abstraction?
Our current effort focuses on addressing these questions without specializing the chosen context any further. This way,
we hope to better understand what problems are common to
different forms of composition and what problems are specific to families of components or laws of composition. As a
guideline for this general exploration, we also consider the
special case of concurrent composition of processes specified
in temporal logic. This familiar but complex background, in
which the composition problem is far from being solved, is
both a source of inspiration and a test-bench for our abstract
study of composition. Our approach to studying composition as well as some of our results are informally introduced
in the remaining of this paper. Technical details can be
found in cited references.
2.
SPECIFICATIONS AND PROOFS
IN COMPOSITIONAL DESIGNS
2.1 Compositional Design versus
Compositional Verification
quired. When designing a system and looking for a suitable
component, the specification used by the designer cannot include too many details about this component, because any
component with the right functionalities should be usable,
whatever its implementation details are. Such a specification must also be able to express that some aspects are irrelevant in order to avoid an overspecification of requirements.
If requirements are overspecified, then designers might end
up not finding any suitable component while actually some
existing component would fit their needs perfectly.
Composition has often been advocated as a necessary step
in the proof of large systems. While this is certainly true,
we do not want to restrict composition to that role.
For instance, it is possible to build a system from components, generate correctness proof obligations from the complete system, and then apply composition at the proof level
(split the global proof obligation into several independent
proofs). This approach is suggested, for instance, in [24].
Compositional model-checking also follows this philosophy
to some degree.
A second reason why we want specifications to be abstract
is to keep composition worthwhile and cost effective in spite
of the natural overhead it generates. A key idea of component technology is that the same component can be used
in many systems, and thus the effort that goes into specifying, proving and implementing components can be exploited
many times. As explained before, each time a component is
reused, a proof, the correctness proof of that component, is
reused too. If a component specification contains abstract,
relevant, hard-to-prove facts about the component, a possibly difficult and large proof is reused. However, if a component specification is too close to its implementation and not
abstract enough, very little proof can be reused. Therefore,
greater productivity is achieved by using components that
embody substantial effort by containing proofs of abstract
specifications.
While the previous technique is relatively simple and allows
verification techniques to handle large systems, we have in
mind a more ambitious role for composition, namely the
“open system” approach. In this approach, we want to verify the correctness of components in isolation, before they
become part of any system. In the previous case, the complete knowledge of the system can be used to verify one
component. For open systems, this is not true anymore. All
that is known are specific assumptions on possible environments, which are part of a component specification. This
tends to make proofs harder since these assumptions describe a set of possible environments instead of a completely
specified context, and they have to be abstract and generic
enough to allow a large number of environments to use the
component.
This situation is illustrated in figure 1. Proofs labeled with
‘T’ are those component-correctness proofs that are left unchanged through composition and that can be reused in the
design of several systems. Proofs labeled with ‘C’ are proofs
of composition, i.e., proofs of system properties from component properties. The level of abstraction of component
specifications clearly influences the amount of effort that has
to be put in T-proofs and in C-proofs. A good framework
for composition should allow us to put most of the effort in
T-proofs and keep C-proofs as simple as possible. Even if
the sum of C and T-proofs is larger and more complex than
a direct (noncompositional) proof for the same system, composition is still worthwhile because existing T-proofs can be
reused.
However, the open system approach also has benefits that
make its study worthwhile. Firstly, since components are
already proved correct with respect to their specifications,
the correctness proof of a complete system can rely on these
specifications instead of the components’ implementations.
This allows designers not to take into account the many
details of the internal structure of each component. Compositionality of designs breaks down when reasoning about
a system requires managing too many details from each part
of that system.
Part of the problem is that specifications that are too abstract do not contain enough information to be composed.
Therefore, the right balance between abstraction and ability
to be composed must be found.
Secondly, and this is probably the main benefit, the open
system approach allows designers to embed parts of a correctness proof into components, making these parts available
each time a component is used to build a system. Indeed,
when a component is proved correct with respect to its specification, relevant facts about this component are extracted
from the details of its implementation and become part of
the component specification. When this component is composed with a larger system, these facts can be used in the
system correctness proof without the need for proving them
again. Each time a component is reused, a (possibly difficult) proof is reused too, as well as any other correctness
argument available such as tests or behavior in other systems.
2.2
3.
3.1
SPECIFICITY OF OUR RESEARCH
Shortcomings of Current Approaches
When deterministic components are composed sequentially,
the problem reduces to composition of functions and remains
tractable. Developers use libraries of procedures every day
and rely on their specifications without having to consider
implementation details.
However, effective compositional design often involves nondeterministic components and concurrent composition. For
instance, the different parts of a reactive system cannot be
specified in terms of precondition and postcondition because
of their possibly infinite behavior, which leads to tremendous
difficulties in terms of composition.
Abstract Specifications
In order to be able to achieve such reuse, we need specifications to remain abstract enough to describe what is required
from a component, all that is required and only what is re-
43
Global System
C
Component
1
Component
2
Component
...
T
T
C
Program Text
1
Program Text
2
Component
...
Component
...
Component
...
Specification
C
Proof of composition
Program
T
Proof of component correctness
Figure 1: A compositional design
Composition of such systems, which interact at the level of
their behavior, not at the level of their initial/final state, has
been extensively studied. Very schematically, two distinct
families emerge.
tailored to certain forms of composition. Our view is one
of a component-based software industry, where composition
is involved in almost every design. We want to deal with
this composition, whether it works well or not, whether it
is easy or not. This departs from the works on temporal
logic cited above, where usually the whole language is made
“composable” by restricting up front the type of interaction
under consideration. For instance, composition works fine
in TLA (it reduces to conjunction) [2], but component assumptions are made at the transition level and cannot be at
the computation level, as in the case of liveness assumptions
(see example in section 4.4).
On the one hand, process algebras, such as CSP, CCS or
π-calculus to name a few, integrate composition as a central part of their design. Systems are compositions of processes and processes compose quite naturally. The resulting
formally well-defined notation, however, often looks like a
programming language more than a specification language.
In this context, it is quite difficult to express abstract properties on the expected behavior of these components and
systems. As a consequence, it is difficult to obtain reusable
generic specifications, as well as specifications easily related
to informal requirements.
The context of our work is therefore independent of the nature of systems. It is not a context of “variables”, “states”,
“computations”, “interleaving”, “safety” or “liveness”, but
rather one of “systems”, “components”, “specifications” and
“composition laws”. No specific logic or process model is
used and few hypotheses are made on composition laws.
This way, it is hoped that we can understand aspects that
are common to many forms of composition and many types
of systems. Later, that knowledge can be applied to the
concurrent composition of reactive systems, for instance.
Temporal logics, on the other hand, such as LTL, CTL,
TLA, or Unity, are well-suited to express nonoperational,
abstract specifications. They provide us with specification
languages that are closer to informal descriptions, which
makes specifications more easily readable and checkable with
respect to informal requirements. However, the starting
point of these notations is the specification of a system, globally. Composition is viewed as an additional issue, which requires a specific treatment. Work has been done to manage
composition issues with specific logics [25, 19, 18, 2, 20, 23,
34, 21], but little work has been done to study composition
in itself, independently of the underlying logic [1, 4, 3].
3.2
This approach inherits from both the process algebra and
the temporal logic families mentioned above. On the one
hand, we consider that systems are specified logically (without choosing a specific logic), which provides us with a rich
specification language and allows us potentially to apply results to temporal logics for reactive systems. On the other
hand, we define an algebra of composition with the goal of
obtaining a calculus that would allow us to calculate (instead of guess and then prove) properties of systems and
components. In this respect, our approach relates to process calculus based approaches.
Composition in the Abstract
The specificity of our approach is to study composition independently from what components and the laws of composition actually are. We are not focusing on a specific
domain, nor do we want to design specification languages
44
4. CURRENT WORK
4.1 Existential and Universal Specifications
cal implication of a more general operator which we called
WE [6]. This allows a separation of concerns: WE actually
represents composition while logical implication represents
the assumption-commitment mechanism. WE is a predicate
transformer, in other words, a function from specifications
to specifications. Formally, for a specification X, WE.X is
defined as the weakest existential specification stronger than
X (which exists regardless of X).
The starting point of our exploration is the definition of
a simple model of components, systems and specifications.
Because of our concern with generality, we use a monoidlike structure of components and specifications are boolean
functions (predicates) on components and systems. In other
words, we assume that components are composed with a single law of composition for which we assume associativity but
no other property such as symmetry or idempotency. As a
consequence, the model can be instantiated with transformational programs (specified in terms of preconditions and
postconditions and composed sequentially) or with reactive
processes (specified with temporal logics and composed concurrently), among other things.
It can be proved that WE.X characterizes those components
F such that specification X holds in any system that contains F as a component [14]. As a consequence, the specification X guarantees Y is actually equivalent to WE.(X ⇒ Y ).
In other words, guarantees is the weakest (the most abstract)
strengthening of logical implication that makes it composable (for the existential form of composition). This, in some
sense, is a theoretical argument to claim that guarantees can
provide us with abstract, reusable specifications.
In this context, we first focused on two particular families
of specifications called existential and universal [7, 14]. We
say that a specification is existential exactly when, for all
systems, the specification holds in a system if it holds in at
least one component of that system. Similarly, a specification is universal if it holds in a system when it holds in all
components of that system. Existential and universal are
characteristics of specifications, independent of a particular
set of components. Some specifications are existential, some
are universal and, of course, some are neither. However,
when existential and universal specifications are used, they
naturally lead to simple proofs of composition (C-proofs),
properties being inherited by a system from its components.
4.2
WE is the first of a series of predicate transformers that we
have started to study. Indeed, we can define SE.X as the
strongest existential property weaker than X. The corresponding theorem states that SE.X characterizes those systems that contain at least one component that satisfies X.
In other words, when a component that satisfies X is used
in a system, this system satisfies SE.X. In the best case
(when X is an existential specification), the system satisfies
X (SE.X is equivalent to X); in the worst case (where all
of X is lost through composition), SE.X reduces to true. In
some sense, SE.X represents the part of specification X that
composes (existentially). Equivalently, SE.X characterizes
those systems that are (or can be) built using a component
that satisfies specification X [15].
A “guarantees” Operator for
Assumption-Commitment Specifications
If we only allow existential and universal specifications to
appear in component descriptions, this is a restriction on
how components can be described. This is the price to pay
for simple proofs of composition. However, we have found
these two classes to be surprisingly rich. For instance, the
work on temporal logics in [19, 18, 2, 20, 34, 21] relies almost
exclusively on existential-like composition.
Things are different in the case of universal composition. A
transformer SU can be defined (as the strongest universal
specification weaker than a given specification), but we are
still looking for a suitable WU. Such a transformer would
be useful to characterize what has to be proved on a component instead of a (nonuniversal) specification X in order
to inherit the simplicity of universal composition. However,
it cannot be defined as the weakest universal specification
stronger than a given specification because such a weakest
element does not always exist, depending on the nonuniversal specification that is considered. We have started to
study several possible candidates for a WU operator but we
do not have a strong argument in favor of one of them yet.
As a guideline for that search of WU, we have also studied
the question of strengthening nonuniversal properties in a
more restricted context, namely a linear temporal logic (see
section 4.4).
One reason why existential specifications appear to be so
convenient is the existence of the guarantees operator defined in [7]. The guarantees operator can be used to express existential assumption-commitment specifications. Its
main originality is that it is not defined in terms of component environments, as assumption-commitment specifications usually are (components are making assumptions on
their possible environments). In the case of guarantees, the
commitment part of the specification as well as the assumption part apply to a complete system (environment + component): X guarantees Y holds in a component F if and
only if Y holds in G◦F ◦H (where ◦ denotes the law of composition under consideration) when X holds in G◦F ◦H, for
all systems G and H that can be composed with F . The
fundamental property of guarantees is that X guarantees Y
is existential regardless of what the specifications X and Y
are. Therefore, proofs of composition are simplified when
components are specified in terms of guarantees.
4.3
Furthermore, by describing composition in terms of predicate transformers, for which a large amount of literature
exists [22], we are able to reuse classic techniques such as
conjugates. Every predicate transformer T has a unique
conjugate T ∗ such that T ∗ .X = ¬T .(¬X). The transformers we have defined for existential and universal composition
also have conjugates, namely WE∗ , SE∗ and SU∗ . It should
be noted that, while WE, SE and SU describe composition
from components to systems (what has to be proved on
components, what can be deduced on systems), WE∗ , SE∗
and SU∗ describe composition from systems to components
Predicate Transformers for Composition
By studying the guarantees operator carefully, we made
the observation that it is merely the application to logi-
45
(what should be proved on systems, what can be deduced
on components). For instance, WE∗ .X is true of any component that is used to build a system that satisfies specification
X. This form of reasoning, from systems to components, is
sometimes neglected. We believe it to be extremely important because it is the kind of reasoning that is involved when
system designers are looking for components. A designer
who is building a system to satisfy specification X knows
that only components that satisfy WE∗ .X can be used and
that other components need not be considered. We find
conjugates to be a powerful and elegant way to switch from
bottom-up to top-down views on composition [13]. In particular, many properties of predicate transformers, such as
junctivity and monotonicity, are inherited from transformers
to conjugates. This allows us to avoid duplicating proofs.
4.4
Using universal specifications gives rise to other interesting
issues. For instance, the Unity logic (which was used in our
examples) exists in two forms: a weak form and a strong
form [31, 28, 27]. The Unity operator invariant leads to
universal specifications in its strong form but not in its weak
form. For the sake of simplicity, we used the strong form of
Unity logic in our example. However, this is not realistic from a practical point of view (the strong form of the
logic is much too strong for a specification) and we have to
find ways of strengthening the weak form to make it universal. We have defined such a strengthening based on WE [9]
(the resulting universal form of the weak invariant resembles a similar operator from [34]), but we cannot tell if this
is an optimal solution. In other words, we do not know if
the resulting operator is the weakest universal specification
stronger than the weak invariant (we do not even know if
such a weakest solution exists). Besides its practical interest, this question also relates to the problem of finding a
suitable transformer WU, as explained earlier in section 4.3.
Application to UNITY logic
In parallel with our work on predicate transformers and composition, we have started to apply our ideas to specifications
and proofs of concurrent and distributed systems. Theoretical investigation is one way to claim the usefulness of operators (for instance, by proving that they are the weakest
solution to some set of equations). Practical attempts at
writing specifications and proofs based on these operators
are another.
Our second example involves distributed systems. It makes
use of guarantees, mixed with techniques for abstract communication description that were previously developed [16,
26, 8, 33, 17]. This abstract description of communication is
made possible by the ability of guarantees to involve liveness
specifications in its assumption part. Basically, a network
component guarantees that the sequence of received messages is always a prefix of the sequence of sent messages
(safety) and that any message that is sent is eventually received (liveness).
Two of these examples were fully developed and published.
One focuses on shared memory systems [11], while the other
deals with distributed systems [12, 5].
There are other places in this example where our use of
liveness specifications combined with guarantees leads to
simpler proofs of composition by embedding larger proofs
in components verification (see the discussion in 2.2). For
instance, this example involves a resource allocator component that satisfies a property of the form: clients return
resources in finite time (and other conditions) guarantees
any request for resources is eventually satisfied. The proof
of composition remains simple because the corresponding
client component property that states that clients actually
return resources in finite time can be plugged (through network specifications) into the left-hand side of this guarantees
property to deduce that all requests are eventually granted.
In the first example, universal specifications are used instead
of guarantees, which does not seem to fit this example well
enough. In this case, the correctness argument relies on the
fact that some dependency graph among processes remains
acyclic. Since each process only modifies the dependency
graph locally (by interacting with its neighbors), no single
process can guarantee that the graph remains acyclic, using
an existential property. However, there can be a property
that states that no process will ever create a cycle in the
graph. Such a property can be formulated in a universal
way so that, when it is satisfied by all processes, the global
system also satisfies it and cycles cannot be introduced in
the graph.
If liveness properties cannot be used in the assumption part
of a composition operator 7→ (as in [1, 2, 18, 19, 20, 21]),
the resource allocator specification has to be of the form:
enough resources are available to satisfy the first pending
request 7→ the first pending request is eventually granted. In
this case, the fact that clients return resources in finite time
cannot be used directly as before. Instead, a first proof of
composition is required to show that enough resources will
eventually be available to satisfy the first pending request
and then a second proof to show that other requests are
eventually satisfied. When guarantees is used, these two
proofs (by induction) are inside the correctness proof of the
allocator component and can be reused when the allocator
component is reused. In the other case, they are in the
proof of composition and have to be redone every time a
new system is built from these components.
This raises a number of interesting questions. In this example, it appears that universal specifications are required
to describe the behavior of shared variables (variables that
are written by several processes). However, there are other
examples with shared variables that can successfully be specified in terms of guarantees. There are also systems without
shared variables (distributed systems) but where a shared
virtual data structure (such as a graph among processes)
is used in the correctness proof. Should such a system be
specified in terms of guarantees (it usually can, from the
absence of shared variables) or in terms of universal specifications of the shared virtual data structure? And if guarantees is used, should the correctness proof rely directly on it
or can we obtain a simpler proof by using an intermediate
(universal) specification that is deduced from the original
(existential) specification? These are the kind of fundamental questions we plan to explore through the development of
other examples.
46
5.
OUTLINE OF FUTURE RESEARCH
tics, from which we can draw new inspirations [10]. This
new set of transformers has now to be explored carefully.
Especially, relationships between transformer properties and
assumptions on the different laws of composition have to be
found.
The work described above represents a first step towards our
exploration of composition issues in system design. Starting with guarantees as a middle point, the research is now
developing both upstream (towards predicate transformers
and other fundamental composition-related operators) and
downstream (towards practical application to concurrent systems).
6.
SUMMARY
The lack of composition-based methods is a major factor
in the limited use of formal methods in actual designs. We
believe our project adopts a novel view on an old and important problem. Most work on composition has focused
on a specific form of composition (sequential, parallel with
shared variables, parallel with message passing, etc.) and a
specific type of component (namely, programs, either with
states or with so-called “open system computations”). By
choosing a much more general view, we hope to understand
fundamental aspects of composition that are independent
from the types of components and the way they interact.
One of our goals is the definition of a formal calculus in
which specifications can be transformed to fit specific composition constraints. In other words, starting from requirements that are not compositional, we want to calculate a
suitable compositional specification. In the case of existential composition, for example, it is not enough to know that
WE.X is what needs to be proved on a component to ensure
that systems which use that component will satisfy specification X. We need to know how to prove WE.X given a
component description.
Our ultimate goal is to build a calculus for composition. It
would be a formal framework that can be instantiated with
many form of compositions and many types of systems and
components. We hope this framework will include generic
rules and theorems about composition and logical specifications. The search for such fundamental rules, common
to any kind of composition, is an exciting problem. Then,
each instantiation enriches the framework with additional
rules that are specific to this instantiation, making it more
complete and more practically usable.
This can be achieved at different levels. At the most abstract
level, we can exhibit theorems about WE that allow us to reduce the calculation of WE.X using known WE.Y , where Y
is a part of X (for instance, using existential Y specifications). When this is possible, we can calculate WE.X inside
the logic in which X is expressed, which gives us the corresponding component specification. We were able to achieve
such calculations on toy examples [14], but we need more
theorems and rules related to WE and our other transformers to be able to conduct such calculations on examples from
more interesting domains. One difficulty when seeking such
properties of the transformers is to free ourselves from implicit assumptions regarding the law of composition. For
instance, we sometimes use concurrent composition of processes as a guideline to find general rules about the transformers, but we must be careful not to use an hypothesis
such as symmetry or idempotency which we decided not to
include systematically in our model.
Besides this theoretical part of the project, we are experimenting with several notations for the specification and verification of concurrent systems to see how they can be extended through our approach into compositional notations.
We hope, by modifying and extending existing notations,
to develop an interesting framework to reason about concurrent composition of reactive systems. Another aspect of
the problem is related to mechanization. We are investigating the question of the mechanization of guarantees through
a collaboration with Larry Paulson from the University of
Cambridge. Larry is currently working on a mechanization
of Unity [29] extended with guarantees [30] in the higherorder generic theorem prover Isabelle. His work is guided by
his attempts at mechanizing hand proofs from our example
involving distributed systems.
Another way to deal with the transformers is to first instantiate our framework with a specification language and
then to derive rules about WE.X, when X is expressed in
the chosen logical language (instead of using general theorems about WE). We have started this process with Unity
logic in order to build the necessary correctness proofs in
our examples with concurrent and distributed systems [9].
Furthermore, we also need to apply our approach to other
frameworks for the specification and verification of concurrent systems. This effort has already started, for instance
with CTL [32], but we want to consider other frameworks,
such as TLA or I/O-automata.
We are convinced that the future of software engineering is
tied to composition. Component-based designs and reuse of
generic components will be at the core of future software
systems. Composition involves a number of practical issues,
but also raises fundamental questions regarding component
specifications and compositional reasoning. We need to improve our understanding of composition if we want to be
able to devise the tools and principles that will allow us to
use components reliably and efficiently in software engineering. Our project has started an exploration of some of the
fundamental questions inherent in compositional design.
Recently, we have started to generalize our approach to systems in which several laws of composition are used at the
same time. An example of such a system is a software system in which components are composed sequentially and in
parallel. According to preliminary results, it seems that our
approach can still be applied. In other words, we are still
able to define weakest and strongest transformers that represent specific views on composition (independently, this time,
from existential and universal specifications). Furthermore,
the resulting predicate transformers bear strong similarities
with Dijkstra’s wlp and sp transformers for program seman-
47
7.
REFERENCES
[2] Martı́n Abadi and Leslie Lamport. Conjoining
specifications. ACM Transactions on Programming
Languages and Systems, 17(3):507–534, May 1995.
[13] Michel Charpentier and K. Mani Chandy. Reasoning
about composition using property transformers and
their conjugates. In J. van Leeuwen, O. Watanabe,
M. Hagiya, P.D. Mosses, and T. Ito, editors,
Theoretical Computer Science: Exploring New
Frontiers of Theoretical Informatics (IFIP-TCS’2000),
volume 1872 of Lecture Notes in Computer Science,
pages 580–595. Springer-Verlag, August 2000.
[3] Martı́n Abadi and Stephan Merz. An abstract account
of composition. In Jivrı́ Wiedermann and Petr Hajek,
editors, Mathematical Foundations of Computer
Science, volume 969 of Lecture Notes in Computer
Science, pages 499–508. Springer-Verlag, September
1995.
[14] Michel Charpentier and K. Mani Chandy. Theorems
about composition. In R. Backhouse and J. Nuno
Oliveira, editors, International Conference on
Mathematics of Program Construction (MPC’2000),
volume 1837 of Lecture Notes in Computer Science,
pages 167–186. Springer-Verlag, July 2000.
[4] Martı́n Abadi and Gordon Plotkin. A logical view of
composition. Theoretical Computer Science,
114(1):3–30, June 1993.
[15] Michel Charpentier and K. Mani Chandy.
Specification transformers: A predicate transformer
approach to composition. Submitted for publication,
July 2001.
[1] Martı́n Abadi and Leslie Lamport. Composing
specifications. ACM Transactions on Programming
Languages and Systems, 15(1):73–132, January 1993.
[5] K. Mani Chandy and Michel Charpentier. An
experiment in program composition and proof. Formal
Methods in System Design, April 1999. Accepted for
publication.
[16] Michel Charpentier, Mamoun Filali, Philippe Mauran,
Gérard Padiou, and Philippe Quéinnec. Abstracting
communication to reason about distributed
algorithms. In Ö. Babaoğlu and K. Marzullo, editors,
Tenth International Workshop on Distributed
Algorithms (WDAG’96), volume 1151 of Lecture Notes
in Computer Science, pages 89–104. Springer-Verlag,
October 1996.
[6] K. Mani Chandy and Michel Charpentier. Predicate
transformers for composition. In Jim Davies, Bill
Roscoe, and Jim Woodcock, editors, Millennial
Perspectives in Computer Science: proccedings of the
1999 Oxford-Microsoft symposium in honour of Sir
Tony Hoare, Cornerstones of Computing, pages 81–90.
Palgrave, 2000.
[7] K. Mani Chandy and Beverly Sanders. Reasoning
about program composition.
http://www.cise.ufl.edu/∼sanders/pubs/composition.ps.
[8] Michel Charpentier. Assistance à la Répartition de
Systèmes Réactifs. PhD thesis, Institut National
Polytechnique de Toulouse, France, November 1997.
[9] Michel Charpentier. Making Unity properties
compositional. Unpublished report, California
Institute of Technology, 1999.
[17] Michel Charpentier, Mamoun Filali, Philippe Mauran,
Gérard Padiou, and Philippe Quéinnec. The
observation: an abstract communication mechanism.
Parallel Processing Letters, 9(3):437–450, September
1999.
[18] Pierre Collette. Design of Compositional Proof
Systems Based on Assumption-Commitment
Specifications. Application to Unity. Doctoral thesis,
Faculté des Sciences Appliquées, Université
Catholique de Louvain, June 1994.
[19] Pierre Collette. An explanatory presentation of
composition rules for assumption-commitment
specifications. Information Processing Letters,
50:31–35, 1994.
[10] Michel Charpentier. A theory of composition
motivated by wp. Submitted for publication, August
2001.
[20] Pierre Collette and Edgar Knapp. Logical foundations
for compositional verification and development of
concurrent programs in Unity. In International
Conference on Algebraic Methodology and Software
Technology, volume 936 of Lecture Notes in Computer
Science, pages 353–367. Springer-Verlag, 1995.
[11] Michel Charpentier and K. Mani Chandy. Examples of
program composition illustrating the use of universal
properties. In J. Rolim, editor, International workshop
on Formal Methods for Parallel Programming: Theory
and Applications (FMPPTA’99), volume 1586 of
Lecture Notes in Computer Science, pages 1215–1227.
Springer-Verlag, April 1999.
[21] Pierre Collette and Edgar Knapp. A foundation for
modular reasoning about safety and progress
properties of state-based concurrent programs.
Theoretical Computer Science, 183:253–279, 1997.
[12] Michel Charpentier and K. Mani Chandy. Towards a
compositional approach to the design and verification
of distributed systems. In J. Wing, J. Woodcock, and
J. Davies, editors, World Congress on Formal Methods
in the Development of Computing Systems (FM’99),
(Vol. I), volume 1708 of Lecture Notes in Computer
Science, pages 570–589. Springer-Verlag, September
1999.
[22] Edsger W. Dijkstra and Carel S. Scholten. Predicate
calculus and program semantics. Texts and
monographs in computer science. Springer-Verlag,
1990.
[23] J.L. Fiadeiro and T. Maibaum. Verifying for reuse:
foundations of object-oriented system verification. In
48
I. Makie C. Hankin and R. Nagarajan, editors, Theory
and Formal Methods, pages 235–257. World Scientific
Publishing Company, 1995.
[24] Leslie Lamport. Composition: A way to make proofs
harder. In W.-P. de Roever, H. Langmaack, and
A. Pnueli, editors, Compositionality: The Significant
Difference (COMPOS’97), volume 1536 of Lecture
Notes in Computer Science, pages 402–423.
Springer-Verlag, September 1997.
[25] Zohar Manna and Amir Pnueli. The Temporal Logic of
Reactive and Concurrent Systems: Specification.
Springer-Verlag, 1992.
[26] R. Manohar and Paul Sivilotti. Composing processes
using modified rely-guarantee specifications. Technical
Report CS-TR-96-22, California Institute of
Technology, 1996.
[27] Jayadev Misra. A logic for concurrent programming:
Progress. Journal of Computer and Software
Engineering, 3(2):273–300, 1995.
[28] Jayadev Misra. A logic for concurrent programming:
Safety. Journal of Computer and Software
Engineering, 3(2):239–272, 1995.
[29] Lawrence C. Paulson. Mechanizing Unity in Isabelle.
ACM Transactions on Computational Logic, 1(1), July
2000.
[30] Lawrence C. Paulson. Mechanizing a theory of
program composition for Unity. ACM Transactions
on Computational Logic, 2001. To appear.
[31] Beverly A. Sanders. Eliminating the substitution
axiom from Unity logic. Formal Aspects of
Computing, 3(2):189–205, April–June 1991.
[32] Beverly A. Sanders and Hector Andrade. Model
checking for open systems. Submitted for publication,
2000.
[33] Paolo A. G. Sivilotti. A Method for the Specification,
Composition, and Testing of Distributed Object
Systems. PhD thesis, California Institute of
Technology, 256-80 Caltech, Pasadena, California
91125, December 1997.
[34] Rob T. Udink. Program Refinement in Unity-like
Environments. PhD thesis, Utrecht University,
September 1995.
49
Specification and Verification with References
Bruce W. Weide and Wayne D. Heym
Computer and Information Science
The Ohio State University
Columbus, OH 43210
+1-614-292-1517
{weide,heym}@cis.ohio-state.edu
ABSTRACT
Modern object-oriented programming languages demand that
component designers, specifiers, and clients deal with references. This is true despite the fact that some programming
language and formal methods researchers have been announcing for decades, in effect, that pointers/references are harmful
to the reasoning process. Their wise counsel to bury pointers/references as deeply as possible, or to eliminate them entirely, hasn’t been heeded. What can be done to reconcile the
practical need to program in the languages provided to us by
the commercial powers-that-be, with the need to reason
soundly about the behavior of component-based software systems? By directly comparing specifications for value and reference types, it is possible to assess the impact of visible
pointers/references. The issues involved are the added difficulty for clients in understanding component specifications,
and in reasoning about client program behavior. The conclusion is that making pointers/references visible to component
clients needlessly complicates specification and verification.
Categories and Subject Descriptors
D.2.1 [Requirements/Specifications]: Languages, Methodologies.
D.2.4 [Software/Program Verification]: Correctness proofs,
Formal methods, Programming by contract, Reliability.
General Terms
Design, Reliability, Languages, Verification.
Keywords
Java, Pointers, References, Specification, Verification.
1. INTRODUCTION
A well-known “folk theorem” in computing circles is that
nearly every problem can be solved with one more level of
indirection. Like most folklore, this claim is partially true—a
fact not lost on programming language designers, who have
consistently delivered not only computational models, but a
variety of language constructs, to help us more easily write
programs that use indirection.
The belief is a dangerous one, however, which has been noted
many times over the past few decades. Writing programs more
easily is one thing. Reasoning more easily about their behavior is quite another. As early as 1973, Tony Hoare remarked of
pointers that “their introduction into high-level languages has
been a step backward from which we may never recover” [10].
In 1976, Dick Kieburtz explained why we should be “programming without pointer variables” [15]. And in 1978, Steve
Cook’s seminal paper on the soundness and relative com-
50
pleteness of Hoare logic [3] identified aliasing (of arguments
to calls, i.e., even in a language without pointer variables) as
the key technical impediment to modular verification. There
have been recent papers (e.g., [19, 23]) showing how it is technically possible to overcome such problems, but apparently
only at the cost of even further complicating the programming
model that a language presents to a software engineer.
Why do we need another paper about this issue? The consequences of programming with pointers have been examined so
far primarily in the context of programming language design
and formal methods. We take a position in the context of the
human element of specification and verification:
Making pointers/references visible to component clients
needlessly complicates specification and verification.
In supporting this position, we rely in part on another, and far
older, bit of folklore: “Occam’s Razor”, a.k.a. the Law of Parsimony. It holds that simpler explanations of phenomena are
better than more complex ones. The phenomena of software
behavior are entirely of our own making, giving us ample opportunity to control the intellectual complexity and comprehensibility of specifications and reasoning based on them.
Throughout the paper (and with apologies to C++ gurus, as
noted in Section 5.1) the terms “pointer” and “reference” are
used interchangeably. The point, so to speak, is that from the
standpoint of specification and verification difficulties they
amount to the same thing. Code examples use Java notation.
The reader is also assumed to be familiar with the basis for
standard model-based specifications but not with any particular specification language; RESOLVE [27] is used for specification examples, but the notation is explained right here.
Section 2 discusses the difference between value and reference
variables, which might seem so well known as to go without
saying. (The reason for saying it anyway is detailed in Section
5.2.) Section 3 describes the serious impact of this distinction
on the complexity of behavioral specifications, and Section 4
describes the impact on modular verification. Section 5 discusses related work. Section 6 presents our conclusions.
2. VALUES VS. REFERENCES
Popular object-oriented languages, including C++, Eiffel, and
Java, share a bizarre feature. They create a dichotomy between
two kinds of types and, therefore, two kinds of variables:
•
Value variables, which stand for values of the built-in
types (value types) such as boolean, char, and int.
•
Reference variables, which stand for references to objects
whose values are of types (reference types) introduced
through interfaces and classes.
Why is this dichotomy “bizarre”? It clearly is not intuitive,
which is obvious if you have ever tried to explain and justify
it to students. Parsimony certainly suggests having only
value variables or only reference variables, not both.
Knowing Hoare’s hints on programming language design and
recognizing the elegance of some purely functional programming languages, the C++, Eiffel, and Java designers must have
preferred to have only value variables, all other things being
equal. But all other things are not equal. For one thing, there
is the folk theorem about indirection. In fact, the use of indirection is a little like the use of tobacco: an addictive bad
habit. Modern programming languages have contributed to
the problem by making indirection harder and harder to avoid
and programs using indirection easier and easier to write. Reference variables are everywhere in Java yet carry no syntactic
baggage at all! So surely it would be considered sacrilege to
remove easy indirection from any modern imperative language—even though the effect of indirection, when truly appropriate as it is occasionally, could be provided by a small
set of library components offering comparable power and performance profiles to language-provided pointers [12, 14].
Of course, tradition is not the reason these popular languages
distinguish between values and references. Language designers simply failed to discover another way to make programs
efficient in terms of execution time and storage usage [11].
Value variables can be represented with small chunks of storage that can easily be copied, leaving x and y completely independent in code following the assignment statement here:
int x;
int y;
...
y = x;
If user-defined types were value types that behaved like ints,
then this kind of code could be terribly inefficient. For example, suppose x and y were value variables in the following Java
code—remember they are not—and so would remain independent in code following the assignment statement:
SetOfInt x = new SetOfInt ();
SetOfInt y = new SetOfInt ();
...
y = x;
The assignment would then entail deep copying of a SetOfInt
object representation, which presumably would take time linear in the size of the set x. Overriding the assignment operator
to make a deep copy is recommended practice for C++ programmers who use the Standard Template Library [24], precisely because this leaves x and y independent of each other
following the assignment. The Java assignment operator, on
the other hand, cannot be overridden. An optional clone
method is supposed to make a deep copy (but it doesn’t, in
fact, even for the collections in the popular java.util package).
Having reference variables directly addresses the performance
problems involved in copying large data structures because:
•
the representations of all variables remain small, i.e., the
size of one pointer each, although every reference variable
still refers to an object whose representation is a potentially large data structure; and
•
the assignment statement is fast for both value and reference variables.
Most of the rest of this paper discusses the price paid for following this road to efficiency: complications in specification
and verification, and therefore in understanding and reasoning
51
about program behavior. The appendix (adapted from [14])
briefly explains the swapping paradigm, an alternative approach that permits the same efficiency to be achieved without
introducing references into the language model, specifications, or programmer reasoning. The purpose of the appendix
is to suggest that there are other solutions to the apparent reasoning vs. efficiency trade-off, i.e., that the choice is not limited to a pure functional programming paradigm (reasoning
over efficiency) or the standard object-oriented programming
paradigm (efficiency over reasoning).
3. IMPACT ON SPECIFICATION
Simply introducing reference types into a language model
makes it harder for clients to understand the specified behavior of components—if such behavior were carefully specified,
which in practice (e.g., Java component libraries) it is not.
This section illustrates the additional complication by describing a reference type in a model-based specification language, RESOLVE, that is designed for specifying value types
[27]. That is, there should be no syntactic sugar through
which the specification language might mask the fact that
there is a reference type. This approach allows an apples-toapples comparison of the underlying “intellectual load” introduced by value vs. reference types, both on component specifiers and on clients of those specifications.
Wouldn’t it be fair to (also?) select a specification language
that is designed to handle reference types, and use it to try to
specify value types? Not really. Variables in traditional
mathematics stand for values; they do not stand for references
to objects that have values. In other words, a hypothetical
specification language that is designed to hide references behind syntactic sugar must still, in the final analysis, “mean”
(i.e., have its semantics) in the domain of traditional mathematics. The verification conditions arising in correctness
proofs must be stated in traditional mathematics in order that
proofs can be carried out. “Desugaring” from references to
values is, therefore, ultimately required. It is only in the
desugared version of this hypothetical specification language
that we could really compare the relative difficulties values
and references pose for specification writers and readers.
3.1 Defining Mathematical Models for Types
Let’s start with a simple case: specifying the mathematical
model for a built-in value type. For example, for type int i n
Java the obvious mathematical model is a mathematical integer constrained to be within some bounds. In RESOLVE notation, this is expressed as follows:
type int is modeled by integer
exemplar i
constraint
-2147483648 <= i <= 2147483647
The exemplar clause introduces an arbitrary name for a prototypical variable of the new type, and the constraint clause is
an assertion that describes such a variable’s value space. So,
the meaning of this specification is that in reasoning about
Java code such as that shown earlier using int variables, you
should think of the values of x and y as being mathematical
integers like 1372 and –49 (i.e., not as strings of 32 bits).
3.1.1 Value Type Specification
A similar scenario arises for a type such as SetOfInt whose
mathematical model is more complex and whose representation is potentially large. For example, if SetOfInt were a value
type in the earlier Java code—remember it is not—then you
would want to think of the values of x and y as being sets of
numbers like {1, 34, 16, 13} and {2, –9, 45, 67, 15, 16, 942, 0}.
The mathematical model specification would look like this:
type SetOfInt is modeled by
finite set of integer
exemplar s
constraint
for all k: integer where (k is in s)
(-2147483648 <= k <= 2147483647)
initialization ensures
s = {}
The initialization clause says that when a new SetOfInt variable is declared, its value is the empty set.
3.1.2 Reference Type Specification
Unfortunately, life is not so simple in Java: SetOfInt is a reference type. In order to reason soundly about what your programs do, you must think of the values of x and y as being
references to objects whose values are sets of numbers like {1,
34, 16, 13} and {2, –9, 45, 67, 15, 16, 942, 0}. That is, the fact
that this is a reference type must be made explicit in the type’s
mathematical model specification. How can this be done?
Without syntactic sugar to hide references, the obvious approach (known to many others) is to model the mapping of
references to sets of integers as a mathematical function whose
scope is global to all SetOfInt variables. In RESOLVE, you can
say this using abstract state variables that may be accessed
and updated in (the specification of) any method associated
with any variable of the type being specified. An appropriate
mathematical model can be expressed as follows; there are
other ways to do it but this is the simplest one we know:
state variables
last: integer
objval: function from integer to
finite set of integer
constraint
for all r: integer
(for all k: integer
where (k is in objval(r))
(-2147483648 <= k <= 2147483647))
initialization ensures
for all r: integer (objval(r) = {})
in which case null is modeled by 0. Throughout the rest of
this paper, however, we ignore the possibility of null references. There are two reasons. First, we are trying to evaluate
how little additional trouble is necessarily entailed by having
reference types. Allowing null references only makes method
specifications messier, i.e., what happens for null and what
happens for non-null values of all the method parameters that
are of reference types. Second, it might be possible in principle to have a language in which there were reference types but
no null references. Java is used here for illustration, but we
don’t want to limit observations about reference types to Java.
The state variable objval is an abstraction of the mapping between references and the values of the objects they refer to.
Again, objval is an abstract mathematical variable, so there is
no problem that it (or, for that matter, last) has a value from a
mathematical domain that is manifestly too large to represent.
In this specification, we decided to initialize objval so every
possible reference is mapped to an empty set. The illusion is
that there is an infinite pool of objects whose values are empty
sets of integers, and that every time a new SetOfInt object is
constructed, one of these pre-formed objects is selected from
that pool. There are other ways to model the situation, of
course, but none is any simpler or cleaner when written out.
It is already evident that the mathematical machinery involved
in modeling the reference type is significantly more complex
than that needed to model the corresponding value type. But
this is only part of the problem; there remains the issue of
specifying the behavior of methods.
3.2 Defining Method Behavior
Let’s consider a method to add an int to a SetOfInt:
public void addInt (int i);
3.2.1 Value Type Specification
If SetOfInt were a value type in Java—remember it is
not—then the specification for addInt might look like this:
evaluates i
updates self
requires
i is not in self
ensures
self = #self union {i}
type SetOfInt is modeled by integer
exemplar s
initialization ensures
last = #last + 1 and
objval = #objval and
s = last
The state variable last is an abstraction of the address held in a
SetOfInt variable. Its purpose is to ensure that a newly constructed SetOfInt object is independent of all others. The starting value of last does not matter because, each time a new
SetOfInt object is constructed, the value of last is incremented
(“#” before a variable name denotes the old value). Since last
is an abstract variable, there is no need to worry about eventual
overflow.
The value null, however, is an annoying problem: there must
be some way to tell it apart from other values. This can be
handled in the above model with a minor change:
initialization ensures
last = 0 and ...
52
Before the precondition (requires clause) and the postcondition (ensures clause), the lists of variables classify each variable in scope as either unchanged (restores or evaluates list)
or potentially modified (updates or replaces list). “Restores”
means that the abstract value of the parameter undergoes no
net change from call to return, but it might be modified temporarily while the method is operating. Because i is passed by
value in Java, and the corresponding actual parameter is
treated as an expression, i is listed as having evaluates mode.
3.2.2 Reference Type Specification
Here is what happens because SetOfInt is really a reference type:
evaluates i
restores self, last
updates objval
requires
i is not in objval(self)
ensures
objval(self) = #objval(self) union {i} and
for all r: integer where (r /= self)
(objval(r) = #objval(r))
Note that self is not changed because it is a reference. But the
SetOfInt object it refers to has its value (i.e., objval(self))
changed. The last clause of the postcondition says that no
other SetOfInt object has its value changed.
All the other public methods for SetOfInt have specifications
with the same flavor as addInt. So, all of this is “boilerplate”:
ables. Of course, the only reason it does “the same thing” is
that the mathematical model for a reference type makes the
value of a reference variable explicit and distinct from the
value of the object it refers to. The assignment operator simply copies the value of the (value or reference) variable on the
right-hand side to that on the left-hand side.
4. IMPACT ON MODULAR VERIFICATION
restores self, last
updates objval
ensures
for all r: integer where (r /= self)
(objval(r) = #objval(r))
By making these oft-repeated specification clauses implicit
with a wave of the hand, it is possible to create a specification
language with enough syntactic sugar to simplify the look of a
specification for a reference type. In ESC/Modula-3 [19], for
example, variables not in a “modifies” list are preserved, and
the value of a referenced object (e.g., objval(self)) can be listed
as though it were a variable name, so the short version of the
above statements is (in RESOLVE-like syntax) just:
updates objval(self)
This does not materially change the intellectual task of understanding the meaning of the specification, however. And as
noted in Section 4, the underlying additional complication of
references reveals itself once you start relying on that specification to try to reason about client code that uses SetOfInt.
3.3 Assignment
It is instructive to specify the behavior of the Java assignment
operator, prototypically of the following form:
lhs = rhs;
3.3.1 Value Type Specification
If SetOfInt were a value type in Java—remember it is not—then
the specification would be:
evaluates rhs
replaces lhs
ensures
rhs = lhs
Note that the “=” in the specification is not itself an assignment operator, but denotes the assertion of ordinary mathematical equality between the mathematical models of lhs and
rhs. We have written “rhs = lhs” rather than the equivalent
“lhs = rhs” to emphasize this, any ambiguity being removed
by the specification that rhs is merely evaluated. The confusing use of “=” as an assignment operator is an unfortunate
design choice that crept from Fortran back into C after having
been nearly eradicated by “:=” in Algol-like languages.
3.3.2 Reference Type Specification
Interestingly, the assignment specification looks virtually
identical for SetOfInt as a reference type, the only difference
being that last and objval are also listed as being unchanged:
evaluates rhs
restores last, objval
replaces lhs
ensures
rhs = lhs
It is widely acknowledged that practical verification must be
modular, a.k.a. compositional. Factoring of the verification
task cuts along the lines of programming-by-contract [22].
That is, a component implementation is verified against its
specification once and for all, out of the context of the client
programs that might use it. The legitimacy of client use of a
component implementation is gauged during verification of
the client, based on knowledge of only the component specification, i.e., without “peeking inside” the separately-verified
component implementation and without reverifying any part
of it on a per-use basis.
The primary verification issue for software with references
stems from the possibility of aliasing: having two or more
references to the same object. Aliasing can arise either from
reference assignment (the case considered here) or from parameter-passing anomalies (the case Cook considered in his
study of Hoare logic [3]; see also [13, 17]). The challenge here
is to discover how the specification of SetOfInt in Section 3
might be used in modular verification of a client of SetOfInt, if
the client program could execute a reference assignment.
Let’s consider a relatively simple situation where the client
program is a main program having two “helper” operations P
and Q with specifications not shown:
import Section3.SetOfInt;
class Client {
private static void P (SetOfInt si) {
...
}
private static int Q (int i) {
...
}
public static void main (...) {
int j, k;
SetOfInt s1 = new SetOfInt();
SetOfInt s2 = new SetOfInt();
...
P(s1);
...
k = Q(j);
...
// point A
P(s2);
// point B
...
}
}
Suppose this program uses no other classes or constructs that
might cause modular verification problems, so the focus is
entirely on the impact of using SetOfInt. In other words, suppose main , P, and Q could be verified independently except for
any effects introduced by using SetOfInt.
4.1 Value Type Verification
Maybe there is some comfort in knowing that the assignment
operator does “the same thing” for value and reference vari-
53
If SetOfInt were a value type in Java—remember it is not—then
variables of this type could be passed from main to P without
fear that modularity might be compromised. The specification
of SetOfInt as a value type makes this clear. There are no state
variables in that specification and, consequently, no shared
state would be introduced among main , P, and Q as a result of
their common visibility over the SetOfInt class. For example,
suppose the intended behavior of P were this:
updates si
ensures
si = #si union {13}
You would be able to reason about the correctness of the body
of P independently of the bodies of main and Q because there
would be nothing P’s body could do to the values of any variables in the program other than the argument passed for the
formal si in a given call. The same would be true of the bodies
of main and Q. Reasoning would remain modular even with
this user-defined type in the picture—if it were a value type.
4.2 Reference Type Verification
In truth, SetOfInt is a reference type. But suppose, in a fit of
wishful thinking, you decided that it didn’t matter that much
and made the simplification of thinking of SetOfInt as a value
type. Given the specification above, you might expect P to
have the following body:
if (! si.contains (13)) {
si.addInt (13);
}
The problem with your thinking would be that P has visibility
over the reference type SetOfInt, including the abstract state
variables last and objval. Through them P might do other
things. For example, P might copy and save the reference s1
that main passes in the first call, and then quietly change objval(s1 ) through that alias during the next call. If you erroneously thought of SetOfInt as a value type, then it would seem
that the value of s1 changed spontaneously between the points
labeled “A” and “B” in main even though the variable s1 was
not even mentioned in the statement executed between them.
In reality, of course, what was changing was objval(s1 ); but by
hypothesis you were oblivious to the abstract state variable
objval and were thinking of si as a value variable— a “no-no”.
So, the following might be the body of P. It also seems to satisfy the specification above in terms of its effect on si , if you
treat si as a value variable and thereby ignore objval. Here,
Alias is a simple class with two static methods, saveTheAlias
and theAlias, which copy an Object reference and return the
copy, respectively. The point is that nowhere outside the body
of P is there even a hint that an alias is being kept inside it.
if (Alias.theAlias () != null) {
((SetOfInt) Alias.theAlias ()).clear ();
}
Alias.saveTheAlias (si);
if (! si.contains (13)) {
si.addInt (13);
}
In reasoning about the body of main , how could you predict
the strange behavior resulting from this code without examining the body of P—and thereby giving up modular reasoning?
The key to salvaging modularity is to realize that the specification of SetOfInt as a reference type involves two abstract
state variables, last and objval, that are visible throughout
main , P, and Q. From the reasoning standpoint, there are variables in this program that are global to main , P, and Q, although the syntax of Java does a great job of hiding them.
Now main still can be verified independently of P and Q despite sharing last and objval with them. The specifications of
54
P and Q simply must describe their effects on the abstract state
variables last and objval as well as on their explicit parameters. P’s specification should be changed to this:
evaluates si
restores last
updates objval
ensures
objval(si) = objval(#si) union {13}
for all r: integer where (r /= si)
(objval(r) = #objval(r))
and
Knowing only that P preserves last does not allow the verifier
of main to be sure that P cannot create an alias by copying si
and then changing the object value later. But the “nothing
else changes” clause in the postcondition prevents a correct
body for P from doing anything funny with an alias (like the
second body above) even if it saves one.
Another possibility is that maybe the above specification isn’t
really what is wanted! Perhaps the weird implementation of P
is correct according to the programmer’s intent, and the problem is specifying what P is supposed to do. Such a situation
also can be handled in this specification framework.
This example shows why it is critical for sound reasoning that
a programmer not imagine and/or hope that reference variables
are sort of like value variables. They aren’t.
Can Q be verified independently of main and P despite sharing
last and objval with them? Here, main and P can manipulate
last and objval by executing any series of SetOfInt method
calls. It turns out that Q cannot see the effects of those manipulations even if it declares and uses SetOfInt variables of
its own—and vice versa. But the basis for this claim is not
clearly evident from the specification of SetOfInt. It is a consequence of a special “non-interference” property that arises
from the way the SetOfInt specification uses the abstract state
variables: Neither of two methods declaring their own SetOfInt
variables but otherwise not communicating with each other
can detect changes that are made by the other to the abstract
state variables. So, curiously, Q can be verified independently
of main and P in this case even if its specification does not
include a “nothing else changes” clause.
5. RELATED WORK
Following the early papers cited in Section 1, there have been
some interesting recent episodes in the literature on programming language design, specification, and verification. They
suggest a fundamental struggle between acknowledging the
folklore about the importance and power of indirection, and
the reasoning problems arising from its use. We briefly review
two language designs, the cases of C++ and Java, in Sections
5.1 and 5.2, respectively. Other researchers have investigated
some of the specification and verification difficulties arising
from pointers. We briefly discuss their work in Section 5.3.
5.1 C++
C++ makes a distinction between pointers and references, as
explained by Bjarne Stroustrup, the creator of C++ [30]:
A reference is an alternative name for an object. The main
use of references is for specifying arguments and return
values for functions in general and for overloaded operators... [T]he value of a reference cannot be changed after
initialization; it always refers to the object it was initialized to denote.
That is, references were introduced into C++ primarily to simplify parameter passing and overload resolution. These programming language concerns had nothing to do with trying to
address the reasoning problems that arise from using pointers.
Indeed, C++ still has pointers, too.
Later, it became clear that this claim was a bit of an overstatement, or at least that it could be considered correct only in the
legalistic sense that Java does not have pointer syntax. Of
course, it has pointers almost everywhere, but it calls them
references. The potential for confusion was addressed by Sun
Microsystems itself in its on-line Java FAQ [31]:
The decision to complicate C++ by not only introducing references, but making them different from pointers in a rather subtle way, might seem to be another “step backward”. But other
language features combine with references to give the C++
programmer the flexibility to change the default programming
model from reference-oriented to value-oriented. That is, it
turns out it is quite possible in C++ to keep pointers and references from bubbling up through component (class) interfaces
where they must be faced by clients reading specifications and
verifying client code. One of these extra features is the ability
to override the assignment operator and copy constructor so
they make deep copies, not merely copies of references.
How can I program linked lists if there are no pointers?
[Answer:] Of all the misconceptions about the Java programming language, this is the most egregious. Far from
not having pointers, object-oriented programming is
conducted in the Java programming language exclusively
with pointers. In other words, objects are only ever accessed through pointers, never directly. The pointers are
termed “references” and they are automatically dereferenced for you.
“An object is a class instance or an array. The reference
values (often just references) are pointers to these objects.” Java Language Specification, section 4.3.1. [emphasis is in the original text]
The problem is that there is a performance penalty for making
deep copies, as discussed earlier. Luckily, the flexibility of
C++ does not stop there. It is also possible to make both the
assignment operator and copy constructor private, so they are
simply unavailable to clients of a class.
Any book that claims Java does not have pointers is inconsistent with the Java reference specification.
Interestingly, then, some of Hoare’s general advice about programming language design was heeded by the Java designers.
But his specific warning about pointers was ignored, early
claims to the contrary notwithstanding. By the way, what is
the correct answer to the FAQ question, “How do I program
linked lists?” You don’t; you use java.util.List, or similar.
We have taken advantage of the latter feature (and several others) to create a disciplined style of programming in C++, the
RESOLVE/C++ discipline [14, 33], in which adherence to many
rules of the discipline is compiler-checked by C++ itself. The
bottom line is that you can program in C++ using what are
technically reference variables yet maintain the illusion that
you have only value variables. To achieve this, we introduced
the swap operator [9] to replace the private assignment operator and copy constructor. Then we designed a large library of
class templates [25] whose formal specifications allow clients
to reason modularly about client code [14, 33]. The RESOLVE/C++ discipline has been shown to be rather easily understandable and usable by introductory CS students [20, 28,
29] and has been shown to result in dramatically good code
quality when used to build a commercial software system [14].
See the appendix for a brief discussion of the key idea behind
the discipline, i.e., the swapping paradigm.
5.3 Specification and Verification
In the 1970s, several researchers addressed pointer specification and verification in the context of the precursors to objectoriented languages, notably Pascal. The culmination of this
effort was reported in a 1979 paper by David Luckham and
Nori Suzuki [21], where the modeling of the state of memory
was made explicit in specifications and verification conditions in a slightly different way than we have done it. They
introduced a mapping from the reference variable’s textual
name, not its mathematical model value (integer in our case),
to the data value it pointed to. They would write the typespecific state variable we call objval in our example as
P#SetOfInt, for “pointer to SetOfInt”. Special notation also
was introduced for dereferencing a pointer-to-SetOfInt variable
s when writing assertions, i.e., P#SetOfInt⊂s ⊃.
5.2 Java
By the time Java was born, Sun Microsystems apparently
sensed that people were worried about the “safety” of their
programming languages. Thus, the conservatism of Java’s
design was heavily stressed. In the first paragraph of The Java
Language Specification, James Gosling, Bill Joy, and Guy
Steele wrote [7]:
An important missing ingredient in this early work—apparently because Pascal lacked user-defined types with hidden
representations—was any use of abstraction in explaining the
behavior of new types. For example, in our SetOfInt specification as a reference type, as a client you may think of objval(s)
as being a mathematical set of integers. In the Luckham/Suzuki style of specification, you would see not only the
top-level reference complication but the pointers to the nodes
in the (unhidden) data structure that represented the set. In
other words, in 1979 and in Pascal, client component specifications for user-defined types exhibited all the complexity of
specifications of reference types in Java, and then some. This
was technically acceptable from the formal standpoint of verification but could not be used to give a fair comparison between specifying reference types and specifying value types
because specifying reference types this way was even uglier
than it needed to be, with no simplifying abstractions.
Java is intended to be a production language, not a research language, and so, as C. A. R. Hoare suggested in his
classic paper on language design, the design of Java has
avoided including new and untested features.
Some of the early literature about Java also argued that it did
not have certain old and well tested but known-to-bedangerous features—like pointers. For example, consider this
passage written by Gosling and Henry McGilton in their 1996
white paper on The Java Language Environment [8]:
[P]ointers are one of the primary features that enable programmers to put bugs into their code. Given that structures are gone, and arrays and strings are objects, the need
for pointers to these constructs goes away. Thus the Java
language has no pointers.
55
In 1980, George Ernst and Bill Ogden [5] considered similar
specification and verification issues in Modula, which had a
module construct with hidden exported types. They, therefore,
needed to consider the question of how it was possible to hide
reference types behind abstract specifications. They showed it
was technically possible to hide references in module specifications through the use of some syntactic sugar in the specification language and an appropriate abstraction function in the
module implementation. But the complexity moved over the
horizon and into the proof rules:
the real programmers they are supposed to enable to deal with
references, and there is little evidence so far that this will be
easily achieved. In other words, despite impressive technical
advances that could contribute to the survival of reference
types in our languages, these ideas still need to be validated
against their ultimate objective: to become practically useful
and comprehensible by real programmers.
Of course, we also have published some prior work in this area
[13, 26, 32, 33, 34], including evidence of the comprehensibility and practical effectiveness of the RESOLVE discipline,
which simply eliminates reference types [14, 28]. And Manfred Broy, like us, has generally suggested designing components for ease of specification, as opposed to writing “postmortem” specifications for previously-designed components
[1]. This would suggest simply avoiding reference types: the
advice we’d get from Occam, too, were he still around.
The only conceptual difficulty with the verification rules
presented in this paper is that they do not prevent a procedure from side-effecting certain instances of abstract
types which are not parameters to a call on it... [T]o verify
a module, we must verify everything prescribed by the
rule ..., but we must also verify that the side-effecting ...
cannot occur. Developing such a rule is a non-trivial task
... beyond the scope of this paper.
To summarize, we were unable to find any work directly comparing the intellectual loads involved in specifying value
types vs. reference types, or using such analysis to compare
the difficulty in reasoning about client programs using them.
One problem with showing that “the side-effecting ... cannot
occur” is that it can occur according to the Modula language
definition by assignment of a reference variable; even worse,
some programmers want it to occur and write programs that
way, and these programs might be correct, as noted in the example of Section 4.2. This means that hiding the complexity
of references in a proof obligation stating that there is no aliasing causes a completeness problem.
6. CONCLUSIONS
Adding references types to value types, as in Java, significantly and needlessly complicates standard model-based
specifications and the modular verification they help enable.
Technically, everything can be made to “work” with reference
types. Reasonably concise and even plausibly comprehensible model-based specifications can be designed that account
for the behavioral peculiarities arising from references.
In 1994, Ernst and Ogden, along with Ray Hookway, published
a verification method for ADT realizations that handled
“shared realizations” [6], including heap storage. Their approach to modeling references was essentially identical to our
approach for reference types, with syntactic sugar hiding the
abstract state variables that recorded the “serial number” of the
last object constructed and the mapping from reference values
to data values. A value-type specification was possible, with
reference details arising only within the proof of the realization, because the only source of possible aliasing in the language was within realization code, i.e., not from client assignment of references. Moreover, the paper contained another
caveat about the example used for specification and verification with a shared realization:
By comparing the complexity of mathematical models and
method specifications in a language that has no syntactic
sugar to mask references, though, it becomes obvious that
reference types introduce a substantially greater intellectual
load than value types for both specifier and client. Writing
specifications for reference types suggests obvious ways in
which syntactic sugar can shorten the specifier’s typing time,
while still acknowledging a distinction between value types
and reference types. Yet it is unlikely that such sugaring can
in any way simplify the specifier’s thinking or the client’s
ability to understand the specified behavior of reference types.
The example does not use heap memory, because it would
require extensive use of pointers, which would unnecessarily complicate both specification and verification...
In general, modular verification remains possible in the face of
reference types if the abstract state variables needed to specify
a reference type are considered part of the state space of all
units that have visibility over that type. For verification purposes the abstract state variables used in specifying a reference
type can be treated like additional ghost parameters to all calls
involving one or more explicit parameters of that type. Reasoning is, of course, far more complicated with these extra
variables in the picture than it would be with value types only.
But technically you can still have modular verification with
reference types if there are no other language constructs that
thwart modularity.
So, the fundamental problem of how to verify programs with
reference types seems technically solvable by making sure that
the abstract state variables associated with reference variables
“follow them around” throughout the proof. Everyone seems
to agree that the introduction of references seriously complicates both specification and reasoning, though.
Other work that is directly related involves specification and
verification of standard object-oriented software, where reference types are considered something we just have to learn to
live with. The primary group in this area includes Gary Leavens, K. Rustan M. Leino, Peter Müller, and Arnd PoetzschHeffter, who have worked on similar issues both separately and
in combination. They have tackled the problem of specifying
behaviors of components involving pointers and references,
and have dealt with potential aliasing both from copying of
references and from parameter passing anomalies [4, 16, 17, 18,
19, 23]. Others (e.g., [2]) also have proposed ways to limit yet
not eliminate aliasing through clever linguistic mechanisms.
But these approaches have yet to be shown understandable by
It remains common practice to encode indirection in Fortran
by using arrays and integer indices as though they were dynamically-allocated storage pools and pointers into them.
These arrays and integers are passed among subroutines as
parameters, or sometimes placed in named common blocks that
are visible to a selected subset of the subroutines in a program.
All the subroutines that manipulate these arrays must agree on
how they are using them in order to work correctly together.
Over the years, programming language designers have simplified the syntax required to do this sort of thing, to the point
56
where in Java there is almost no syntax at all associated with
indirection. But the underlying logic of programming with
references in Java is the same as the logic of programming with
arrays and indices in Fortran.
[7] Gosling, J., Joy, B., and Steele, G. The Java Language Specification. Addison-Wesley, Reading, MA,
1996.
[8] Gosling, J., and McGilton, H. The Java Language
Environment: A White Paper. Sun Microsystems,
Inc., 1996; http://java.sun.com/docs/white/langenv/
viewed 8 August 2001.
[9] Harms, D.E., and Weide, B.W. Copying and swapping: Influences on the design of reusable software
components. IEEE Transactions on Software Engineering 17, 5 (1991), 424-435.
[10] Hoare, C.A.R. Hints on Programming Language Design. Stanford University Computer Science Department Technical Report No. CS-73-403, 1973. Reprinted in Programming Languages: A Grand Tour,
E. Horowitz, ed., Computer Science Press, Rockville,
MD, 1983, 31-40.
[11] Hogg, J., Lea, D., Holt, R., Wills, A., and de Champeaux, D. The Geneva convention on the treatment of
object aliasing. OOPS Messenger, April 1992.
http://gee.cs.oswego.edu/dl/aliasing/aliasing.html
viewed 8 August 2001.
[12] Hollingsworth, J.E. and Weide, B.W. Engineering
‘unbounded’ reusable Ada generics. In Proceedings of
10th Annual National Conference on Ada Technology,
1992, ANCOST, 82-97.
[13] Hollingsworth, J.E. Uncontrolled reference semantics
thwart local certifiability. In Proceedings of the Sixth
Annual Workshop on Software Reuse, 1993.
[14] Hollingsworth, J.E., Blankenship, L., and Weide,
B.W. Experience report: Using RESOLVE/C++ for
commercial software. In Proceedings of the ACM
SIGSOFT Eighth International Symposium on the
Foundations of Software Engineering, 2000, ACM
Press, 11-19.
[15] Kieburtz, R.B. Programming without pointer variables. In Proceedings of the SIGPLAN '76 Conference
on Data: Abstraction, Definition and Structure, 1976.
ACM Press.
[16] Leavens, G.T., and Cheon, Y. Extending CORBA
IDL to specify behavior with Larch. In OOPSLA '93
Workshop Proceedings: Specification of Behavioral
Semantics in OO Information Modeling, 77-80; also
TR #93-20, Department of Computer Science, Iowa
State University, Ames, IA, 1993.
[17] Leavens, G.T., and Antropova, O. ACL — Eliminating Parameter Aliasing with Dynamic Dispatch. TR
#98-08a, Department of Computer Science, Iowa State
University, Ames, IA, 1998.
[18] Leavens, G. T., Baker, A. L., and Ruby, C. JML: A
notation for detailed design. In Behavioral Specifications of Businesses and Systems, eds. H. Kilov, B.
Rumpe, and I. Simmonds, Kluwer Academic Publishers, Boston, MA, 1999.
Is it, then, a good idea to hide the sharing of global state by
making such language “advances”? This sharing is clearly
evident in Fortran programs, but not in Java programs. But
shared state introduced through references can remain hidden
only from the minds of programmers who program without
specifications and who never try to verify their programs. If
specification language designers try to take the same road then
they, too, will find they can hide this shared state only from
the minds of programmers who never try to verify programs.
Eventually, the emperor’s thin disguise will reveal itself to
all—although perhaps not before some catastrophic software
failures cause more people to take a serious look at whether
programming languages should offer constructs that are so
well known to complicate specification and verification.
7. ACKNOWLEDGMENTS
Murali Sitaraman and Gary Leavens and their students, as well
as the members of the OSU Reusable Software Research Group,
have provided much food for thought through various personal and electronic discussions of some of the issues mentioned here. Scott Pike and the anonymous referees helped in
many other ways, too, especially by suggesting how to focus
the paper on its real thesis.
We gratefully acknowledge financial support from the National Science Foundation under grant CCR-0081596, and
from Lucent Technologies. Any opinions, findings, and conclusions or recommendations expressed in this paper are those
of the author and do not necessarily reflect the views of the
National Science Foundation or Lucent.
8. REFERENCES
[1] Broy, M. Experiences with Software Specification
and Verification Using LP, the Larch Proof Assistant. Research Report 93, Compaq Systems Research
Center, Palo Alto, CA, 1992.
[2] Clarke, D.G., Potter, J.M., and Noble, J. Ownership
types for flexible alias protection. In OOPSLA '98
Conference Proceedings, ACM Press, 1998, 48-64.
[3] Cook, S.A. Soundness and completeness of an axiom
system for program verification. SIAM Journal of
Computing 7, 1 (1978), 70-90.
[4] Egle, R. Evaluating Larch/C++ as a Specification
Language: A Case Study Using the Microsoft Foundation Class Library. TR #95-17, Department of Computer Science, Iowa State University, Ames, IA, 1995.
[5] Ernst, G.W., and Ogden, W.F. Specification of abstract data types in MODULA. ACM Transactions on
Programming Languages and Systems 2, 4 (1980),
522-543.
[6] Ernst, G.W., Hookway, R.J., and Ogden, W.F. Modular verification of data abstractions with shared realizations. IEEE Transactions on Software Engineering
20, 4 (1994), 288-207.
57
[19] Leino, K.R.M., and Nelson, G. Data Abstraction and
Information Hiding. Compaq SRC Rep. #160, 2000.
[20] Long, T.J., Weide, B. W., Bucci, P., Gibson, D. S.,
Hollingsworth, J., Sitaraman, M., and Edwards, S.
Providing intellectual focus to CS1/CS2. In Proceedings of the 29th SIGCSE Technical Symposium on
Computer Science Education, 1998, ACM Press, 252256.
[21] Luckham, D.C., and Suzuki, N. Verification of array,
record, and pointer operations in Pascal. ACM Transactions on Programming Languages and Systems 1, 2
(1979), 226-244.
[22] Meyer, B. Object-oriented Software Construction.
Prentice-Hall, New York, 1988; second edition, 1997.
[23] Müller, P., and Poetzsch-Heffter, A. Modular specification and verification techniques for object-oriented
software components. In Foundations of ComponentBased Systems, eds. G.T. Leavens and M. Sitaraman,
Cambridge University Press, 2000, 137-159.
[24] Musser, D.R., Derge, G.J., and Saini, A. STL Tutorial and Reference Guide, Second Edition. AddisonWesley, Upper Saddle River, NJ, 2001.
[25] RESOLVE/C++ Component Catalog Home Page.
http://www.cis.ohiostate.edu/~weide/sce/rcpp/RESOLVE_Catalog-HTML
viewed 8 August 2001.
[26] Sitaraman, M., Atkinson, S., Kulczycki, G., Weide,
B.W., Long, T.J., Bucci, P., Heym, W., Pike, S., and
Hollingsworth, J.E. Reasoning about softwarecomponent behavior. In Software Reuse: Advances in
Software Reusability (Proceedings Sixth International
Conference on Software Reuse), LNCS 1844, ed. W.
Frakes, 2000, Springer-Verlag, 266-283.
[27] Sitaraman, M., and Weide, B.W. Component-based
software using RESOLVE. ACM SIGSOFT Software
Engineering Notes 19, 4 (1994), 21-67.
[28] Sitaraman, M., Long, T.J., Weide, B.W., Harner, J.,
and Wang, C. A formal approach to component-based
software engineering: education and evaluation. In
Proceedings 2001 International Conference on Software Engineering, 2001, IEEE, 601-609.
[29] Software Component Engineering Course Home Page.
http://www.cis.ohio-state.edu/~weide/sce/now viewed
8 August 2001.
[30] Stroustrup, B. The C++ Programming Language, 3rd
edition. Addison-Wesley, Reading, MA, 1997.
[31] Sun Microsystems, Java “Frequently Asked Questions”. http://java.sun.com/people/linden/faq_b.html
viewed 8 August 2001.
[32] Weide, B.W., Edwards, S.H., Harms, D.E., and
Lamb, D.A. Design and specification of iterators using the swapping paradigm. IEEE Transactions on
Software Engineering 20, 8 (1994), 631-643.
[33] Weide, B.W. Software Component Engineering.
OSU Reprographics, Columbus, OH, 1996.
[34] Weide, B.W. “Modular regression testing”: Connections to component-based software. In Proceedings
Fourth ICSE Workshop on Component-Based Software Engineering, 2001, IEEE, 47-51.
9. APPENDIX: THE SWAPPING PARADIGM
How do you make some variable (say, y) get the value of another variable (say, x)? For example, suppose x and y are variables of type int, a value type whose mathematical model is a
mathematical integer, as discussed in Section 3.1. Obviously,
you use an assignment statement:
y = x;
What if x and y are variables of a value type VT, where VT’s
mathematical model is relatively complex and its representation data structure is probably large? Suppose, for example,
that VT is SetOfInt, whose mathematical model is a mathematical set of mathematical integers, as discussed in Section 3.1.1.
There are now two options for data movement, neither of which
is especially attractive:
1.
Consider the assignment operator for SetOfInt to perform
deep copy, so that after the assignment statement we can
think of both x and y as having the same abstract value.
Logically, x and y must behave independently, too, so
changes to x do not side-effect the value of y and vice
versa. This can be terribly inefficient, because without using fancy data-structure-specific tricks that frequently do
not apply, the assignment operator must take time linear
in the size of x’s representation. Big sets simply take a
long time to copy and hence to assign.
2.
Do not view x and y as value variables, but as reference
variables; i.e., change their type from value type VT to reference type RT, and think of x and y as references to objects whose values are sets of integers. This fixes the efficiency problem but at the cost of a distressing nonuniformity in reasoning about program behavior: Some
variables denote values and others denote references. It
also means that the assignment operator creates aliases,
which complicates formal specification and reasoning
about program behavior, as explained in Section 4.2.
Approach #2 has been codified into most modern languages,
notably Java. It is actually far worse than #1 from certain
software engineering standpoints. One reason is that the programmer now must be aware that variables of some types have
ordinary values while variables of other types hold references
to objects (it’s the objects that have the values). For template
components this creates a special problem. Inside a component that is parameterized by a type Item, there is no way to
know before instantiation time whether an assignment of one
Item to another will assign a value or a reference. Of course,
this can be “fixed” as it is in Java, by introducing otherwiseredundant reference types such as Integer to wrap value types
such as int. Actual template parameters can then be limited to
reference types. This is really ugly, though. And there is still
the issue of the complication caused by references for specification and verification, as seen in Sections 3 and 4.
Figure 1 summarizes the data movement dilemma faced by
someone who wants efficient software about whose behavior it
is easy to reason. The conclusion is that this is only attainable
58
by sticking to built-in value types—not incidentally, the only
types available when the assignment operator was introduced
into programming languages—or, at best, by inventing only
new user-defined types that admit “small” representations.
swapped with x. Swapping simultaneously puts the old value
of x into the Set’s representation data structure, where it needs
to be; and sets the new value of x to the initial value for its
type that was originally in the data field of the node.
What if there are no pointers in the language, though? In an
implementation of the Set component that is layered on top of
a provided List component, for example, the add operation
simply inserts x at the appropriate place into the List that represents the Set. If the insertion operation for List also is designed using the swapping paradigm, so it consumes its argument just like add does, then this call does exactly what is
needed.
What does “y = x;” do?
makes a deep copy
copies a reference
How big is x’s representation?
small
alias
In other words, in both these situations, the code that you
would have written if using assignment for data movement is
changed in just one respect: assignment of x to its place in the
Set’s representation is replaced by swapping x with its place in
the Set’s representation.
large
OK
Our experience is that a family of components such as those in
the RESOLVE/C++ component catalog [25] can be designed
according to the swapping paradigm to compose in such a way
that programming with swapping is substantially similar to
programming with assignment statements. But the resulting
components offer efficiency and/or reasoning advantages over
similar components designed in a traditional fashion.
slow
Figure 1: The Data Movement Dilemma
Again, how do you make some variable (say, y) get the value of
another variable (say, x)? There is no inherent requirement that
the value of x must not change as a result of the data movement
process. Realizing this opens the door to other possibilities.
The new value of y must be the old value of x, but the new
value of x might be:
•
the old value of x (to get this behavior we use assignment,
which works well if x’s representation is small); or
•
undefined; or
•
a defined, but arbitrary and unknown, value of its type; or
•
some particular value of its type, e.g., an initial value; or
•
the old value of y.
Let’s be clear that we still use the assignment operator with
built-in value types. There is nothing wrong with the following statement from either the efficiency or reasoning standpoints, assuming that x and y are variables of some value type
with a “small” representation:
y = x;
The possibly surprising empirical observation that has been
substantiated by commercial application development is that,
with swapping, there is rarely a need for such a statement when
x and y have user-defined types. You can have value types and
efficiency at the same time.
It is beyond the scope of this appendix to analyze the pros and
cons of all the possibilities beyond the first one, which is unsatisfactory as a general approach to data movement. Suffice
to say that leaving x undefined complicates reasoning, although not nearly as much as allowing aliasing; and that leaving x with either an arbitrary or a distinguished value of its
type is actually quite a reasonable thing to do. However, the
last approach— swapping the values of x and y—is both efficient and safe with respect to modular reasoning, and it results
in remarkably few changes to how most programmers write
imperative code [9, 33].
The main advantages of the swapping paradigm are, then:
You need to get used to a few new idioms when adopting the
swapping paradigm, e.g., for iterating through a collection
[32]. The biggest effect of the swapping paradigm, however, is
on the design of component interfaces. Consider, for example,
a Set component (parameterized by the Item type it contains)
with operations add, remove, etc. What should add(x) do to
the value of x? The analysis of this question parallels the
analysis of the data movement dilemma as the question was
phrased above. The conclusion is that add should consume x,
i.e., it should leave x with an initial value of its type.
•
The swapping paradigm is easy for imperative-language
programmers to learn and apply.
•
All types are value types, which allows for understanding
of specifications and modular reasoning that are complicated significantly if reference types creep in.
•
All pointers and references can be hidden deep within the
bowels of a few low-level components and remain invisible to a client programmer layering new code on top of
them.
•
If these low-level components have no storage leaks, then
client programs have no storage leaks, and client programmers do not have to worry about where to invoke delete in, e.g., C++, because they simply never invoke it. In
the case of a garbage-collected language, e.g., Java, there
is no need for the complications of general garbage collection because there are no aliases and all collection
takes place at predictable times.
Other questions often asked about the interactions between the
swapping paradigm and other programming language and
software engineering issues, such as the role of function operations, assignment of function results to variables, parameter
passing, etc., are discussed in [9].
How can this be accomplished? A direct implementation of the
Set component declares a new variable of the parametric type
Item in the body of add, e.g., the data field in a new node that is
to be inserted in a linked list of nodes. This variable is then
59
Modular Verification of Performance Correctness
Joan Krone
Dept. Math. and Comp. Science
Denison University
Granville, OH 43023, USA
+1 740 587 6484
[email protected]
William F. Ogden
Murali Sitaraman
Dept. Comp. & Info. Science
The Ohio State Universtiy
Columbus, OH 43210, USA
+1 614-292-5813
[email protected]
Dept. Comp. Science
Clemson University
Clemson, SC 29634, USA
+1 864 656 3444
[email protected]
Woodside note the importance of the performance problem in
their guest editorial on Software and Performance [21]:
“Performance is a problem in many software
development projects and anecdotal evidence suggests
that it is one of the principal reasons behind cases
where projects fail totally. There is a disconnect
between techniques being developed for software
analysis and design and the techniques that are
available for performance analysis.”
Abstract
Component-based software engineering is concerned with
predictability in both functional and performance behavior,
though most formal techniques have typically focused their
attention on the former. The objective of this paper is to present
specification-based proof rules compositional or modular
verification of performance in addition to functionality,
addressing both time and space constraints. The modularity of
the system makes it possible to verify performance correctness
of a module or procedure locally, relative to the procedure itself.
The proposed rules can be automated and are intended to serve
as part of a system of rules that accommodate a language
sufficiently powerful to support component-based, objectoriented software.
Measurement during execution (e.g., using run-time monitoring)
is a common approach for analyzing performance of large-scale
systems [21]. The objective of this paper is to present static
analysis (and hence, a priori prediction) as an alternative to
measurement. In particular, the focus is on modular or
compositional performance reasoning: Reasoning about the
(functionality and performance) behavior of a system using the
(functionality and performance) specifications of the
components of the system, without a need to examine or
otherwise analyze the implementations of those components
[17].
Categories and Subject Descriptors
D.2.13 [Software Engineering]: formal specification and
verification of software performance.
General Terms
Verification, assertive language, formal specifications.
Compositionality is essential for all analysis, including time and
space analysis, to scale up.
To facilitate compositional
performance reasoning, we have introduced notations for
performance specifications elsewhere [18]. Given functionality
and performance specifications (and other internal assertions
such as invariants), the rest of this paper describes a proof
system for modular verification. Section II sets up the
framework to facilitate automated application of rules, using a
simple example rule. Section III contains proof rules for
verification of procedure bodies and procedure calls, involving
possibly generic objects with abstract models as parameters.
Section IV contains an example to illustrate a variety of issues
involved in formal verification. Section V has a discussion of
related work and summary.
Keywords
Proof rule, performance, time and space.
1. INTRODUCTION
Predictability is a fundamental goal of all engineering, including
software engineering. To show that a program predictably
provides specified functional behavior, a variety of ways to
apply a system of proof rules to a program for proving
functional correctness have been studied since Hoare’s work.
More recent efforts address the special challenge of modular
reasoning for object oriented, component based software [1, 5,
8, 9, 12]. These systems depend on programmer-supplied
assertions that serve as formal specifications for the functional
behavior of the software. While correct functional behavior is
critical to any software system, in order to achieve full
predictability, we must ultimately address the issue of
performance as well.
2. ELEMENTS OF THE PROOF SYSTEM
Though the underlying principles presented in this paper are
language-independent and are applicable to any assertive
language that includes syntactic slots for specifications and
internal assertions, to make the ideas concrete we use the
RESOLVE notation [15, 16]. RESOLVE is intended for
predictable component-based software engineering and it
includes notations for writing specifications of generic
components that permit multiple realizations (implementations)
of those components. It also includes notations for specifying
time and space behaviors of an implementation.
The
implementations include programmer-supplied representation
A program that carries out the right job, but takes longer than
available time to complete is of limited value, especially in
modern embedded systems. Similarly, a program that is
functionally correct, but that requires more space than the
system can provide is not useful either. Cheng, Clemens, and
60
invariants, loop invariants, progress metrics, and other assertions
depending on the structure.
verifier. Similarly, the verifier would simply continue backing
through the rest of the code, applying appropriate proof rules,
eliminating one more constructs in each step.
The proof rules have been designed so that an automated clause
generator can start at the end of a given assertive program and
back over the code replacing the executable language constructs
with assertions about the mathematical domain over which the
program has been written. The clause generator produces a
clause that is equivalent to the correctness of the given program.
The clause can then be evaluated manually, automatically by a
theorem prover, or by a combination to determine whether the
clause is provable in the appropriate mathematical domain, and
thereby whether the program is correct (with respect to its
specification). To illustrate the ideas, we begin with a simple
example. First we consider functional behavior and then address
performance for the following piece of assertive code:
Now we augment the above rule to prove functional correctness,
with performance-related assertions. Suppose we need to prove
the correctness of the following assertive code:
Assume x = 3 ^ Cum_Dur = 0 ^ Prior_Max_Aug = 0 ^
Cur_Aug = 0;
x = x + 1;
Confirm x = 4 ^ Cum_Dur + 0.0 = D:= + DInt_+ ^
Max(Prior_Max_Aug, Cur_Aug + 0 ) ≤ S:=1;
Here, D:= denotes the duration for expression assignment2
(excluding the time to evaluate the expression itself). S:=
denotes storage space requirement for expression assignment
(excluding the storage space needed to evaluate the expression
itself and the storage for variable declaration of x which is
outside the above code). The units for time and space are
assumed to be consistent, though we make no assumptions about
the units themselves. The rest of the terms (whose need may not
become fully clear until after the discussion of procedures in
Section III) are explained in the context of the following rule for
expression assignment:
Assume x = 3;
x := x + 1;
Confirm x = 4;
Exactly how such an assertive code comes into place, given a
specification and an implementation, is explained in Section III.
In this code segment, the programmer has supplied a precondition indicated by the Assume keyword and a postcondition following the keyword Confirm with some (assertive)
code in between. To prove the correctness of this segment,
consider the following automatable proof rule for expression
assignment:
C \ Code; Evaluate(exp); Confirm ( Outcome_Exp ∧
Cum_Dur + D:= + Sqnt_Dur_Exp ≤ Dur_Bd_Exp∧
Max( Prior_Max_Aug, Cur_Aug + S:= +
Fut_Sup_Disp_Exp ) ≤ Aug_Bd_Exp) )
C \ Code; Evaluate (exp); Confirm Outcome_Exp[x ⇝
M_Exp(exp) ]
___________________________________________
C \ Code; x := exp; Confirm Outcome_Exp;
[x⇝M_Exp(exp)];
──────────────────────────
C \ Code; x := exp; Confirm Outcome_Exp ∧ Cum_Dur +
Sqnt_Dur_Exp ≤ Dur_Bd_Exp ∧
Max( Prior_Max_Aug, Cur_Aug + Fut_Sup_Disp_Exp ) ≤
Aug_Bd_Exp;
In this rule, C on the left side of both the hypothesis and the
conclusion stands for Context and it denotes the collection of
whatever information is needed about the code in order to reason
about its correctness. For example, the types of variables and
the mathematical theories on which those types are based would
be in the context.
The new rule includes everything needed for functional
correctness, and also includes new clauses about time and space
performance. In spite of past attempts in the literature, it is just
not possible to develop rules for performance correctness
independently of functional correctness, because in general,
performance depends on values of variables (which come from
analyzing functional behavior) [17, 18]. In the example and in
the rule, terms in bold print are keywords and the terms ending
with “_Exp” represent expressions to be supplied by the
programmer and kept up to date by the verifier.
In our example, the Outcome_Exp is “x = 4.” The Code
preceding the assignment is the assertion “Assume x = 3.” In
the assertive clauses, the 3 and 4 are the mathematical integers,
while the assignment statement is performing an increment on a
computer representation of an integer. (The use of mathematical
integers in specifying computational Integer operations is
documented in Integer_Template that specifies Integer objects
and operations, and it is assumed to be in the context.)
1
We have added terms “+ 0.0” and “+ 0” in the expressions
here so that it is easy to match the syntactic structure of the rule
given next.
2
In RESOLVE, the right hand side of an assignment statement
is restricted to be an expression. In particular, x := y is not
allowed on variables of arbitrary types. For copying y to x, the
assignment statement needs to be x := Replica(y). This
interpretation is implicit for (easily) replicable objects such as
Integers for programming convenience. This is what justifies
the time analysis in the present rule. To move the value of y to x
efficiently on all objects large and small, and without
introducing aliasing, RESOLVE supports swapping (denoted by
“:=:”) as the built-in data movement operation on all objects [3].
Applying the proof rule on the example leads to the following
assertive code:
Assume x = 3; Evaluate(x + 1); Confirm x + 1 = 4.
This is the result of substituting the expression “x + 1” for x, the
meaning of [x ⇝ M_Exp(exp)]. M_Exp denotes putting in the
mathematical expression that corresponds to the programming
expression, thus keeping our assertions over mathematical
entities, rather than programming ones. There is a rule for
Evaluate that causes the expression to be evaluated by the
61
3. PROCEDURES
First we consider timing. The keyword Cum_Dur suggests
cumulative duration. At the beginning of a program the
cumulative duration would be zero. As the program executes,
the duration increases as each construct requires some amount of
time to complete. The programmer supplies an over all duration
bound expression, noted by Dur_Bd_Exp. This is some
expression over variables of the program that indicates an
amount of time acceptable for the completion of the program.
As the verifier automatically steps backward through the code,
that expression gets updated with proper variable substitutions
as the proof rules indicate.
We examine a more complicated procedure construct in this
section, having introduced basic terminology using the
expression assignment proof rule. We present a rule for
procedure declarations and one for procedure calls. These rules
apply not only to ordinary code when all variables and types are
previously defined, but to generic code as well, i.e., code written
for variables that have not yet been tied to a particular type or
value. This capability to handle generic code is critical for
reusable, object-based components.
3.1 Procedure Declaration Rule
For example, in the above rule, when the verifier steps backward
over an assignment, the variable, “x,” receiving the assignment
is replaced by the mathematical form of the given expression,
“exp,” in all of the expressions included within the parentheses.
Associated with every procedure is a heading that includes the
name, the parameter list, and assertions that describe both
functional and performance behavior:
Sqnt_Dur_Exp stands for the subsequent duration expression,
an expression for how much time the program will take starting
at this point. This expression is updated also automatically by
the verifier, along with other expressions in the rule.
P_Heading:
Operation P(updates x: T);
requires P_Usg_Exp/ x \;
ensures P_Rslt_Exp/ x, #x \;
duration Dur_Exp/ x, #x \;
manip_disp M_D_Exp/ x, #x \;
The duration (timing) for a program is clearly an accumulative
value, i.e., each new construct simply adds additional duration to
what was already present. On the other hand, storage space is
not a simple additive quantity. As a program executes, the
declaration of new variables will cause sudden, possibly sharp,
increases in amount of space needed by the program. At the end
of any given block, depending on memory management, storage
space for variables local to the block, may be returned to some
common storage facility, causing a possibly sharp decrease in
space.
This heading is a formal specification for procedure P. We use
separate keywords Operation to denote the specification and
Procedure to denote executable code that purports to implement
an operation. We have included only one parameter on the
argument list, but of course, if there were more, they would be
treated according to whatever parameter mode were to be
indicated. The updates mode means that the variable is to be
updated, i.e., possibly changed during execution.
The right operation for duration is addition and for storage it
turns out to be taking the maximum over any given block. It is
reasonable to assume that for any given program, there will be a
certain amount of space needed for getting the program started.
This will include the program code itself, since the code will
reside in memory. Assuming real, rather than virtual memory,
the code will take up a fixed amount of space throughout the
execution. With this in mind, we think of some fixed amount of
space for any given program that remains in use throughout the
execution. Our rules are written to deal with the space that
augments the fixed storage and increases and decreases as the
program executes. Prior_Max_Aug stands for “prior maximum
augmentation” of space. At the beginning of any program, the
prior maximum will be zero, since only the fixed storage is in
use. As the program executes, over each block, a maximum of
storage for that block is taken to be the Prior_Max_Aug. At
any point in the program, there will be a storage amount over the
fixed storage. We call that the current augmentation of space,
Cur_Aug. Of course, there will be some overall storage bound
to represent what is acceptable. We call that the augmentation
bound expression, Aug_Bd_Exp. Finally, just as there was an
expression to represent how much additional time would be
needed, there is an expression for how much storage
(displacement) will be needed in the future, the future
supplementary
displacement
expression,
Fut_Sup_Disp_Exp.
In the heading, the type T may be a type already pinned down in
the program elsewhere, or it might represent a generic type that
remains abstract at this point. The requires and ensures clauses
are pre and post conditions respectively for the behavior of the
operation, and the angle brackets hold arguments on which the
clauses might be dependent. Due to page constraints, the rule
does not include other potential dependencies such as on global
variables.
Details of performance specification are given in [18].
Duration is the keyword for timing.
Dur_Exp is a
programmer-supplied expression that describes how much time
the procedure may take. That expression may be given in terms
of other procedures that P calls and it may be phrased in terms
of the variables that the operation is designed to affect. We may
need to refer both to the incoming value of x and to the resulting
value of x in these clauses. We distinguish them by using #x
for the value of x at the beginning of the procedure and x as the
updated value when the procedure has completed. The last part
of the Operation heading involves storage specification. Here,
manip_disp (termed trans_disp in [18]) suggests manipulation
displacement, i.e., how much space the procedure may
manipulate as it executes.
62
Given the operation heading, we next consider a rule for a
procedure declaration to implement an operation.
3.2 Procedure Call Rule
A picture serves to motivate space-related assertions in the
procedure call rule. The timing aspects of the rule are more
straightforward and they are not shown in this picture.
C ∪ {P_Heading} \ Assume P_Usg_Exp ∧
Cur_Dur = 0.0 ∧
Prior_Max_Aug = Cur_Aug = Disp(x);
P_Body;
Confirm P_Rslt_Exp ∧ Cur_Dur + 0.0 ≤
Dur_Exp ∧
Max( Prior_Max_Aug, Cur_Aug + 0) ≤ M_D_Exp;
C ∪ {P_Heading} \ Code; Confirm Outcome_Exp;
─────────────────────────────────
C \ P_Heading; Procedure P_Body; end P;
Code; Confirm Outcome_Exp;
As in the assignment rule, C stands for the context in which the
procedure occurs. Note that P_Heading, the specification of
Operation P, is added to the context making it possible for
reasoning about the procedure to take place. The conclusion
line of the rule allows the procedure declaration to be made and
followed by some code and a clause to confirm after the code.
The hypotheses of the rule indicate that the procedure is to be
examined abstractly, proving that no matter what value for the
parameter is passed in, the result will satisfy both the functional
and performance requirements.
Along the lower part of the picture the “fixed displacement”
represents some amount of storage necessary for the program to
run, an amount that does not vary throughout execution. The
code itself is included in this fixed storage. Above the fixed
storage the execution of the code requires a fluctuating amount
of space, increasing when storage for new variables is allocated
and decreasing when it is released.
The first hypothesis checks functional behavior by showing that
if the requires clause is met, then the ensures clause is satisfied
upon completion of the procedure body. For timing, we set the
Cum_Dur to 0 thereby localizing the proof to just this
procedure, avoiding the pitfall of having to consider the entire
program when proving correctness for just this procedure. After
the procedure body, we confirm that the Cum_Dur remains
below Dur_Exp, the bound expression given in the
specifications. It is assumed that the Cum_Dur acts like an
auxiliary variable updated automatically at each step.
The auxiliary variable, Cur_Aug, represents at any point what
the current amount of storage is over and above the fixed
storage.
Note that the same variable appears twice on the
picture, once at the place where a call to procedure P is made
and again at the point of completion of P. Cur_Aug has a value
at every point in the program and is continually updated.
Similarly, as the execution procedes, Prior_Max_Aug keeps
track of the maximum storage used during any interval. In the
picture at the point where the call P(a) is made, Cur_Aug is
shown, as is Prior_Max_Aug. Of course, as the code execution
progresses, the value for Prior_Max_Aug is updated whenever
a new peak in storage use occurs.
Finally, we address the storage requirements. Before the
procedure body, we set the Prior_Max_Aug and the Cur_Aug
both to be the amount of space required by the parameter, x.
(Alternatively, the displacement of parameters at the beginning
could be subtracted at the end.) This is necessary to retain the
local nature of the proof process. The only concern that the
procedure rule has about space is what the procedure uses above
what has already been used in the past and what might be used
in the future. After the body, the rule checks that the max over
the stated values is within the specified bound.
Within the procedure body, some local variables may be
declared. This augmented displacement is denoted in the figure
by a spike in the line representing space allocation for the
procedure code. The specifications of the procedure include
M_D_Exp, an expression that limits the supplementary storage a
procedure may use. The procedure must stay within that limit in
order to be considered correct in terms of performance. As the
picture shows, the M_D_Exp is an expression about only local
variables and whatever parameters are passed in. These are the
only variables under the control of the procedure and they are
the only ones the procedure should need to consider for
specification and verification purposes.
Disp is an operator that extracts the amount of storage for a
given variable. This operator gets its value in the displacement
clause given in an implementation of an object-oriented concept,
and it is usually parameterized by the object’s value [18]. At the
63
The next hypothesis in the rule is about timing, and it checks,
after variable substitution, that any result from the procedure
will lead to satisfaction of specified time bounds for the client
program. It is not surprising that any reasoning about time or
space must be made in terms of the variables being manipulated,
since their size and representation affect both.
point where the call P(a) is made the picture shows Disp(a), to
denote that a’s space allotment is part of the current
augmentation displacement. Upon completion of the procedure
call, the new value of a, shown as ?a may be different and may
require a different amount of space from what its value needed
at the time of the call. Disp(?a) is part of the current
augmentation
at
the
point
of
completion.
Fut_Max_Sup_Exp, as noted before, describes a bound on the
storage used by the remaining code, i.e., code following the
current statement under consideration.
Finally, the displacement hypothesis considers the maximum
over several values. To understand this hypothesis, the picture
helps by illustrating the prior maximum augmentation, current
augmentation both at the point of the call and at the point of the
return. The picture also shows the displacement for actual
parameter a at the beginning of the procedure call and the
displacement of ?a at the end.
Given his explanation, the procedure call rule follows:
C ∪ {P_Heading} \ Code; Confirm P_Usg_Exp[x⇝a] ∧
∀ ?a: M_Exp(T), if P_Rslt_Exp[#x⇝a, x⇝?a] then
The displacement hypothesis involves a nested max situation.
We consider the inner max first. Here we are taking the
maximum over two items. The first is the expression from the
procedure heading that identifies how much storage the
procedure will need in terms of the local variables and the
parameters. The second is the sum of the amount of space
required by the final value of the updated parameter referred to
as ?a and the amount of space for the rest of the program
represented by Fut_Sup_Disp_Exp. From the second
quantity we subtract the displacement of a, since it was
accounted for in the current augmentation. Finally, we take the
max over the two items and show that it remains within the
overall bound.
Outcome_Exp[a⇝?a] ∧
Cum_Dur + Dur_Exp[#x⇝a, x⇝?a] +
Sqnt_Dur_Exp[a⇝?a] ≤ Dur_Bd_Exp[a⇝?a] ∧
Max( Prior_Max_Aug, Cur_Aug ,
Max( M_D_Exp[#x⇝a, x⇝?a],
Disp(?a) + Fut_Sup_Disp_Exp[a⇝?a] ) – Disp(a) )
≤ Aug _Bd_Exp[a⇝?a];
——————————————————————————
C ∪ {P_Heading} \ Code; P(a); Confirm Outcome_Exp ∧
Cum_Dur + Sqnt_Dur_Exp ≤ Dur_Bd_Exp ∧
Max( Prior_Max_Aug, Cur_Aug + Fut_Sup_Disp_Exp ) ≤
Aug_Bd_Exp;
The technique used in parameter passing naturally affects the
performance behavior of a procedure call. In the rule, we have
assumed a constant-time parameter passing method, such as
swapping [3].
An additional degree of complication is
introduced when an argument is repeated as a procedure call,
because extra variables may be created to handle the situation.
The present rule does not address this complexity.
The heading for P is placed in the context, making available the
specifications needed to carry out any proof. In the conclusion
line, a call to P with parameter a is made at the point in the
program following Code.
In modular reasoning, verification of this code that calls an
operation P is based only on the specification of P. The
functional behavior is addressed in the top line of the hypothesis
part of the rule. To facilitate modular verification, at the point in
the code where the call to P is made with parameter a, it is
necessary to check that the requires clause, P_Usg_Exp with
a replacing x holds. The second hypothesis, also about
functional behavior, checks to see that if the procedure
successfully completes, i.e., the ensures clause is met with the
appropriate substitution of variables, then the assertion
Outcome_Exp holds, again with the appropriate substitution of
variables. These substitutions make it possible for the rules to
talk about two distinct times, one at the point where a call to the
procedure is made and one at the point of completion. The
substitution of what variables need to appear at what points in
the proof process avoids the need ever to introduce more than
two points in the time line, thereby simplifying the process.
4. AN EXAMPLE
In this section, we present a more comprehensive example of a
generic code segment, including appropriate expressions for
describing time and space. In our example, we reproduce
Stack_Template concept from [18], where a detailed explanation
of the notation may be found:
It is important to note here that the specification of Operation P
may be relational, i.e., alternative outputs may result for the
same input. Regardless of what value results for parameters
after a call to P, the calling code must satisfy its obligations.
This is the reason for the universal quantification of variable ?a
in the rule.
64
Concept Stack_Template( type Entry;
evaluates Max_Depth: Integer);
uses Std_Integer_Fac, String_Theory;
requires Max_Depth > 0;
The advantage of writing this capability as an enhancement is
that it is reusable, i.e., it will work for all Stack_Template
realizations. For an example of a Stack_Template realization, a
reader is referred to [18].
Type_Family Stack ⊆ Str(Entry);
exemplar S;
constraints S ≤ Max_Depth;
initialization
ensures S = Λ;
In our implementation, given below, we have included both the
code (it is purely generic since any realization of the given stack
concept may be used for the underlying stack type) and the
performance specifications that deal with time and space.
Realization Obvious_F_C_Realiz for
Stack_Template.Flipping_Capability;
Operation Push( alters E: Entry; updates S: Stack );
requires S < Max_Depth;
ensures S = 〈#E〉 ° #S;
Duration Situation Normal: ∃ CPu, CPo, CIE, CEI, CSIS: ℝ>0 ∋
CPu = LUB(DurPush[Entry×Stack]) and
CPo = LUB(DurPop[Entry×Stack]) and
CIE = LUB(DurIs_Empty[Stack]) and
CEI = DurEntry.Initialization and
CSIS + Max_Depth∗CEI = DurStack.Initialization;
Operation Pop( replaces R: Entry; updates S: Stack );
requires S > 0 ;
ensures #S = 〈R〉 ° S;
Defn const C1: ℝ>0 = (CIE + CPo + CPu);
Operation Depth_of( restores S: Stack ): Integer;
ensures Depth_of = ( S );
Defn const C2: ℝ>0 = (DurCall(1) + CEI + CSIS + CIE + C:=:);
Defn const Cnts_Disp( S: Str(Entry) ): ℕ =
( ∑ Occurs _ Ct (E, S) ∗ Disp(E) );
Operation Rem_Capacity( restores S: Stack ): Integer;
ensures Rem_Capacity = ( Max_Depth −S);
E : Entry
Displacement Situation Normal: ∃ DSD, DEID: ℕ ∋
DEID = DispEntry.Init_Val and
∀ S: Stack, Disp(S) = DSD +
DEID∗(Max_Depth − |S|) + Cnts_Disp( S ) and
∀ E: Entry, Disp(E) ≥ DEID and
Is_Nominal(Mnp_DispPop(E, S)) and
Is_Nominal(Mnp_DispPush(E, S)) and
Is_Nominal(Mnp_DispIs_Empty(S));
Operation Clear( clears S: Stack );
end Stack_Template;
This specification is for a generic family of stacks whose entries
are left to be supplied by clients and whose maximum depth is a
parameter. It exports a family of stack types along with the
typical operations on stacks. Any given stack type is modeled as
a collection of strings over the given type Entry whose length is
bounded by the Max_Depth parameter.
Procedure Flip( upd S: Stack );
duration Normal: C1∗|#S| + Max_Depth∗CEI + C2;
manip_disp Normal: 2∗DSD + DEID∗(2∗Max_Depth +
1 − |@S|) + Cnts_Disp( @S );
Var Next_Entry: Entry;
Var S_Flipped: Stack;
While ¬ Is_Empty( S )
updating S, S_Flipped, Next_Entry;
maintaining #S = S_FlippedRev◦S and
Entry.Is_Initial(Next_Entry);
decreasing |S|;
elapsed_time Normal: C1∗|S_Flipped|;
max_manip_space 2∗DSD + DEID∗(2∗Max_Depth
+ 1 − |#S|) + Cnts_Disp( #S );
do
Pop( Next_Entry, S );
Push( Next_Entry, S_Flipped );
end;
S :=: S_Flipped;
end Flip;
end Obvious_F_C_Realiz;
In order to promote both component reuse and the idea of
multiple implementations for any given concept, our design
guidelines include the recommendation that concepts should
provide whatever operations are necessary to support whatever
type is being exported and operations that allow a user to check
whether or not a given operation should be called. In the stack
example both Push and Pop must be present because those are
the operations that define stack behavior. The Depth_of and
Rem_Capacity enable a client to find out whether or not it is
alright to Push or to Pop. These are called primary operations.
Our guidelines suggest that secondary operations, ones that can
be carried out -- efficiently -- using the primary ones, should be
in an enhancement. An enhancement is a component that is
written for a specific concept. It can use any of the exported
types and operations provided in that concept. For example, we
might write an enhancement to reverse a stack. In it would be
an operation whose specifications indicate that whatever stack is
passed into the procedure is supposed to be reversed. Given
below is the functionality specification of such an enhancement:
In writing performance specifications, there is a trade-off
between generality and simplicity. Given that the space/time
usage of a call to every operation could depend on the input and
outputs values of its parameters at the time of the call, a general
version of performance specification can be quite complex. But
we can simplify the situation, if we make some reasonable
Enhancement Flipping_Capability for Stack_Template;
Operation Flip(updates S: Stack);
ensures S = #SRev;
end Flipping_Capability;
65
•
assumptions about the performance of reusable operations.
While the performance specification language should be
sufficiently expressive to handle all possibilities, in this paper,
we present simplified performance expressions making a few
assumptions.
When the assumptions do not hold, the
performance specifications do not apply.
The proof rule for while loop (not given here) checks that each
of the programmer-supplied clauses is valid and then employs
them in the proof.
There may a variety of ways in which time and space are
handled, such as the straightforward allocation of space upon
declaration and immediate return upon completion of a block as
one method, and amortization as another. Here we use the term
Duration Situation followed by Normal to indicate the former.
A specification may also give performance behavior for more
than one situation.
In this short version of the paper, we have omitted discussion of
several important issues, including proof rules for loop
statements as well as other constructs. We have also not
explained how the system can accommodate dynamic and/or
global memory management, though the framework allows for
those complications. Finally, the non-trivial aspects of a
framework within which to discuss the soundness and
completeness of the proof system need to be presented.
We provide constants that represent durations for each of the
procedures that might be called, taking least upper bound when
those durations might vary according to contents. For example,
DurPush stands for the amount of time taken by a Push operation.
Since that might vary depending on the particular value being
pushed, the least upper bound is used to address that fact.
5. RELATED WORK AND SUMMARY
The importance of performance considerations in componentbased software engineering is well documented [7, 19, 20, 21].
Designers of languages and developers of object-based
component
libraries
have
considered
alternative
implementations providing performance trade-offs, including
parameterization for performance [2]. While these and other
advances in object-based computing continue to change the
nature of programming languages, formal techniques for static
performance analysis have restricted their attention to real-time
and concurrency aspects [6, 10, 11, 20].
The way this approach allows the use of generic code is to have
specifications that can be given in terms of the procedures they
call. We think of initialization as a special procedure, one for
each type, that is called when a variable is declared. For
example, DurStack.Initialization means the duration associated with
the initialization of a stack. We do not know nor do we need to
know what particular kind of stack will be used here, rather our
specifications are completely generic, allowing the specific
values to be filled in once a particular stack type has been
designated.
Hehner and Reddy are among the first to consider formalization
of space (including dynamic allocation) [4, 13]. Reddy’s work
is essentially a precursor to the contents of this paper, and its
focus is on performance specification. The proof system for
time and (maximum) space analysis outlined in [4] is similar to
the elements of our proof system given in section 2 of this paper.
Both systems are intended for automation. In verification of
recursive procedures and loops, for automation, we expect time
remaining and maximum manipulated space clauses to be
supplied by a programmer, though the need for the clauses is not
made apparent in the examples in Hehner’s paper. Our rules for
these constructs are, therefore, different. Other differences
include performance specification of generic data abstractions
and specification-based modular performance reasoning. This
becomes clear, for example, by observing the role of the
displacement functions in the procedure call rule in Section 3.
All of the constants at the beginning of the realization are
presented as convenience definitions so that the expressions
written in the duration and manip_disp clauses will be shorter
to read.
Just as we have identified what duration constants are needed
for specifying the duration of the reversing procedure, we also
set up definitions to make the storage (manip_disp) expression
shorter to read. We can now see how the duration and
manipulation displacement expressions associated with each
procedure can be used when scaling up and using those
procedures in a larger program.
In verifying the correctness of the procedure, for the loop
statement, the programmer supplies the following information:
•
•
•
•
A max_manip_space clause that denotes the
maximum space manipulated since the beginning
of the loop in any iteration.
This paper complements our earlier paper on performance
specification in explaining how performance can be analyzed
formally and in a modular fashion. To have an analytical
method for performance prediction, i.e., to determine a priori if
and when a system will fail due to space/time limits, is a basic
need for predictable (software) engineering. Clearly,
performance specification and analysis are complicated
activities, even when compounding issues such as concurrency
and compiler optimization are factored out. Bringing these
results into practice will require considerable education and
sophisticated tools. More importantly, current language and
software design techniques that focus on functional flexibility
need to be re-evaluated with attention to predictable
performance.
An updating clause that lists variables that might
be modified in the loop, allowing the verifier to
assume that values of other variables in scope are
invariant, i.e., not modified;
A maintaining clause that postulates an invariant
for the loop;
A decreasing clause that serves as a progress
metric to be used in showing that the loop
terminates;
An elapsed time clause for each situation
assumption in the duration specification to denote
how much time has elapsed since the beginning
of the loop; and
66
ACKNOWLEDGMENTS
It is a pleasure to acknowledge the contributions of members of
the Reusable Software Research Groups at Clemson University
and The Ohio State University. We would especially like to
thank Greg Kulczycki, A. L. N. Reddy, and Bruce Weide for
discussions on the contents of this paper. Our thanks are also
due to the referees for their suggestions for improvement.
11.
12.
We gratefully acknowledge financial support from the National
Science Foundation under grants CCR-0081596 and CCR0113181, and from the Defense Advanced Research Projects
Agency under project number DAAH04-96-1-0419 monitored
by the U.S. Army Research Office.
13.
REFERENCES
14.
1.
Ernst, G. W., Hookway, R. J., and Ogden, W. F.,
“Modular Verification of Data Abstractions with
Shared Realizations”, IEEE Transactions on Software
Engineering 20, 4, April 1994, 288-307.
2. Generic Programming, eds. M. Jazayeri, R. G. K.
Loos, and D. R. Musser, LNCS 1766, Springer, 2000.
3. Harms, D.E., and Weide, B.W., “Copying and
Swapping: Influences on the Design of Reusable
Software Components,” IEEE Transactions on
Software Engineering, Vol. 17, No. 5, May 1991, pp.
424-435.
4. Hehner, E. C. R., “Formalization of Time and Space,”
Formal Aspects of Computing, Springer-Verlag, 1999,
pp. 6-18.
5. Heym, W.D. Computer Program Verification:
Improvements for Human Reasoning. Ph.D.
Dissertation, Department of Computer and
Information Science, The Ohio State University,
Columbus, OH, 1995.
6. Hooman, J., Specification and Compositional
Verification of Real-Time Systems, LNCS 558,
Springer-Verlag, New York, 1991.
7. Jones, R., Preface, Proceedings of the International
Symposium on Memory Management, ACM SIGPLAN
Notices 34, No. 3, March 1999, pp. iv-v.
8. Leavens, G., “Modular Specification and Verification
of Object-Oriented Programs”, IEEE Software, Vol. 8,
No. 4, July 1991, pp. 72-80.
9. Leino, K. R. M., Toward Reliable Modular Programs,
Ph. D. Thesis, California Institute of Technology,
1995.
10. Liu, Y. A. and Gomez, G., “Automatic Accurate
Time-Bound Analysis for High-Level Languages,”
15.
16.
17.
18.
19.
20.
21.
67
Procs. ACM SIGPLAN Workshop on Languages,
Compilers, and Tools for Embedded Systems, LNCS
1474, Springer-Verlag, 1998.
Lynch, N. and Vaandrager, F., “Forward and
backward
simulations-Part
II:
Timing-Based
Systems,” Information and Computation, 121(2),
September 1995, 214-233.
Muller, P. and Poetzsch-Heffter, A., “Modular
Specification and Verification Techniques for ObjectOriented Software Components,” in Foundations of
Component-Based Systems, Eds. G. T. Leavens and
M. Sitaraman, Cambridge University Press, 2000.
Reddy, A. L. N., Formalization of Storage
Considerations
in
Software
Design,
Ph.D.
Dissertation, Department of Computer Science and
Electrical Engineering, West Virginia University,
Morgantown, WV, 1999.
Schmidt, H. W. and Chen, J. Reasoning About
Concurrent Objects. In Proceedings of the AsiaPacific Software Engineering Conference, IEEE,
Brisbane, Australia, 1995, 86-95.
Sitaraman, M., and Weide, B.W., eds. Componentbased software using RESOLVE. ACM Software Eng.
Notes 19,4 (1994), 21-67.
Sitaraman, M., Atkinson, S., Kulczycki, G., Weide, B.
W., Long, T. J., Bucci, P., Heym, W., Pike, S., and
Hollingsworth, J. E., “Reasoning About SoftwareComponent Behavior,” Procs. Sixth Int. Conf. on
Software Reuse, LNCS 1844, Springer-Verlag, 2000,
266-283.
Sitaraman,
M.,
“Compositional
Performance
Reasoning,” Procs. Fourth ICSE Workshop on
Component-Based Software Engineering: ComponentCertification and System Prediction, Toronto, CA,
May 2001.
Sitaraman, M., Krone, J., Kulczycki, G., Ogden, W.
F., and Reddy, A. L. N., “Performance Specification
of Software Components,” ACM SIGSOFT
Symposium on Software Reuse, May 2001.
Szyperski, C., Component Software: Beyond ObjectOriented Programming, Addison-Wesley, 1998.
Special issue on Real-Time Specification and
Verification, IEEE Trans. on Software Engineeering,
September 1992.
Special section: Workshop on Software and
Performance, Eds., A. M. K. Cheng, P. Clemens, and
M. Woodside, IEEE Trans. on Software Engineeering,
November/December 2000.
On Contract Monitoring for the Verification of
Component-Based Systems
Philippe Collet
Objects and Software Components Group
Laboratoire I3S - CNRS - Université de Nice - Sophia Antipolis
Les Algorithmes- Bât. Euclide B, 2000 route des Lucioles
BP 121, F-06903 Sophia Antipolis Cedex, France
[email protected]
ABSTRACT
This position paper focuses on contract monitoring for component interfaces, considering the verification of functional
and non-functional properties in the contracts. We investigate what properties are needed on behavioral and Quality of Service contracts. We also define what are the requirements on a monitoring environment to handle properly
those contracts. We briefly transpose those requirements to
a meta-level architecture.
1.
INTRODUCTION
The development of component-based systems intends to
deliver the beneficial effects that the object-oriented approach failed to completely provide: reuse of out-sourced
pieces of software and thus increased productivity. The definition of component devised during the 1996 Workshop on
Component-Oriented Programming [1] is the following: “A
software component is a unit of composition with contractually specified interfaces and explicit context dependencies
only. A software component can be deployed independently
and is subject to composition by third parties.”
In this definition, the specification process is clearly related to contractually specified interfaces. This position paper focuses on the general notion of contract for components,
that is a component must expose functionalities, through its
functional contract, and its performances, using some nonfunctional contract. More precisely, Beugnard et al [3] categorize contracts in four levels:
1. Syntactic contracts, that is signatures of data types.
2. Behavioral contracts, that is some semantic description of data types,
3. Synchronization contracts, which deal with concurrency
issues.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
Copyright 2001 Philippe Collet.
68
4. Quality of Service (QoS) contracts, which encompass
all non-functional requirements and guarantees.
We consider it crucial to dispose of such contracts if we
want software components to behave like components from
other engineering domains. Moreover, software components
can certainly be the right software units to justify the additional cost of using more formal approaches, as their life
cycle and their marketing strategies might be driven by quality. To create a real market of software components, application developers must be capable of browsing, comparing
and choosing components [13] according to all their exposed
properties: an expression of services and quality of these services is then obviously necessary. Those specifications must
then be verified one way or another.
Consequently we believe that the specification and verification of component-based systems must take into account
those four levels of contract from the start, to provide a
broad and consistent framework to handle those different
kinds of properties. As we also believe that expressive formalisms are needed to support the contractual approach,
we base our work on the hypothesis that it is not possible
to fully verify statically that such contracts are never violated. The runtime enforcement of those contracts together
leads to specific monitoring problems as a straightforward
combination of separate contracts monitoring would interfere with each other. A specific monitoring framework is
needed to handle all kinds of contract and we consider that
an appropriate meta-level architecture must be defined to
provide such a framework.
In this paper, we investigate what properties are needed
on contracts, by considering two specific levels, behavioral
and QoS. We define the global contract which consists of the
combination of the four levels. We describe what are the requirements on a monitoring environment to handle properly
those contracts. We briefly transpose those requirements
to a meta-level architecture, both in its design and in its
implementation.
2.
SPECIFICATION OF BEHAVIORAL AND
QOS CONTRACTS
In this paper, we only focus on the behavioral and QoS
contracts. The first level of contract corresponds to type
signatures, and type checking is usually performed statically. The synchronization aspects of contracts still need
to be studied in a general enough component framework, as
concurrency issues are often reduced to the means of communication of a given connector of a component.
2.1
Java syntax and semantics for basic operations in the
assertion language (access to fields, method calls, basic operators, etc.). JML also provides very interesting
features with the separate specification of normal and
exceptional behaviors, quantification operators and refinement of the specification models1 . The runtime enforcement of some parts of the contract is also possible.
As a result, JML provides a well-founded basis from
the start, trying to be closer to developers.
Behavioral Contract
Several specification techniques can be envisaged to specify the behavioral semantics of component interfaces. Currently the contractual approach based on preconditions, postconditions and invariants is promoted as a pragmatic but
valuable specification technique for components. Current
component frameworks are based on, or at least promote,
OO programming languages. The majority of those OO
languages provide only the first level of contract, but there
are languages, such as Eiffel [12], that inherently incorporate
behavioral contracts with preconditions, postconditions and
invariants. Many extensions to existing languages with behavioral contracts, such as iContract [10] or JML [11] for
Java, have also been designed.
Szyperski [14] showed that behavioral contracts based on
pre and postconditions have several drawbacks related to
call-backs and re-entrance. Nevertheless, we believe it still
constitutes the best trade-off between expressiveness and
ease of comprehension by an average developer.
However, there are two different specification approaches
for those behavioral contracts:
• The first one can be qualified as language-based specification, as the contract expression is a boolean expression of the annotated language, usually using all the
functional features (access to fields, method calls, basic types and operations) with some specific operators
to refer to previous states (old, @pre), to the result of
the annotated function (result), etc. The main reference is the Eiffel language [12], even if more expressive
assertion language have been proposed [10], with the
addition of quantification operators for example.
This approach suffers from its reuse of the annotated
language, as it is often hard to provide a complete formal semantics for the assertion language, as the underlying programming language does not provide one
either. Despite this problem, this approach is open
to partial specification, fits well with subtyping and is
well understood by developers.
Moreover, recent work [7] provides a sound framework
for behavioral contracts based on pre and postconditions. This theory [6] brings soundness regarding inheritance and interfaces in the context of the Java programming language. But this theory is applicable to
many other cases.
• The other approach relies on model-based specifications [4], that is the annotations that make up the
contract are stated in terms of a mathematical model
of the states of objects. This kind of specification usually enables static analysis and theorem proving, as
they are based on an algebraic style. However, as the
expressiveness of the language increases, proofs are no
longer possible. Moreover, this kind of specification
is hard to understand by developers as they are not
trained or used to think in such a way.
A somewhat hybrid approach is now developed : JML
(Java Modeling Language) [11] restricts the use of models to model fields and reuses as much as possible the
69
Both approaches have advantages and drawbacks, and are
trying to eliminate their respective disadvantages: theoretical work is done in the language-based approach, practical
issues motivate work in the model-based approach. One can
hope that the approaches will merge or that one approach
will reuse and adapt all beneficial aspects of the other one.
In the meantime, it must be noted that both JML and
language-based contracts systems lead to the same kind of
runtime monitoring systems, which will be shown to interfere with other contract levels.
2.2
QoS Contract
Regarding QoS, contracts have been investigated in the
world of distributed objects and components systems. Software components, in the broad sense, must be able to expose many different non functional properties, such as performance, reliability, policies related to persistence, transactions or security. Apart from the properties that are usually
provided by the container — or context —, designing a QoS
contract system expressing time and space performance in
function of some resources usage seems quite challenging, as
many aspects must be taken into account.
The complexity of algorithms can be easily related to an
order using the O notation on both the average and worst
cases. Both cases are likely to be relevant for a software
component. But this notation expresses complexity bounds,
independent of any deployment platform, so these formulas
need to be related to absolute bounds [14], showing some
real figures. In addition to the issue of comparing performance, contracting QoS leads to the problem of handling
negotiation and renegotiation.
To our knowledge, no QoS contract language or system
expresses and verifies performance issues based on input parameters and resources usage, but QML (QoS Modeling Language) [8] looks like the most advanced QoS specification
language. In QML, the QoS specification is made of three
mechanisms: contract type, contract and profile. Contract
type are QoS aspects, such as performance or reliability. A
contract is an instance of a contract type and a profile associates a QML contract with an interface. The QoS aspects
that can be represented in QML are quite powerful, with different domains of value, constraints and even statistics on
measured values over a period of time. However QML does
not provide any means to express a QoS contract according
to some parameters that would come from the component
interface, e.g. to specify a time constraint in relation with
the size of an input data structure. Moreover resources consumption cannot be specified. QML contracts are made of
constraints on domains of values, and a contract can refine
1
JML also provides a when clause, which can be seen as part
of a level 3 contract on synchronization: if a method is called
and its preconditions hold, the call will wait until the when
clause holds as well.
another one by adding constraints or putting stronger constraints on an already constrained domain. Each kind of
constraint that can be defined in QML must specify a total order among its values. A conformance relation is then
defined between the contracts.
Monitoring QoS is not considered in QML [8], but similar
QoS oriented approaches monitor some properties at runtime by configuring the middleware, or by using meta-level
mechanisms [2]. As some categories of QoS can involve pervasive monitoring, like security in Java [5], interferences between the separate QoS monitoring already proposed would
certainly occur. As general-purpose QoS specification formalisms are likely to be proposed, a contract monitoring environment must be carefully designed to enable to express
the correct combination of each corresponding monitoring
process. It must be also kept open enough to take into
account the possible new features. The environment must
also handle the case of partial conformance between QoS
contracts or during monitoring, e.g. a time constraint is respected but a space constraint is not. Different policies are
then applicable: termination, renegotiation, etc. The same
problem arises on the global contract, as described in the
next section.
2.3
• by not modifying the program behavior in relation to
synchronization;
• and finally by not consuming any time or space!
Even if the first property can be achieved by modifying all
the methods that give access to type information, it is not
feasible to completely achieve the second and third properties. Nonetheless, the monitoring environment must strive
for minimizing the effect of the observer on the observed
phenomena.
3.
REQUIREMENTS FOR
MONITORING CONTRACTS
In order to provide an appropriate framework to monitor
all kinds of contract, we propose exposing the necessary concepts that are manipulated by behavioral contract systems.
In the same way, we expect to describe an open enough
framework for QoS monitoring, so that the monitoring processes can be manipulated and composed at the global level.
3.1
Putting Contracts Together
Considering all four levels together (type, behavior, synchronization, QoS), a proper combination can be determined
in order to provide a global contract. The general specification can simply be done separately in each contract formalism and the conformance rule of this global contract is the
conjunction of all conformance rules. However, it is also important to consider the case where some partial conformance
is achieved, which typically leads to contract renegotiation
in QoS-aware systems. Different actions regarding the contract can be started:
• Termination if the QoS contract is considered as too
important to be renegotiated.
• Renegotiation of the QoS contract with weaker constraints (e.g. a 3D component cannot provide a 30
frames/s rate and the new QoS contract asks for 25).
• Withdrawal of the QoS contract, getting back to a
purely functional best-effort approach.
• Renegotiation of the functional contract and possibly
of the QoS contract (e.g. the same 3D component
is asked to lower its resolution and may be asked to
maintain the 30 frames/s rate).
Consequently the combination of all contracts must be provided with the addition of dynamic negotiation capabilities,
which can be taken for example from the QoS formalism.
2.4
• by not adding new types in the type hierarchy;
Monitoring Issues
Monitoring at runtime needs a proper support so that a
specific contract monitoring does not affect another monitoring process at a different level. For example, behavioral
and QoS monitoring can interfere if the monitoring code
that evaluates assertions create new objects when the QoS
is monitoring space occupancy. In the same way, the time
spent in monitoring must not be taken into account in profiling time, unless explicitly specified. Consequently, monitoring behavioral contracts must be done in a framework
that will not interfere on any other contract level:
70
Behavioral Contract Monitoring
The monitoring technique for such contracts consists in
checking the appropriate preconditions at the entry of a
method, the postconditions and invariants at the exit. Defining what are the appropriate assertions, i.e. the semantically
correct ones, to be monitored on a given object at runtime,
according to inheritance, subtyping and implemented interfaces [6] is considered as out of the scope of the monitoring
process. We present a list of requirements on the monitoring
system:
• The integration of the contract enforcement code with
the normal code must not create new visible classes or
methods — wrapping asserted methods is a common
way to integrate assertions —. Even if programmers
can be told not to use these, any tool that uses the
modified class will consider them as normal unless correctly hidden or specified. Avoiding a pervasive integration is also important for the deployment footprint,
which could be constrained in a QoS contract.
• Specific data structures and code are usually necessary
to manage the integration, to avoid non-termination of
assertion checking due to recursion, to provide assertion triggering at a fine-grained level (class or object)
and to make the checker thread-safe!
• All accesses to instance fields and all method calls that
are made to evaluate an assertion are recorded as such,
i.e. not counted in time measurement.
• All created objects during any evaluation are excluded
from space measurement.
• The synchronization policies and behaviors normally
defined for the component should not be modified.
How this can be achieved, totally or partially, remains
an open question. However, the sketched framework is
expected to be able to design and experiment proper
solutions.
The assertion languages always provide enhancements to
boolean expressions in order to increase expressiveness. The
most common ones are studied in relation to the monitoring
issues:
• Quantification operations (∀, ∃), or more generally
higher-level functions, need to be translated to the underlying language, thus generating extra code and new
functions. That boils down to the first side-effects presented above.
• Access to the result of the annotated function usually
generates side-effects because of methods wrapping or
any other techniques used to provide this feature.
• Reference to the previous state of objects in the specification of procedures (old, @pre) is usually done by
generating local variables that keep references or values of the concerned variables by computation at the
method entry. They are later referenced at method
exit. This additional code generates side-effect. This
is also the same for the let construct, which is used
to avoid repetitions in assertions.
All the prototyped approaches that have been proposed so
far generates all, or almost all, side-effects listed above. That
includes approaches based on source to source processing,
bytecode adaptation, compile-time or runtime reflection and
aspect-based processing.
3.2
QoS Contract Monitoring
As a proper general QoS specification language is not
available, we infer some principles on how to monitor QoS.
Taking QML as an example, the monitoring would be based
on time measurement and appropriate recording to compute necessary values and statistics. QoS in general would
be based on measurement of many parameters, to compute
results ranging from simple constraints to complex function
of several parameters, such as time and space requirements
together with dependencies on available resources, size of
input data, etc.
Consequently, the computation of these results needs to
be semantically correct, that is:
• without any interference from other contracts, and actually, without any interference coming from the component surrounding, such as the services provided by
the container.
• at the appropriate times. Considering the method call
as the essential point of contracting, the monitoring
environment can be kept open by reusing the finegrained model of aspect-oriented programming [9] to
consider the following events: before the method call
(client side), at the method entry (provider side), before the exit (provider side), just after the method call
(client side). A distinction can also be made between
the method call and the effective method execution
(late binding).
3.3
Requirements for an appropriate metalevel
Monitoring behavioral contracts can be seen as an aspect
in the sense of aspect-oriented programming [9]. Monitoring
some QoS properties in middleware has been done through
71
message reflection [2]. Consequently we consider that the
monitoring of all forms of contracts must be done in a appropriate meta-level framework supporting message interception, as contracts are mainly monitored on method calls.
However this meta-level must satisfy strong constraints, as
it must provide a clear separation between the normal behavior and other aspects, so that monitoring of contracts
can be as transparent as possible to the semantics and to
QoS for the client.
We believe that this transparency can be achieved by
defining a minimal set of interactions between the two levels, taking into account low-level issues such as object allocation. At the meta level, the careful implementation of
the specific contractual constructs we have described is expected to enforce transparency as well. The main issue of
such a framework will certainly be performance, as both
levels will need to act as almost separate execution environments. The implementation of a prototype to experiment
these ideas has begun. It uses a language-based specification language for Java, OCL-J, which adapts the Object
Constraint Language of UML to the Java programming language. The developed prototype is intended to use the Java
Platform Debugging Architecture (JPDA), as this architecture provides a framework that is close in some points to
our requirements. We expect these experiments to provide
feedback on how to properly design the interactions between
the base and the meta levels, as well as new insights in the
area of contract monitoring.
4.
CONCLUSION
In order to provide quality software components, the specification and verification of component-based systems must
take into account both the functional and non-functional
contracting of interfaces. By considering a global contract
merging all kinds of contracts, we showed that renegotiation of QoS contracts must be supported and that different
monitoring codes must be aware of each other and must not
interfere. Consequently we argue that contract monitoring
must be handled globally inside a meta-level that clearly
separates the base level and the meta-level in all functional
and non-functional aspects.
5.
ACKNOWLEDGMENTS
Thanks to Jacques Malenfant for discussions on non-functional
contracts and for pinpointing the QoS specification language
QML.
6.
REFERENCES
[1] International Workshop on Component-Oriented
Programming (WCOP’96), 1998.
[2] M. Aksit, A. Noutash, M. van Sinderen, and
L. Bergmans. QoS Provisioning in Corba by
Introducing a Reflective Aspect-Oriented Transport
Layer. In 1st ECOOP Workshop on Quality of Service
in Distributed Object Systems (QoSDOS 2000), 2000.
[3] A. Beugnard, J.-M. Jézéquel, N. Plouzeau, and
D. Watkins. Making Components Contract Aware.
Computer, 32(7), July 1999.
[4] Y. Cheon and G. T. Leavens. A Quick Overview of
Larch/C++. Journal of Object Oriented
Programming, 7(8):39–49, Oct. 1994.
[5] U. Erlingsson and F. B. Schneider. IRM Enforcement
of Java Stack Inspection. In IEEE Symposium on
Security and Privacy, Oakland, California, May 2000.
[6] R. B. Findler and M. Felleisen. Contract Soundness
for Object-Oriented Languages. In Proceedings of
OOPSLA’2001, 2001.
[7] R. B. Findler, M. Latendresse, and M. Felleisen.
Behavioral Contracts and Behavioral Subtyping. In
Proceedings of Foundations of Software Engineering
(FSE’2001), 2001.
[8] S. Frolund and J. Koistinen. Quality of Service
Specification in Distributed Object Systems Design.
Distributed System Engineering, December 1998.
[9] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten,
J. Palm, and W. G. Griswold. An Overview of
AspectJ. In Proceedings of the 24th European
Conference on Object-Oriented Programming
(ECOOP’2001), Lecture Notes in Computer Science.
Springer Verlag (Berlin), 2001.
[10] R. Kramer. iContract - the Java Design by Contract
Tool. In M. Singh, B. Meyer, J. Gil, and R. Mitchell,
editors, International Conference on Technology of
Object-Oriented Languages and Systems (Tools 26,
USA’98), IEEE Computer Society Press (New York),
1998.
[11] G. T. Leavens, A. L. Baker, and C. Ruby. JML: A
Notation for Detailed Design. In H. Kilov, B. Rumpe,
and I. Simmonds, editors, Behavioral Specifications of
Businesses and Systems, pages 175–188. Kluwer, 1999.
[12] B. Meyer. Object-Oriented Software Construction. The
O-O series. Prentice Hall Inc. (Englewood Cliffs, NJ),
2nd edition, 1997.
[13] H. L. Nielsen and R. Elmstrom. Proposal for Tools
Supporting Component Based Programming. In
Fourth International Workshop on
Component-Oriented Programming (WCOP’99), 1999.
[14] C. Szyperski. Component Software — Beyond
Object-Oriented Programming. Addison-Wesley
Publishing Co. (Reading, MA), 1998.
72
A Framework for Formal Component-Based
Software Architecting
M.R.V. Chaudron, E.M. Eskenazi, A.V. Fioukov, D.K. Hammer
Department of Mathematics and Computing Science, Technische Universiteit Eindhoven,
Postbox 513, 5600 MB Eindhoven, The Netherlands
+31 (0)40 – 247 4416
{m.r.v.chaudron, e.m.eskenazi, a.v.fioukov, d.k.hammer}@tue.nl
H[LVWLQJ VROXWLRQV LV YLWDO )RU WKLV SXUSRVH WKH FRQVWUXFWLRQ RI
VRIWZDUH ZLWK UHXVDEOH FRPSRQHQWV LV KLJKO\ GHVLUDEOH 7KLV
PHWKRGRIVRIWZDUHGHYHORSPHQWUHTXLUHVWHFKQLTXHVIRUDVVHVVLQJ
WKH FRPSRVDELOLW\ RI FRPSRQHQWV 7KLV DVVHVVPHQW FDQ EH GRQH
UHDVRQDEO\ZHOOIRUWKHIXQFWLRQDODVSHFWVRIFRPSRQHQWVEXWQR
DGHTXDWH WHFKQLTXHV H[LVWV IRU DQDO\]LQJ FRPSRVDELOLW\ RI QRQ
IXQFWLRQDORQHV
$%675$&7
7KHDVVHVVPHQWRITXDOLW\DWWULEXWHVRIVRIWZDUHLQWHQVLYHV\VWHPV
LV D FKDOOHQJLQJ LVVXH 7KLV SDSHU RXWOLQHV D PHWKRG DLPHG DW
TXDQWLWDWLYH HYDOXDWLRQ RI FHUWDLQ TXDOLW\ DWWULEXWHV WKDW DUH
LPSRUWDQW IRU HPEHGGHG V\VWHPV WLPHOLQHVV SHUIRUPDQFH DQG
PHPRU\FRQVXPSWLRQ
7KH SDSHU VNHWFKHV RXW WKH NH\ SULQFLSOHV IRU EXLOGLQJ D IRUPDO
PRGHO IRU HYDOXDWLQJ TXDOLW\ DWWULEXWHV 'HSHQGDELOLW\
FRQVWUDLQWV DUH VSHFLILHG LQ DQ HQGWRHQG IDVKLRQ &RPSRQHQWV DUH DWWULEXWHG ZLWK UHVRXUFH GHPDQGV 6SHFLILFDWLRQ RI FRPSRQHQW LQWHUDFWLRQ LV VHSDUDWHG IURP
VSHFLILFDWLRQRIFRPSRQHQWEHKDYLRU
7KHSRVVLELOLW\WRHVWLPDWHUHOHYDQWTXDOLW\DWWULEXWHV LQ WKH HDUO\
GHYHORSPHQW SKDVH LV FUXFLDO 7KHVH NLQGV RI SUHGLFWLRQV ZLOO
UHGXFH WKH ULVN RI GHYHORSLQJ QRQFRPSHWLWLYH LQIHDVLEOH RU
IODZHG SURGXFWV 7KXV IRU TXDQWLWDWLYH VRIWZDUH DUFKLWHFWLQJ D
IRUPDOPDWKHPDWLFDOEDVLVLVQHHGHG
0RVW FRQWHPSRUDU\ DUFKLWHFWLQJ DSSURDFKHV GHDO RQO\ ZLWK WKH
IXQFWLRQDODVSHFWVRIVRIWZDUH%XWWKHUHDUHDOVR QRQIXQFWLRQDO
TXDOLW\ DWWULEXWHV D W\SLFDO H[DPSOH EHLQJ GHSHQGDELOLW\ TXDOLW\
DWWULEXWHVSHUIRUPDQFHWLPHOLQHVVUHOLDELOLW\DYDLODELOLW\VDIHW\
DQG VHFXULW\ 7KHVH DWWULEXWHV HPHUJH DV D UHVXOW RI FROODERUDWLYH
IXQFWLRQLQJRIDOOSDUWVZKLFKDV\VWHPLVEXLOWIURPDQGWKH\FDQ
PDNH D VLJQLILFDQW LPSDFW RQ WKH HQWLUH DUFKLWHFWXUH
&RQVHTXHQWO\ RQH RI WKH PRVW LPSRUWDQW LVVXHV LQ VRIWZDUH
DUFKLWHFWLQJLVGHDOLQJZLWKTXDOLW\DWWULEXWHV
7KH PHWKRG LV DLPHG WR EH DSSOLFDEOH LQ SUDFWLFH 7KHUHIRUH ZH
LQYHVWLJDWH FRPELQLQJ ZLGHO\ XVHG VRIWZDUH PRGHOLQJ QRWDWLRQV
ZLWK H[LVWLQJ IRUPDO PHWKRGV ,Q SDUWLFXODU WKH SURSRVHG
DSSURDFK FRPELQHV 0HVVDJH 6HTXHQFH &KDUWV DQG 7LPHG
$XWRPDWD:HLOOXVWUDWHWKHDSSURDFKZLWKDQH[DPSOH
&DWHJRULHVDQG6XEMHFW'HVFULSWRUV
' 6RIWZDUH $UFKLWHFWXUHV ' 6RIWZDUH 3URJUDP
9HULILFDWLRQ
0DQ\PRGHUQWHFKQLTXHVIRUVRIWZDUHHYDOXDWLRQXVHH[SHUWEDVHG
DSSURDFKHV HJ $7$0 >@ 6$$0 >@ ZKLFK HYDOXDWH RYHUDOO
TXDOLW\RIWKHDUFKLWHFWXUH7KHTXDQWLWDWLYHPHWKRGVXVHGLQWKHVH
DSSURDFKHVDUHDSSOLHGLQDQDGKRFPDQQHU DQG LQ PDQ\ FDVHV
DUHWRRFRQWH[WRULHQWHGWREHJHQHUDOL]HG$VDFRQVHTXHQFHLWLV
GLIILFXOW WR PDNH WKH DUFKLWHFWLQJ SURFHVV UHOLDEOH SUHGLFWDEOH
DQGUHSHDWDEOH
*HQHUDO7HUPV
3HUIRUPDQFH'HVLJQ5HOLDELOLW\9HULILFDWLRQ
.H\ZRUGV
&RPSRQHQWEDVHG VRIWZDUH VRIWZDUH DUFKLWHFWXUH TXDOLW\
DWWULEXWHV DUFKLWHFWXUH HYDOXDWLRQ WLPHOLQHVV PHPRU\
FRQVXPSWLRQIRUPDOPHWKRGV
)RU WKH WLPH EHLQJ DUFKLWHFWLQJ LV VWLOO PRUH DQ DUW WKDQ DQ
HQJLQHHULQJ GLVFLSOLQH 6XEVWDQWLDO HIIRUWV KDYH WR EH LQYHVWHG LQ
PDNLQJ WKH DUFKLWHFWLQJ SURFHVV PRUH UDWLRQDOL]HG DQG SUHFLVH
2QHRIWKHZD\VWRPDNHWKHDUFKLWHFWLQJSURFHVVPRUHSUHFLVHLV
WKH XVH RI IRUPDO PHWKRGV +RZHYHU IRUPDO PHWKRGV DUH QRW D
VLOYHUEXOOHWWKH\KDYHWKHLURZQGUDZEDFNV2QHVKRXOGEHDZDUH
WKDW WKH DSSOLFDWLRQ RI IRUPDO PHWKRGV XVXDOO\ UHTXLUHV SUHFLVH
DQG FRPSOHWH VSHFLILFDWLRQ ,Q PDQ\ FDVHV DQ DUFKLWHFW GRHV QRW
KDYHWKLVLQIRUPDWLRQ+HRUVKHPD\QRWHYHQEHLQWHUHVWHGLQD
YHU\ GHWDLOHG GHVLJQ DW WKH HDUO\ VWDJHV RI GHVLJQ EXW SUHIHU WR
SRVWSRQHGHVLJQGHFLVLRQVWRODWHUVWDJHV7KXVDEDODQFHEHWZHHQ
WKHDUFKLWHFW
VIUHHGRPRIGHVLJQDQGWKHSUHFLVLRQRIDQDO\VLVDQG
VSHFLILFDWLRQVKRXOGEHIRXQG1RWHDFFXUDF\RIDVSHFLILFDWLRQLV
QRW DOZD\V D GUDZEDFN DV LW DOVR VWLPXODWHV RQH WR WKLQN PRUH
DFFXUDWHO\DQGV\VWHPDWLFDOO\
,1752'8&7,21
1RZDGD\V PRUH DQG PRUH ³LQWHOOLJHQW´ GHYLFHV FRQWDLQ
VRSKLVWLFDWHG HPEHGGHG VRIWZDUH WR IXOILOO D EURDG VFRSH RI
IXQFWLRQV$VPRUHGHYLFHVDUHGHYHORSHGWKHVFRSHRIIXQFWLRQV
WR EH LPSOHPHQWHG PXVW EH EURDGHU 7KLV JURZLQJ FRPSOH[LW\
FRPSOLFDWHV WKH GHYHORSPHQW RI HPEHGGHG VRIWZDUH 7KXV QHZ
DSSURDFKHVIRUVRIWZDUHGHYHORSPHQWDUHKHDYLO\QHHGHG
7R UHGXFH GHYHORSPHQW FRVW DQG GHYHORSPHQW WLPH WKH UHXVH RI
73
6XSSRUW E\ DXWRPDWLF WRROV FRXOG EH YHU\ KHOSIXO IRU DUFKLWHFWV
+RZHYHUWRROLQJXVXDOO\UHTXLUHVVWULFWQRQDPELJXRXVVHPDQWLFV
RI WKH PRGHOV EHLQJ SURFHVVHG WKXV IRUPDO PHWKRGV DUH DOVR
HVVHQWLDOKHUH
.(<35,1&,3/(6)25&20321(17
%$6('$5&+,7(&7,1*
&RPSRQHQWEDVHGDUFKLWHFWLQJ HJ VHH >@ DQG >@ LV RQH RI
WKH PRVW SURPLVLQJ DSSURDFKHV IRU PDQDJLQJ FRPSOH[LW\ DQG
ERRVWLQJUHXVH+RZHYHUFXUUHQWFRPSRQHQWEDVHGDSSURDFKHVGR
QRWDGGUHVVWKHEHKDYLRUDODQGQRQIXQFWLRQDODVSHFWVRIVRIWZDUH
7KHUHIRUHZHSURSRVHWKHIROORZLQJH[WHQVLRQV
7KHUH H[LVW QR JHQHUDO DSSURDFKHV IRU HYDOXDWLQJ QRQIXQFWLRQDO
SURSHUWLHV RI D V\VWHP DW WKH DUFKLWHFWXUDO OHYHO 7KH LQWHUHVWLQJ
DSSURDFKFRPELQLQJVWUXFWXUDOGHVFULSWLRQRIDUFKLWHFWXUH'DUZLQ
$UFKLWHFWXUH 'HVFULSWLRQ /DQJXDJH ZLWK EHKDYLRUDO GHVFULSWLRQ
RIFRPSRQHQWV/DEHOHG7UDQVLWLRQ6\VWHPZDVSURSRVHGLQ>@
+RZHYHUWKLVDSSURDFKRQO\DOORZVFKHFNLQJVDIHW\DQGOLYHQHVV
SURSHUWLHVEXWLWGRHVQRWPRGHOWLPLQJDVSHFWVZKLFKDUHQHHGHG
IRU WKH DQDO\VLV RI TXDOLW\ DWWULEXWHV OLNH WLPHOLQHVV DQG
SHUIRUPDQFH $OVR WKH H[LVWLQJ PHWKRGV IRU TXDQWLWDWLYH
HYDOXDWLRQIRFXVRQRQHTXDOLW\DWWULEXWHRQO\
([SOLFLW VSHFLILFDWLRQ RI FRPSRQHQW EHKDYLRU DQG LQWHUDFWLRQ $
IRUPDO VSHFLILFDWLRQ RI WKH G\QDPLF DVSHFWV RI FRPSRQHQWV DQG
WKHLULQWHUDFWLRQLVQHFHVVDU\IRUUHDVRQLQJ DERXW WKH EHKDYLRU RI
WKHLUFRPSRVLWLRQDQGLWVQRQIXQFWLRQDOSURSHUWLHV
6XSSRUWRIKLHUDUFKLFDOFRPSRQHQWGHVFULSWLRQ$FRPSRQHQWFDQ
EHHLWKHUDWRPLFRUFRPSRXQG7KHDWRPLFFRPSRQHQWFDQQRWEH
IXUWKHU VXEGLYLGHG EXW WKH FRPSRXQG FRPSRQHQW FDQ FRQVLVW RI
DWRPLFDQGRURWKHUFRPSRXQGFRPSRQHQWV$VDUHVXOWRQHKDV
PRUH IOH[LELOLW\ LQ FKRRVLQJ WKH XQLW RI WKH UHXVH HLWKHU D VLQJOH
DWRPLFFRPSRQHQWRUDQHQWLUHSDFNDJH$QRWKHUDGYDQWDJHLVWKH
SRVVLELOLW\WRDSSO\FRPSRVLWLRQDOGHVLJQDSSURDFKDWWKHGLIIHUHQW
OHYHOV RI KLHUDUFK\ D V\VWHP LV FRPSRVHG IURP VXEV\VWHPV
VXEV\VWHPVDUHFRPSRVHGIURPFRPSRXQGFRPSRQHQWVHWF
:HDLPWRLQWHJUDOO\PRGHOPXOWLSOHTXDOLW\DWWULEXWHV±WLPHOLQHVV
SHUIRUPDQFHDQGPHPRU\FRQVXPSWLRQ±WRVXSSRUWWKHPDNLQJRI
DUFKLWHFWXUDOGHVLJQWUDGHRIIV
5HTXLUHPHQWVRQWKH0HWKRG
7KHDLPLVWRGHYHORSDPHWKRGIRUVXSSRUWLQJVRIWZDUHDUFKLWHFWV
GXULQJ HDUO\ VWDJHV RI FRPSRQHQWEDVHG VRIWZDUH DUFKLWHFWLQJ RI
UHVRXUFHFRQVWUDLQHG V\VWHPV ,W LV QHFHVVDU\ WR ILQG VXLWDEOH
WHFKQLTXHV IRU DUFKLWHFWXUH GHVFULSWLRQ DQG PHWKRGV IRU TXDOLW\
DWWULEXWHV HYDOXDWLRQ DQG WR PHUJH WKHP LQWR DQ LQWHJUDWHG
IUDPHZRUN
6HSDUDWLRQ RI FRPSRQHQW LQWHUDFWLRQ IURP FRPSRQHQW EHKDYLRU
7KH GHVFULSWLRQ RI EHKDYLRUDO DVSHFWV LV VWUXFWXUHG LQ VHSDUDWH
SDUWV 7KHUH DUH VSHFLILFDWLRQV RI FRPSRQHQW EHKDYLRU DQG
VSHFLILFDWLRQV RI FRPSRQHQW LQWHUDFWLRQ $ UDWLRQDOH IRU
LQGHSHQGHQW VSHFLILFDWLRQ RI WKH LQWHUDFWLRQ UHODWLRQVKLSV LV
SUHVHQWHG LQ >@ :H LGHQWLILHG WKH IROORZLQJ DGGLWLRQDO UHDVRQV
IRUWKLVVHSDUDWLRQ
7KHUHTXLUHPHQWVRQWKHPHWKRGDUHWKHIROORZLQJ
&RPSRVLWLRQDOLW\ RI UHVRXUFHFRQVWUDLQW V\VWHPV 7KH
PHWKRGRORJ\ VKRXOG EH FRPSRVLWLRQDO 7KLV PHDQV WKDW TXDOLW\
DWWULEXWHV RI D FRPSRVLWH V\VWHP FDQ EH FDOFXODWHG IURP WKH
FRQVWLWXHQWV FRPSRQHQWV DQG FRPSRVLWLRQ PHFKDQLVPV ,Q
SDUWLFXODU WKH PHWKRG VKRXOG IRFXV RQ SUHGLFWLQJ TXDOLW\
DWWULEXWHVEDVHGRQUHVRXUFHFRQVXPSWLRQRIWKHFRPSRQHQWV
*HQHULFLW\7DLORUDELOLW\ 7KH LQWHUDFWLRQ VSHFLILFDWLRQ
PD\ EH XVHG WR WDLORU WKH EHKDYLRU RI JHQHULF
FRPSRQHQWV WR SDUWLFXODU FRQWH[W 7KLV KHOSV WR DYRLG
FRGLQJ RI FRQWH[WGULYHQ DVSHFWV ZLWKLQ FRPSRQHQWV
DQGKHQFHDOORZVPRUHJHQHUDOFRPSRQHQWGHVLJQV
(YHQ LI WKH IXQFWLRQDO LQWHUIDFHV DQG WKH LQWHUDFWLRQ PHFKDQLVPV
RI FRPSRQHQWV DUH SUHFLVHO\ VSHFLILHG FRPSRQHQW FRPSRVLWLRQ
PD\ QRW IXQFWLRQ SURSHUO\ EHFDXVH QRQIXQFWLRQDO SURSHUWLHV RI
WKH HQWLUH V\VWHP ZHUH QRW FRQVLGHUHG EHIRUHKDQG 7\SLFDO
LQVWDQFHV RI WKLV SUREOHP DUH UHVRXUFH FRQIOLFWV HJ UDFH
FRQGLWLRQV FRQIOLFWV RQ DFFHVV WR VKDUHG UHVRXUFHV HWF 7KHVH
FRQIOLFWV PDNH LW GLIILFXOW WR HQVXUH WKH SURSHU DQG SUHGLFWDEOH
EHKDYLRURIDV\VWHPLQDGYDQFH
6SHFLI\LQJ FRQVWUDLQWV HQGWRHQG 'HSHQGDELOLW\
FRQVWUDLQWV DUH RIWHQ FRQFHUQHG ZLWK WKH HQGWRHQG
LQWHUDFWLRQ EHWZHHQ FRPSRQHQWV +DYLQJ D VHSDUDWH
VSHFLILFDWLRQ RI WKH LQWHUDFWLRQ FRQVWLWXWHV D EHWWHU
PHDQV IRU VWUXFWXULQJ WKH VSHFLILFDWLRQ WKDQ WKH
DOWHUQDWLYHV SODFLQJ FRQVWUDLQWV DW RQH RI WKH
FRPSRQHQWV LQYROYHG RU GLYLGLQJ XS DQ HQGWRHQG
WLPLQJFRQVWUDLQWRYHUPXOWLSOHFRPSRQHQWV
'HSHQGDELOLW\ DVVHVVPHQW GXULQJ WKH HDUO\ GHYHORSPHQW
SKDVHV 7KH GHSHQGDELOLW\ DWWULEXWHV WLPHOLQHVV SHUIRUPDQFH
UHOLDELOLW\ DYDLODELOLW\ VDIHW\ DQG VHFXULW\ RI FRPSRQHQWEDVHG
V\VWHPV FDQQRW EH HYDOXDWHG E\ WKH FXUUHQW DSSURDFKHV 6R WKH
PHWKRG PXVW KHOS DUFKLWHFWV WR HVWLPDWH WKH GHSHQGDELOLW\
DWWULEXWHVDQGHQVXUHDFHUWDLQOHYHORIHVWLPDWLRQDFFXUDF\$VD
VLPSOH H[DPSOH WKH UHVXOWV FDQ EH GHVFULEHG LQ WHUPV RI ZRUVW
FDVHDQGEHVWFDVHHVWLPDWLRQV
/RRVHFRXSOLQJ,QH[LVWLQJFRPSRQHQWPRGHOVWKHZD\
WKDW D FRPSRQHQW LV LQWHQGHG WR LQWHUDFW ZLWK RWKHU
FRPSRQHQWV LV SURJUDPPHG LQWR D FRPSRQHQW
HQGRJHQRXV ELQGLQJ 7KLV KDV WR FKDQJH LI WKH
EHKDYLRU RI RWKHU FRPSRQHQWV FKDQJHV +HQFH LW
FRQVWLWXWHV D GHSHQGHQF\ RQ WKH EHKDYLRU RI RWKHU
FRPSRQHQWV %\ VSHFLI\LQJ LQWHUDFWLRQ VHSDUDWHO\
H[RJHQRXVO\WKLVGHSHQGHQF\LVDYRLGHG
$OVR WKHUH DUH QRQWHFKQLFDO UHTXLUHPHQWV RQ WKH PHWKRG ,Q
RUGHU WR EH HDVLO\ FRPSUHKHQVLEOH DQG HDV\ WR OHDUQ E\ VRIWZDUH
HQJLQHHUV WKH PHWKRG VKRXOG EH EDVHG RQ ZLGHO\ DFFHSWHG
VRIWZDUH VSHFLILFDWLRQ DQG GHVLJQ WHFKQLTXHV 7KHVH WHFKQLTXHV
VKRXOGPDNHHQJLQHHU¶VZRUNPRUHHIILFLHQWDIWHUWKHHQJLQHHUKDV
JDLQHGVRPHH[SHULHQFHZLWKWKHP
([SOLFLWVSHFLILFDWLRQRIWKHUHVRXUFHUHTXLUHPHQWVRIFRPSRQHQWV
7KH GHSHQGDELOLW\ RI D V\VWHP LV UHODWHG WR WKH DPRXQW RI
UHVRXUFHV FRQVXPHG E\ WKH FRPSRQHQWV DQG SURYLGHG E\ WKH
H[HFXWLRQ SODWIRUP 7KHUH DUH WKUHH W\SHV RI UHVRXUFHV
FRPSXWDWLRQUHVRXUFHVFRPPXQLFDWLRQUHVRXUFHVDQGVWRUDJH7KH
GHILQLWLRQ RI FRPSRQHQW UHVRXUFH UHTXLUHPHQWV LQ D SODWIRUP
LQGHSHQGHQWZD\EURDGHQVWKHVFRSHRIFRPSRQHQWDSSOLFDWLRQ
6SHFLILFDWLRQ RI GHSHQGDELOLW\ FRQVWUDLQWV LQ DQ HQGWRHQG
IDVKLRQ 7KH EDVLF LGHD LV WKDW WLPLQJ DQG GHSHQGDELOLW\
74
FRQVWUDLQWV VKRXOG QRW EH FRPSRQHQW DWWULEXWHV EHFDXVH WKLV
ZRXOG MHRSDUGL]H UHXVDELOLW\ 7KH\ DUH UDWKHU FRQVLGHUHG DV
FRQVWUDLQWVRQWKHG\QDPLFVRIWKHV\VWHPLHRQWKHFRPSRQHQW
LQWHUDFWLRQ
$5&+,7(&785('(6&5,37,21
7(&+1,48(6
7KLV VHFWLRQ HQXPHUDWHV WKH UHTXLUHPHQWV RQ DUFKLWHFWXUH
GHVFULSWLRQ WHFKQLTXHV DQG RXWOLQHV WKH IUDPHZRUN $OVR LW
FRQWDLQVDQH[DPSOHWRLOOXVWUDWHWKHPHWKRGSURSRVHG
'LVWLQJXLVKUHVRXUFHFRQVWUDLQWVDQG UHVRXUFH FRQVXPSWLRQ 7KH
IRUPHUDUHGHVFULEHGDWWKHRYHUDOOV\VWHPOHYHOLQDQHQGWRHQG
IDVKLRQDQGWKHODWWHULVDVVRFLDWHGZLWKDFRPSRQHQWGHVFULSWLRQ
7KLVVHSDUDWLRQHQDEOHVWKHGHYHORSPHQWRIUHXVDEOHFRPSRQHQWV
DQG JLYHV GHVLJQHUV IUHHGRP LQ WKH VDWLVIDFWLRQ RI WKH UHVRXUFH
FRQVWUDLQWV
5HTXLUHPHQWVIRUGHVFULSWLRQWHFKQLTXHV
)RU VSHFLI\LQJ FRPSRQHQW EHKDYLRU D QXPEHU RI IRUPDO
GHVFULSWLRQ WHFKQLTXHV ZHUH LQVSHFWHG DQG FRPSDUHG %HIRUH WKH
DFWXDO FRPSDULVRQ HVVHQWLDO UHTXLUHPHQWV RQ WKH GHVFULSWLRQ
WHFKQLTXHVZHUHLGHQWLILHG7KHVHUHTXLUHPHQWVDQGWKHLUUDWLRQDOH
IROORZEHORZ7KHUHTXLUHPHQWVDUHPDUNHGDVFRPSXOVRU\&RU
RSWLRQDO2
$OOWKHDIRUHPHQWLRQHGDVSHFWVKDYHWREHSURSHUO\HODERUDWHGLQ
RUGHUWRFRQVWLWXWHDSUDFWLFDOPHWKRG
$5&+,7(&7,1*(19,5210(17
7KHGHVFULSWLRQWHFKQLTXHVVKRXOGVXSSRUWTXDQWLWDWLYH
PRGHOVIRUWLPHOLQHVVDQDO\VLV&
7R UHFRQFLOH WKH JRDOV RI XVLQJ DFFHSWHG VRIWZDUH HQJLQHHULQJ
QRWDWLRQV DQG DXWRPDWHG DQDO\VLV WRROV ZH DLP IRU D IUDPHZRUN
WKDWFRQVLVWVRIWKUHHSDUWVVHH)LJXUH
5DWLRQDOHWRHQDEOHWLPHOLQHVVDVVHVVPHQWDWWKHHDUO\
DUFKLWHFWLQJSKDVHEHIRUHV\VWHPLPSOHPHQWDWLRQ
%HKDYLRU&RQVWUDLQWV6SHF
7KHGHVFULSWLRQWHFKQLTXHVVKRXOGVXSSRUWTXDQWLWDWLYH
HYDOXDWLRQRIPHPRU\FRQVXPSWLRQ&
([WHQVLRQV
([WHQVLRQV
IRUVSHFLI\LQJ
5HJXODU
7HPSRUDO
EHKDYLRXU
([SUHVVLRQV
/RJLF
7LPHG
2&/
$XWRPDWD
IRUVSHFLI\LQJ
06&
5DWLRQDOHWRHQDEOHPHPRU\FRQVXPSWLRQHVWLPDWLRQDWWKH
HDUO\DUFKLWHFWLQJSKDVH
LQWHUDFWLRQV
DQGWLPLQJ
FRQVWUDLQWV
FRQVWUDLQWV
7KH GHVFULSWLRQ WHFKQLTXHV VKRXOG VXSSRUW VSHFLILFDWLRQ RI
WLPLQJFRQVWUDLQWVLQDQHQGWRHQGIDVKLRQ&
7LPHG$XWRPDWD
833$$/QRWDWLRQH[WHQVLRQV
5DWLRQDOH WR DYRLG XQQHFHVVDU\ UHGXFWLRQ RI GHVLJQ VSDFH
FDXVHGE\DUWLILFLDOVXEGLYLVLRQRIWKHLQLWLDOGHDGOLQHV
%DVLF
IRUPDOLVP
7KHGHVFULSWLRQWHFKQLTXHVVKRXOGVXSSRUW WKH SRVVLELOLW\ WR
VSHFLI\LQWHUDFWLRQEHKDYLRUH[RJHQRXVO\&
5DWLRQDOH WR LQFUHDVH UHXVDELOLW\ RI WKH FRPSRQHQWV DQG WR
EXLOGIOH[LEOHDUFKLWHFWXUHV
$QDO\VLV
9HULILFDWLRQ
6LPXODWLRQ
(YDOXDWLRQ
7KHGHVFULSWLRQWHFKQLTXHVVKRXOGDOORZRQHWRUHDVRQDERXW
WKH SURSHUWLHV RI D FRPSRQHQW FRPSRVLWLRQ EDVHG RQ WKH
SURSHUWLHVRIWKHFRPSRQHQWV&
5DWLRQDOH7RHQDEOHHIIHFWLYHDXWRPDWHGIRUPDOUHDVRQLQJ
7KH GHVFULSWLRQ WHFKQLTXHV VKRXOG VXSSRUW WKH VSHFLILFDWLRQ
RI UHVRXUFH UHTXLUHPHQWV SURFHVVLQJ VWRUDJH DQG
FRPPXQLFDWLRQ&
)LJXUH$UFKLWHFWLQJHQYLURQPHQW
7KHDUFKLWHFWLQJHQYLURQPHQWSURYLGHVHQJLQHHUVWKHSRVVLELOLW\WR
XVH D FRPELQDWLRQ RI QRWDWLRQV IRU GHVFULELQJ DUFKLWHFWXUHV )RU
WKH WLPH EHLQJ ZH IRFXV RQ 0HVVDJH 6HTXHQFH &KDUWV 06&
>@ DQG 7LPHG $XWRPDWD 7$ >@ $OVR WKH DUFKLWHFWLQJ
HQYLURQPHQWLVWREHH[WHQGLEOHZLWKRWKHUQRWDWLRQVVXFKDVWKH
2EMHFW&RQVWUDLQW/DQJXDJH2&/>@RUWHPSRUDOORJLF
5DWLRQDOHWRHQDEOHDQDO\VLVRIHIIHFWVRIUHVRXUFHFRQIOLFWV
7KHVSHFLILFDWLRQVPXVWEHFRPSUHKHQVLEOHIRUHQJLQHHUV&
5DWLRQDOHUHGXFHHIIRUWVIRUHGXFDWLRQRIHQJLQHHUV
6XSSRUWIRUDXWRPDWLFFRGHJHQHUDWLRQ2
$GHVFULSWLRQWHFKQLTXHVKRXOGHQDEOHFUHDWLQJRIWRROV WKDW
FDQJHQHUDWHFRGHIRUDJLYHQVSHFLILFDWLRQ
)RUDQDO\]LQJDUFKLWHFWXUDOGHVLJQVWKHGLIIHUHQWQRWDWLRQVQHHGWR
EH UHODWHG 7R WKLV HQG ZH GHYLVH PDSSLQJV RI QRWDWLRQV RQWR D
EDVLF IRUPDOLVP ,Q RXU DSSURDFK 7LPHG $XWRPDWD DUH XVHG DV
EDVLF IRUPDOLVP :H GR QRW H[SHFW WR ILQG PDSSLQJV RI DOO
FRQVWUXFWVRIDOOPRGHOLQJQRWDWLRQVRQWRDVLQJOHEDVLFPRGHOLQJ
IRUPDOLVP ,Q FRRSHUDWLRQ ZLWK HQJLQHHUV ZH KDYH WR VHOHFW
VXEVHWV RI WKH QRWDWLRQV WKDW FRPSULVH WKH PRVW LPSRUWDQW
PRGHOLQJFRQVWUXFWV\HWDOVRSURYLGHWKHLQIRUPDWLRQQHHGHGIRU
DXWRPDWLFDQDO\VLV
5DWLRQDOHWRHQDEOHHIILFLHQWGHYHORSPHQW
8VHRIH[LVWLQJGHVLJQVLPXODWLRQDQGYHULILFDWLRQWRROV2
,WLVSUHIHUDEOHWRXVHWKHH[LVWLQJWRROVLQVWHDGRIGHYHORSLQJ
QHZRQHV
5DWLRQDOHWRGHVLJQWKHVRIWZDUHTXLFNO\DQGHDVLO\
%DVLFIRUPDOIUDPHZRUN
7RVXSSRUWGLIIHUHQWW\SHVRIDQDO\VHVZHHQYLVDJHDFROOHFWLRQRI
DQDO\VLVWRROVVXFKDVVFKHGXODELOLW\VLPXODWLRQRUYHULILFDWLRQ
WRROV 7KHVH WRROV RSHUDWH RQ WKH UHSUHVHQWDWLRQ RI WKH
DUFKLWHFWXUDOGHVLJQLQWHUPVRIWKHEDVLFIRUPDOLVP
,QWKLVVHFWLRQZHH[SODLQWKHDUFKLWHFWLQJDSSURDFKE\OLVWLQJWKH
PRGHOVWKDWVKRXOGEHFRQVWUXFWHGIRUGHVFULELQJDQDUFKLWHFWXUH
:HPRWLYDWHWKHFKRLFHVRIWKHIRUPDOGHVFULSWLRQWHFKQLTXHVIRU
WKHVHPRGHOV
75
0HVVDJH6HTXHQFH&KDUWV
*HQHUDOYLHZ
$V PHQWLRQHG EHIRUH FRPSRQHQW LQWHUDFWLRQ LV VSHFLILHG
VHSDUDWHO\ IURP FRPSRQHQW EHKDYLRU )RU WKDW D VSHFLILFDWLRQ
ODQJXDJHLVUHTXLUHGWKDWFDQDGGUHVVWKHIROORZLQJLVVXHV
$ JHQHUDO RYHUYLHZ RI WKH DSSURDFK WR PRGHOLQJ DUFKLWHFWXUHV LV
JLYHQ LQ )LJXUH 7KUHH HVVHQWLDO DUFKLWHFWLQJ PRGHOV DUH
FRQVLGHUHG
7KH ³6WUXFWXUDO PRGHO´ UHSUHVHQWV WKH VWDWLF FRQILJXUDWLRQ RI D
V\VWHP WKURXJK WKH GHSHQGHQFLHV DQG FRQQHFWLRQV EHWZHHQ
FRPSRQHQWV
7KH³%HKDYLRUDO0RGHO´LVXVHGWRGHVFULEHWKHG\QDPLFDVSHFWV
RI WKH FRPSRQHQWV FRPSRQHQW LQWHUDFWLRQ DQG UHVRXUFH
FRQVWUDLQWV HJ HQGWRHQG GHDGOLQHV $ FRPSRQHQW GHVFULSWLRQ
VSHFLILHVUHVRXUFHUHTXLUHPHQWVLQWHUPVRIWKH³5HVRXUFH0RGHO´
%HKDYLRXUDOPRGHO
%
$P
%Q
&T
5HVSRQVH
6WLPXOXV
UU
UU
,WVKRXOGVXSSRUWWKHVSHFLILFDWLRQRIWLPLQJFRQVWUDLQWV
LQDQHQGWRHQGIDVKLRQ
%HFDXVH RI WKH DERYH DGYDQWDJH 06& ZHUH SUHIHUUHG WR 7LPHG
$XWRPDWDIRUVSHFLI\LQJWKHWLPLQJFRQVWUDLQWV
UU
&
&S
([DPSOH
UU
5HVRXUFH
PRGHO
œ
06& DUH D ZHOODFFHSWHG VRIWZDUH QRWDWLRQ WKDW LV HDV\ WR OHDUQ
DQG XQGHUVWDQG $OVR WKH\ KDYH IRUPDO VHPDQWLFV LQ WHUPV RI
DXWRPDWD VHH HJ >@ WKDW PDNHV LW SRVVLEOH WR UHODWH WKHP WR
WLPHGDXWRPDWDZKLFKZHXVHDVEDVLFIRUPDOLVP
6SHFLI\HQGWRHQGFRQVWUDLQWV
$
,W VKRXOG HQDEOH UHVWULFWLQJ WKH EHKDYLRU RI JHQHULF
FRPSRQHQWV
7KH 06& QRWDWLRQ DOORZV RQH WR YLYLGO\ H[SUHVV WLPLQJ
FRQVWUDLQWVEHWZHHQVWLPXOXVDQGUHVSRQVHHYHQWVDWDVLQJOHSODFH
LQ D VSHFLILFDWLRQ 7KLV LV LQ FRQWUDVW WR WLPHG DXWRPDWD ZKHUH
WLPLQJ FRQVWUDLQWV DUH VSHFLILHG E\ PHDQV RI WZR RU PRUH
FRQVWUDLQWV RQ VKDUHG FORFN YDULDEOHV WKDW DUH GLVWULEXWHG RYHU
VHSDUDWHVWDWHVRUWUDQVLWLRQVRIWKHPRGHOWKLVZLOOEHLOOXVWUDWHG
ODWHU E\ DQ H[DPSOH 7KLV UHGXFHV WKH LQWHOOLJLELOLW\ RI D
VSHFLILFDWLRQ
7KH ³5HVRXUFH PRGHO´ GHVFULEHV WKH DYDLODEOH UHVRXUFHV 7KLV
PRGHODOVRGHILQHVDVKDULQJVWUDWHJ\IRUHDFKUHVRXUFH
6WUXFWXUDOPRGHO
œ
7RJLYHDIODYRURIRXUDSSURDFKZHZLOOGHPRQVWUDWHVRPHRIWKH
GHVFULSWLRQ SULQFLSOHV DQDO\VLV LV QRW LQFOXGHG ZLWK DQ H[DPSOH
RIDQ³$XWRPDWLF7HOOHU0DFKLQH´
5HVRXUFH
7KHVWUXFWXUDOPRGHORIWKHDUFKLWHFWXUHLVGHSLFWHGLQ)LJXUH
5HVRXUFH
)LJXUH2YHUYLHZRIWKHDSSURDFK
8VHU
&KRLFHRIDSSURSULDWHIRUPDOLVPV
$70
%DQN
)LJXUH.H\FRPSRQHQWV
)RU VWUXFWXUDO GHVFULSWLRQ ZH FRQVLGHU RQH RI WKH H[LVWLQJ
FRPSRQHQW PRGHOV VXSSRUWLQJ WKH QRWLRQV RI SURYLGHG DQG
UHTXLUHG LQWHUIDFHV HJ .RDOD >@ DQG 'DUZLQ >@ 6LQFH ZH
DLP WR WKH HYDOXDWLRQ RI WLPLQJ SURSHUWLHV WKH SURSHU EHKDYLRUDO
GHVFULSWLRQIRUPDOLVPVDUHWREHIRXQG
7KH V\VWHP FRQVLVWV RI WKH IROORZLQJ FRPSRQHQWV 8VHU $70
PRGHOLQJDFDVKGLVSHQVHUDQG%DQNPRGHOLQJVRPHDVSHFWVRI
EDQNRSHUDWLRQ8VHUDQG%DQNLQWHUDFWRQO\ZLWK$70EXWQRW
ZLWKHDFKRWKHU
$IWHUFRPSDULQJVHYHUDOIRUPDOLVPVWKHH[WHQGHGQRWLRQRI6WDWH
0DFKLQHV7LPHG$XWRPDWD>@ZDVFKRVHQIRUWKHVSHFLILFDWLRQ
RI FRPSRQHQW EHKDYLRU %DVLF 0HVVDJH 6HTXHQFH &KDUWV >@
ZHUH FKRVHQ IRU VSHFLI\LQJ FRPSRQHQW LQWHUDFWLRQ 7KLV VHFWLRQ
PRWLYDWHVWKLVFKRLFH
7KH EHKDYLRUDO PRGHO FRQVLVWV RI D VSHFLILFDWLRQ RI WKH EHKDYLRU
RIWKHLQGLYLGXDOFRPSRQHQWVXVLQJ833$$/DQGDVSHFLILFDWLRQ
RIWKHLULQWHUDFWLRQXVLQJ06&V
:HEULHIO\H[SODLQWKH833$$/QRWDWLRQ>@,Q833$$/WLPH
LV PRGHOHG XVLQJ FORFN YDULDEOHV WLPLQJ FRQVWUDLQV DUH
H[SUHVVLRQV RYHU FORFN YDULDEOHV 7KHVH FRQVWUDLQWV FDQ EH
DWWDFKHGERWKWRWUDQVLWLRQVDQGVWDWHV$FRQGLWLRQRQDVWDWHLVDQ
LQYDULDQW WKH V\VWHP LV DOORZHG WR EH LQ D VWDWH RQO\ LI LWV
LQYDULDQW KROGV $ FRQGLWLRQ RQ D WUDQVLWLRQ LV D JXDUG WKH
WUDQVLWLRQFDQRQO\EHWDNHQLIWKHJXDUGKROGV
7LPHG$XWRPDWD
7LPHG$XWRPDWDDUHVXSSRUWHGE\DZLGHVFRSHRIH[LVWLQJWRROV
IRU PRGHOLQJ DQG VLPXODWLRQ HJ 833$$/ IRU GHWDLOV VHH >@
)XUWKHUPRUH WKHLU JUDSKLFDO GHVFULSWLRQ PDNHV WKHP
FRPSUHKHQVLEOHIRUHQJLQHHUV
7KH WKHRU\ RQ 7LPHG $XWRPDWD GHVFULEHV FRQVWUXFWLRQV IRU
REWDLQLQJDQDXWRPDWRQWKDWGHVFULEHVWKHEHKDYLRURIWKHSDUDOOHO
FRPSRVLWLRQ RI WLPHG DXWRPDWD )RU WKH VLPSOHVW FDVHV LW LV
SRVVLEOHWRXVHWKH&DUWHVLDQSURGXFW
7KH ODEHOV RQ WUDQVLWLRQV GHQRWH HYHQWV /DEHOV ZLWK D TXHVWLRQ
PDUN³"´GHILQHLQSXWHYHQWVODEHOVZLWKDQH[FODPDWLRQPDUN³´
GHILQHRXWSXWHYHQWV
+RZHYHUZKHQXVLQJWLPHGDXWRPDWDFHUWDLQSULQFLSOHVPXVWEH
IROORZHG LQ RUGHU WR EH DEOH WR UHDVRQ FRPSRVLWLRQDOO\ )RU
H[DPSOH RQH VKRXOG QRW XVH JOREDO FORFN YDULDEOHV WR GHILQH
FRQVWUDLQVRQWKHEHKDYLRURIPXOWLSOHFRPSRQHQWV
5HWXUQLQJ WR WKH H[DPSOH )LJXUH GHVFULEHV WKH EHKDYLRU RI
8VHU
76
,GOH
XLQVHUWFDUG
XHMHFW
FDUG"
XHQWHU3,1
,GOH
$XWKRUL]DWLRQ
X3,1
X3,1
LQYDOLG"
YDOLGDWHG"
EQRQDXWKRUL]HG
[!
EYDOLGDWH3,1"
[
EDXWKRUL]HG
[!
XZLWKGUDZ
DPRXQW
,GOH
&KHFNLQJ
DPRXQW
XDFFHSW
XVXFFHVV"
9DOLGDWLQJ [
XHQWHU
XFDQFHO
XIDLO"
DPRXQW"
EEDQNYHWR
)LJXUH%HKDYLRURI8VHU
\!
EEDQN
WUDQVDFWLRQ"
\
7KHVSHFLILFDWLRQRI8VHUGHVFULEHVWKHEHKDYLRURIDQLQGLYLGXDO
ZKR ZDQWV WR ZLWKGUDZ FDVK IURP DQ $70 7KH DXWRPDWRQ
GHILQHVDQRUGHURQWKHHYHQWVIRUWKHZLWKGUDZDOSURFHVV
DLQVHUW
DHQWHU
FDUG"
3,1"
W!
DHMHFWFDUG
D3,1LQYDOLG
:H XVH FORFN YDULDEOHV [ DQG \ WR VSHFLI\ WKH UHVRXUFH
FRQVXPSWLRQ RI %DQN 7KH VSHFLILFDWLRQ VWDWHV WKDW WKH WLPH RI
SURFHVVLQJ DXWKRUL]DWLRQ UHTXHVWV E\ D K\SRWKHWLFDO &38 LV DW
OHDVW RQH WLPH XQLW DQG DW PRVW WZR WLPH XQLWV 7KH IRUPHU LV
LQGLFDWHG ZLWK WKH JXDUGV [! RQ ERWK WUDQVLWLRQV DQG WKH
ODWWHU LV VSHFLILHG ZLWK WKH LQYDULDQW [ RI WKH ³9DOLGDWLQJ´
VWDWH/LNHZLVHWKHWLPHQHFHVVDU\IRUSHUIRUPLQJDWUDQVDFWLRQLV
DWOHDVWWZRWLPHXQLWVEXWDWPRVWIRXUWLPHXQLWV6LPLODUO\RQH
FDQVSHFLI\FRQVXPSWLRQRI&38FDSDFLW\IRURWKHUFRPSRQHQWV
DYDOLGDWH
3,1
DQRQ
DXWKRUL]HG"
DDXWKRUL]HG"
DZLWKGUDZ"
DIDLO
YDOLGDWHG
DVXFFHVV
DEDQN
DEDQN
ILDW
YHWR
3HUIRUP
WUDQVDFWLRQ
W! )LQDOO\ ZH GHPRQVWUDWH WKH VSHFLILFDWLRQ RI HQGWRHQG WLPLQJ
FRQVWUDLQWV DQG WKH LQWHUDFWLRQ EHWZHHQ WKH FRPSRQHQWV 8VHU
$70DQG%DQNZLWKWKH0HVVDJH6HTXHQFH&KDUWLQ)LJXUH
D3,1
DFDQFHO"
W 2QWKHRQHKDQGWKHPHVVDJHVHTXHQFHFKDUWLQ)LJXUHVSHFLILHV
WKURXJK ZKLFK WUDQVLWLRQV DOO WKH WKUHH DXWRPDWD LQWHUDFW )RU
H[DPSOHWRLQGLFDWHWKDWWKHDFWLRQV³XLQVHUWFDUG´DQG ³DLQVHUW
FDUG´RI8VHUDQG$70UHVSHFWLYHO\QHHGWRV\QFKURQL]HZHXVH
DQ DPSHUVDQG V\PERO ³´ /LNHZLVH WKH RWKHU ODEHOV RI DOO WKH
WKUHH DXWRPDWD DUH ERXQG 7KLV W\SH RI VSHFLILFDWLRQ WHFKQLTXH
DOORZVRQHWRELQGFRPSRQHQWVLQDQH[RJHQRXVPDQQHU
DHQWHU
DPRXQW"
W! DEDQN
DDFFHSW
WUDQVDFWLRQ
DPRXQW
W
)LJXUH%HKDYLRURI%DQN
W
W \!
7UDQVDFWLRQ \
7KH EHKDYLRU RI $70 DQG %DQN LV LOOXVWUDWHG LQ )LJXUH DQG
)LJXUHUHVSHFWLYHO\
,GOH
EEDQNILDW
&KHFNLQJ
DPRXQW
$GGLWLRQDOO\WKLVPHVVDJH VHTXHQFH FKDUW LQGLFDWHV WKDW WKH WLPH
EHWZHHQ WKH RFFXUUHQFH RI ³HQWHU 3,1´ DQG WKH RFFXUUHQFH RI
³3,1 YDOLGDWHG´ PXVW QRW H[FHHG ILYH WLPH XQLWV $W WKH VDPH
WLPH LW LQGLFDWHV WKDW WLPH EHWZHHQ ³HQWHU DPRXQW´ DQG
³WUDQVDFWLRQVXFFHVV´PXVWQRWH[FHHGVL[WLPHXQLWV,QDVLPLODU
ZD\ PHVVDJH VHTXHQFH FKDUWV FDQ EH XVHG WR VSHFLI\ RWKHU
GHSHQGDELOLW\ FRQVWUDLQWV LQ DQ HQGWRHQG PDQQHU IRU UHOHYDQW
H[HFXWLRQVFHQDULRV
)LJXUH%HKDYLRURI$70
)RUWKHVSHFLILFDWLRQRI%DQNZHXVHWZRDXWRPDWD7KHVHPDQWLFV
RI WKLV LV WKDW WKH\ RSHUDWH LQ SDUDOOHO 7KLV DOORZV IXUWKHU
HQKDQFLQJRIWKHVSHFLILFDWLRQVWRVXSSRUWPRUHWKDQRQH8VHUDQG
RQH $70 WKH XQQHFHVVDU\ VHULDOL]DWLRQ RI WKH DXWKRUL]DWLRQ DQG
WUDQVDFWLRQUHTXHVWV IURP GLIIHUHQW FDVK GLVSHQVHUV ZKLFK ZRXOG
EH HQIRUFHG E\ PRGHOLQJ WKH EHKDYLRU DV D VLQJOH DXWRPDWD LV
DYRLGHG
77
RI WDVNV EHLQJ DQDO\]HG >@ EDVHG RQ WKH VSHFLILHG ZRUVWFDVH
H[HFXWLRQWLPHDQGGHDGOLQH,QDGGLWLRQLIWKH WDVNV VKDUH VRPH
UHVRXUFHV WKH EORFNLQJ WLPH LQGXFHG E\ WKH RQHV ZLWK ORZHU
SULRULW\VKRXOGEHJLYHQ)LQDOO\WKHSHULRGLFLW\LQIRUPDWLRQIRUD
VLPSOH FDVH LQ D IRUP RI WDVN LQWHUDUULYDO SHULRGV KDV WR EH
SURYLGHGWRHQDEOHWKHDSSOLFDWLRQRI50$
PVF&DVKBZLWKGUDZDOBVFHQDULR
8VHU
$70
%DQN
XLQVHUWFDUG
DLQVHUWFDUG
>@
+RZHYHU 50$ FDQ RQO\ EH XVHG ZLWK VRPH UDWKHU VWULFW
DVVXPSWLRQVRQWKHWDVNVRIWKHV\VWHP7KHPDLQUHVWULFWLRQLVWKH
DVVXPSWLRQWKDWWKHDUULYDOSDWWHUQRIDVWLPXOXVKDVVRPHIRUPRI
SHULRGLFLW\ (DUO\ YHUVLRQV RI 50$ KDYH GHDOW RQO\ ZLWK VWULFWO\
SHULRGLF HYHQWV KRZHYHU ODWHU H[WHQVLRQV KDYH LQFRUSRUDWHG D
SHULRGLFWDVNVDQGVSRUDGLFVHUYHUV$QRWKHUGUDZEDFNRI50$LV
WKDW LW GRHV QRW DOORZ LQWHUDFWLRQ EHWZHHQ WKH WDVNV 7KH RQO\
DOORZHGLQWHUDFWLRQLVPXWXDODFFHVVWRVKDUHGUHVRXUFHV
XHQWHU3,1
DYDOLGDWH3,1
DHQWHU3,1
EYDOLGDWH3,1
9DOLGDWLQJ
X3,1YDOLGDWHG
D3,1YDOLGDWHG
DDXWKRUL]HG
EDXWKRUL]HG
>@
1HZVFKHGXODELOLW\PRGHOLQJDSSURDFKHVKDYHHPHUJHGDVDUHVXOW
RIWKHVXEVWDQWLDOSURJUHVVLQWKHGHYHORSPHQWRIPRGHOFKHFNLQJ
WHFKQLTXHV ERWK IRU RUGLQDU\ DQG K\EULG WLPHG DXWRPDWD 7KHVH
DSSURDFKHV SDUWLDOO\ DGGUHVV WKH GUDZEDFNV RI 50$OLNH
WHFKQLTXHV DV WKH\ WDNH LQWHUDFWLRQ EHWZHHQ WKH WDVNV LQWR
DFFRXQW
XHQWHUDPRXQW
DHQWHUDPRXQW
&KHFNLQJ
DPRXQW
XDFFHSWDPRXQW
7KH PDLQ SULQFLSOH RQ ZKLFK WKHVH WHFKQLTXHV DUH EXLOW LV WKH
UHSODFHPHQW RI WKH LQLWLDO VFKHGXODELOLW\ SUREOHP ZLWK WKH
UHDFKDELOLW\ SUREOHP IRU D WLPHG DXWRPDWRQ HQFRPSDVVLQJ DOO
SHFXOLDULWLHV RI D FRQFUHWH VFKHGXODELOLW\ SROLF\ 7KH DXWRPDWRQ
PRGHOLQJWKHVFKHGXOHUFRPELQHGZLWKDXWRPDWDPRGHOLQJLQWHU
WDVN FRPPXQLFDWLRQ LV DQDO\]HG IRU UHDFKDELOLW\ RI WKH VWDWH
FRUUHVSRQGLQJWRDQRQVFKHGXODEOHVLWXDWLRQ>@
DDFFHSWDPRXQW
XEDQNWUDQVDFWLRQ
EEDQNWUDQVDFWLRQ
7UDQVDFWLRQ
XVXFFHVV
DVXFFHVV
DEDQNILDW
EEDQNILDW
XZLWKGUDZ
,Q JHQHUDO DXWRPDWDEDVHG PHWKRGV FRYHU D EURDGHU VFRSH RI
SRVVLEOHVFKHGXOLQJSROLFLHVWKDQ50$OLNHPHWKRGVGRDVWKH\
DOVR WDNH LQWR DFFRXQW WDVN LQWHUDFWLRQV +RZHYHU WKH DXWRPDWD
EDVHG PHWKRGV KDYH WZR GLVDGYDQWDJHV 7KH ILUVW LV WKDW WKHVH
PHWKRGV RQO\ LQGLFDWH ZKHWKHU D WDVN VHW LV VFKHGXODEOH RU QRW
WKH\GRQRWSURYLGHWKHUHVSRQVHWLPHRI WKH WDVNV ZKLFK ZRXOG
EH YHU\ XVHIXO IRU DUFKLWHFWV 7KH VHFRQG GUDZEDFN LV WKDW WKHVH
PHWKRGV EHLQJ EDVHG RQ WKH FRQVWUXFWLRQ RI DQ DXWRPDWRQ
PRGHOLQJWKHVFKHGXOHUVXIIHUIURPWKH VWDWH H[SORVLRQ SUREOHP
)RUWXQDWHO\ GXULQJ WKH ODVW WKUHH \HDUV D QXPEHU RI VXFFHVVIXO
DFFRXQWVDERXWWKHDSSOLFDWLRQRIDXWRPDWDEDVHGWHFKQLTXHVKDYH
EHHQ SXEOLVKHG >@ >@ DQG >@ %HFDXVH RI WKH IOH[LELOLW\ RI
WKHVH NLQGV RI WHFKQLTXHV WKHLU DSSOLFDWLRQ LV IHDVLEOH DW WKH
DUFKLWHFWLQJ OHYHO HVSHFLDOO\ LQ WKH FDVHV ZKHQ VWDQGDUG
WHFKQLTXHVOLNH50$DUHQRWDSSOLFDEOH
DZLWKGUDZ
XHMHFWFDUG
DHMHFWFDUG
)LJXUH6SHFLILFDWLRQRIGHDGOLQHVDQGFRPSRQHQWLQWHUDFWLRQ
7(&+1,48(6)25(9$/8$7,212)
48$/,7<$775,%87(6
7KLV VHFWLRQ VXPPDUL]HV RXU HYDOXDWLRQ RI PHWKRGV IRU WKH
DVVHVVPHQWRIWLPHOLQHVVDQGPHPRU\FRQVXPSWLRQDQGLQWHUSUHWV
WKHLUXVHIRUWKHVRIWZDUHDUFKLWHFWLQJ
7LPHOLQHVVHYDOXDWLRQ
%RWKW\SHVRIWHFKQLTXHVUHTXLUHLQIRUPDWLRQDERXWWKHZRUVWFDVH
H[HFXWLRQ WLPH RI WDVNV 8QIRUWXQDWHO\ PRVW FRQWHPSRUDU\
PHWKRGVIRUWKHHVWLPDWLRQRIZRUVWFDVHH[HFXWLRQWLPHFDQQRWEH
GLUHFWO\ DSSOLHG WR DUFKLWHFWLQJ DV WKH\ DUH EDVHG RQ DOUHDG\
H[LVWLQJFRGH%XWDWWKHDUFKLWHFWXUDOOHYHOVRPHHVWLPDWLRQVDUH
RIWHQ QHHGHG EHIRUH WKH FRGH LV ZULWWHQ )XUWKHUPRUH WKHUH DUH
WZRSUREOHPVZLWKWUDGLWLRQDODSSURDFKHV
$VDOUHDG\PHQWLRQHGWLPHOLQHVVLVDQLPSRUWDQWTXDOLW\DWWULEXWH
7LPHOLQHVV FDQ EH UHDVRQHG DERXW HLWKHU DQDO\WLFDOO\ WKURXJK D
VFKHGXODELOLW\ WHVW D W\SLFDO H[DPSOH EHLQJ 5DWH 0RQRWRQLF
$QDO\VLV 50$ VHH >@ >@ >@ DQG >@ RU WKURXJK WKH
FRQVWUXFWLRQRIDQH[SOLFLWVFKHGXOHHJLQ>@
%RWK DSSURDFKHV PRGHO WKH VFKHGXOLQJ SROLF\ DGRSWHG IRU WKH
V\VWHP'HSHQGLQJRQZKHWKHUWKHSULRULW\DVVLJQPHQWVWUDWHJ\RI
WKHVFKHGXOLQJSROLF\ LV IL[HG RU G\QDPLF GLIIHUHQW PRGHOV KDYH
WREHXVHG
)RUWKHIL[HGSULRULW\VFKHGXOLQJSROLF\50$LVXVXDOO\DSSOLHG
7KLVPHWKRGLVEDVHGRQWKHDQDO\VLVRIDVRFDOOHGFULWLFDOLQVWDQW
ZKHQ DOO WDVNV LQ WKH WDVN VHW DUH UHOHDVHG VLPXOWDQHRXVO\ ,W LV
SURYHQ WKDW WKH ZRUVWFDVH UHVSRQVH WLPH DSSHDUV IRU HDFK WDVN
GXULQJWKH FULWLFDO LQVWDQW 7KH 50$ PHWKRG FDOFXODWHV UHVSRQVH
WLPHIRUHDFKWDVNIRUDJLYHQUHDOWLPHVLWXDWLRQGHVFULELQJDVHW
78
œ
3UHGLFWLRQV DUH RYHUSHVVLPLVWLF GXH WR H[FOXGLQJ HIIHFWV RI
WKH DFFHOHUDWLRQ IDFLOLWLHV RI PRGHUQ &38¶V SLSHOLQHV
EUDQFK SUHGLFWLRQ EORFNV FDFKHV HWF 7KHVH HIIHFWV DUH
H[FOXGHG IURP WKH DQDO\VLV EHFDXVH RI XQSUHGLFWDEOH
EHKDYLRURIWKHDFFHOHUDWLRQIDFLOLWLHV
œ
9DULDWLRQ LQ EHKDYLRU GXH WR GLIIHUHQW LQSXW SDUDPHWHUV LV
GLIILFXOWWRDFFRXQWIRU7KLVUHTXLUHVDQDO\VLVRIDOOSRVVLEOH
SDWKV RI FRQWURO IORZ ZKLFK LV QRW SRVVLEOH IRU PDQ\
VLWXDWLRQV ZLWKRXW SURYLGLQJ DGGLWLRQDO LQIRUPDWLRQ
)RU WKH DVVHVVPHQW RI WLPHOLQHVV WZR DOWHUQDWLYH FODVVHV RI
WHFKQLTXHVZHUHFRQVLGHUHGDQDO\WLFDQGFRQVWUXFWLYHWHFKQLTXHV
7KHDSSOLFDELOLW\RIWKHVHWHFKQLTXHVLQWKHFRQWH[WRIFRPSRQHQW
EDVHGVRIWZDUHDUFKLWHFWXUHLVEHLQJYDOLGDWHGZLWKLQGXVWULDOFDVH
VWXGLHV
GHVFULELQJ WKH UHODWLRQ EHWZHHQ LQSXW GDWD DQG SURJUDP
EHKDYLRU
,W LV IRUHVHHQ WKDW WKHVH SUREOHPV RI WUDGLWLRQDO DSSURDFKHV PXVW
DOVR EH VROYHG IRU SHUIRUPLQJ ZRUVWFDVH H[HFXWLRQ WLPH
HVWLPDWLRQDWWKHDUFKLWHFWXUDOOHYHO
&XUUHQWO\ ZH DUH ZRUNLQJ RQ WKH LQWHJUDWLRQ RI WKH SURSRVHG
DUFKLWHFWXUHGHVFULSWLRQWHFKQLTXHVZLWKWKHHYDOXDWLRQWHFKQLTXHV
IRU WKH DQDO\VLV RI WLPHOLQHVV DQG PHPRU\ FRQVXPSWLRQ +HUH
WLPHGDXWRPDWDEDVHG WHFKQLTXHV DUH HVSHFLDOO\ SURPLVLQJ DV
WKH\KDYHWKHVDPHIRUPDOEDVLVERWKIRUWKHHYDOXDWLRQRITXDOLW\
DWWULEXWHVDQGWKHGHVFULSWLRQRIFRPSRQHQWEHKDYLRU
0HPRU\FRQVXPSWLRQHYDOXDWLRQ
,Q PDQ\ FDVHV DQDO\VLV RI PHPRU\ FRQVXPSWLRQ LV QHHGHG WR
UHDVRQ DERXW WKH IHDVLELOLW\ RI DQ HPEHGGHG V\VWHP 7KH
DOORFDWLRQ RI PHPRU\ FDQ EH G\QDPLF RU VWDWLF 6WDWLF PHPRU\
DOORFDWLRQ LV SHUIRUPHG DW FRPSLOH RU ORDGWLPH ZKLOH G\QDPLF
PHPRU\ DOORFDWLRQ LV SHUIRUPHG GXULQJ UXQWLPH )RU PRVW UHDO
WLPHRSHUDWLQJV\VWHPVWKHPHPRU\OD\RXWRIDQDSSOLFDWLRQ FDQ
EHSUHVHQWHGDVIROORZV
7KHUHDUHDQXPEHURIFKDOOHQJLQJWRSLFVIRUIXUWKHUUHVHDUFK
Œ
7R ILQG DQ DSSURSULDWH OHYHO RI DEVWUDFWLRQ IRU FRPSRQHQW
EHKDYLRUGHVFULSWLRQ7KHUHVKRXOGEHDEDODQFHEHWZHHQWKH
DFFXUDF\RIWKHGHVFULSWLRQUHOHYDQWSDUWVRIEHKDYLRUDUHQRW
RPLWWHGDQGWKHFRPSOH[LW\RIWKHHYDOXDWLRQ
Œ
7R HODERUDWH D PHWKRG IRU WKH VSHFLILFDWLRQ RI UHVRXUFH
FRQVXPSWLRQ ,W LV LPSRUWDQW WR EH DEOH WR LQWHJUDWH WKH
VSHFLILFDWLRQ RI UHVRXUFH FRQVXPSWLRQ LQ WKH GHVFULSWLRQ RI
FRPSRQHQWVWRHQDEOHWKHHYDOXDWLRQRITXDOLW\DWWULEXWHV
Œ
7R GHYHORS D IRUPDO PHWKRGRORJ\ IRU WKH HYDOXDWLRQ RI
ZRUVWFDVHPHPRU\FRQVXPSWLRQ
Œ
7RGHYHORSDPHWKRGIRUUHODWLQJ06&EDVHGGHVFULSWLRQVWR
WLPHGDXWRPDWDEDVHGRQHV
6WDWLFDOO\ DOORFDWHG PHPRU\ WKH LPDJH RI SURJUDP FRGH
VWDWLFGDWDVWDFNDQGKHDS
'\QDPLFDOO\DOORFDWHGPHPRU\VWDFNVIRUGLIIHUHQWWKUHDGV
GDWDREMHFWVDOORFDWHGLQWKHKHDS
$QDO\VLV RI PHPRU\ DYDLODELOLW\ IRU WKH VWDWLF DOORFDWLRQ
PHFKDQLVP LV WULYLDO LQ PRVW FDVHV ,W LV HQRXJK MXVW WR VXPPDWH
WKHVL]HVRI DOO PHPRU\ EORFNV QHHGHG IRU DOO WDVNV DQG FRPSDUH
WKHUHVXOWZLWKWKHDPRXQWRIDYDLODEOHV\VWHPPHPRU\+RZHYHU
WKLVKROGVRQO\IRUELQDU\FRPSRQHQWV
7KH VLWXDWLRQ ZRUVHQV ZKHQ GHDOLQJ ZLWK WKH PHFKDQLVPV IRU
G\QDPLF PHPRU\ DOORFDWLRQ ,Q WKLV FDVH WKH SKHQRPHQRQ RI
IUDJPHQWDWLRQ FDQ EH REVHUYHG 8VXDOO\ WKH IUDJPHQWDWLRQ LV
FDXVHGE\LQWHUOHDYHGVHTXHQFHRIPHPRU\EORFNDOORFDWLRQVDQG
GHDOORFDWLRQVZLWKJUHDWO\YDU\LQJEORFNVL]H,WLVUDWKHUGLIILFXOW
WR HYDOXDWH WKH LPSDFW RQ PHPRU\ DOORFDWLRQ LQGXFHG E\ WKH
IUDJPHQWDWLRQ 0RUHRYHU KDYLQJ WKH PHPRU\ VKDUHG EHWZHHQ
GLIIHUHQW WDVNV UHVXOWV LQ DGGLWLRQDO LQWHUIHUHQFH WKDW PDNHV WKH
PHPRU\EHKDYLRUHYHQOHVVSUHGLFWDEOH
5()(5(1&(6
>@ * $ERZG / %DVV 5 .D]PDQ 0 :HEE 6$$0 $
0HWKRG IRU $QDO\]LQJ WKH 3URSHUWLHV RI 6RIWZDUH
$UFKLWHFWXUH LQ 3URFHHGLQJV RI WKH WK ,QWHUQDWLRQDO
&RQIHUHQFHRQ6RIWZDUH(QJLQHHULQJ,WDO\0D\
>@ 5 $OOHQ DQG ' *DUODQ $ )RUPDO %DVLV IRU $UFKLWHFWXUDO
&RQQHFWLRQ $&0 7UDQVDFWLRQV RQ 6RIWZDUH (QJLQHHULQJ
DQG0HWKRGRORJ\-XO\
7KHPRVWFRPPRQSUDFWLFHIRUKDUGUHDOWLPHV\VWHPVLVWRDYRLG
WKH XVH RI G\QDPLF PHPRU\ PDQDJHPHQW WR LQFUHDVH WKH
SUHGLFWDELOLW\ DQG HIILFLHQF\ ,QVWHDG GDWD LV DOORFDWHG VWDWLFDOO\
1HYHUWKHOHVV VRPH UHVHDUFK RQ WKH HYDOXDWLRQ RI G\QDPLF
PHPRU\DOORFDWLRQKDVEHHQGRQHHJLQ>@E\=RUQHWDO7KHLU
PHWKRGHPSOR\VV\QWKHWLFDOORFDWLRQWUDFHVWKHDOORFDWLRQWUDFHRI
DQ DFWXDO SURJUDP LV PRGHOHG ZLWK D VWRFKDVWLF SURFHVV 7KLV
PHWKRGLVUHSRUWHGWRSURYLGHUHVXOWVZLWKDFFXUDF\7KXVLW
PLJKW EH DSSOLFDEOH IRU WKH HDUO\ DQDO\VLV RI ZRUVWFDVH G\QDPLF
PHPRU\FRQVXPSWLRQDVPRUHSUHFLVHHVWLPDWLRQVDUHQRWQHHGHG
GXULQJ WKH DUFKLWHFWLQJ SKDVH $QRWKHU DSSURDFK LV EDVHG RQ WKH
DEVWUDFW LQWHUSUHWDWLRQ WKHRU\ WKLV PHWKRG DXWRPDWLFDOO\
WUDQVIRUPV D KLJKOHYHO ODQJXDJH SURJUDP LQWR D IXQFWLRQ
FDOFXODWLQJ WKH ZRUVWFDVH XVDJH RI VWDFN DQG KHDS VSDFH VHH
>@ 7KLV DSSURDFK PLJKW DOVR EH DSSOLFDEOH GXULQJ WKH
DUFKLWHFWLQJ
>@ 5 $OXU '/ 'LOO $ 7KHRU\ RI 7LPHG $XWRPDWD LQ
7KHRUHWLFDO&RPSXWHU6FLHQFH 9RO 1R $SULO SS
>@ 0%DUEDFFL6-&DUULHUH3)HLOHU5.D]PDQ0.OHLQ
+ /LSVRQ 7 /RQJVWDII DQG & :HLQVWRFN 6WHSV LQ DQ
$UFKLWHFWXUH 7UDGHRII $QDO\VLV 0HWKRG 4XDOLW\ $WWULEXWH
0RGHOV DQG $QDO\VLV 7HFKQLFDO 5HSRUW &086(,75
>@ $ %XUQV +RZ WR 9HULI\ D 6DIH 5HDO7LPH 6\VWHP 7KH
$SSOLFDWLRQ RI 0RGHO &KHFNLQJ DQG D 7LPHG $XWRPDWD WR
WKH3URGXFWLRQ&HOO&DVH6WXG\7HFKQLFDOUHSRUW5HDO7LPH
6\VWHP 5HVHDUFK *URXS 'HSDUWPHQW RI &RPSXWHU 6FLHQFH
8QLYHUVLW\RI<RUN
>@ $
'DYLG
833$//
N
6PDOO
7XWRULDO
KWWSZZZGRFVXXVHGRFVUWPYXSSDDOWXWRULDOSGI
&21&/86,21
7KH IRUHVHHQ IUDPHZRUN IRU FRPSRQHQWEDVHG VRIWZDUH
DUFKLWHFWLQJ LV VXSSRVHG WR DGGUHVV WKH IROORZLQJ UHDVRQLQJ
DERXW FRPSRVDELOLW\ RI EHKDYLRU WKH HDUO\ DVVHVVPHQW RI
TXDOLW\DWWULEXWHV
>@ $)HKQNHU6FKHGXOLQJDVWHHOSODQWZLWKWLPHGDXWRPDWD,Q
3URFHHGLQJV RI WKH WK ,QWHUQDWLRQDO &RQIHUHQFH RQ 5HDO
7LPH &RPSXWLQJ 6\VWHPV DQG $SSOLFDWLRQV 57&6$
SDJHV,(((&RPSXWHU6RFLHW\
)RUWKHVSHFLILFDWLRQRIFRPSRQHQWEHKDYLRUWLPHGDXWRPDWDDUH
VXJJHVWHG ZKLOH WKH VSHFLILFDWLRQ RI FRPSRQHQW LQWHUDFWLRQ LV
GHVFULEHG ZLWK 0HVVDJH 6HTXHQFH &KDUWV 06& ZKLFK DOORZ WR
YLYLGO\UHSUHVHQWWLPLQJFRQVWUDLQWVLQWKHHQGWRHQGPDQQHU
>@ '*LDQQDNRSRXORX-.UDPHUDQG6&KHXQJ$QDO\VLQJWKH
%HKDYLRXU RI 'LVWULEXWHG 6\VWHPV XVLQJ 7UDFWD -RXUQDO RI
$XWRPDWHG 6RIWZDUH (QJLQHHULQJ VSHFLDO LVVXH RQ
79
>@& /LX - /D\ODQG 6FKHGXOLQJ $OJRULWKPV IRU
0XOWLSURJUDPPLQJ LQ +DUG 5HDO 7LPH (QYLURQPHQW
-$&0
$XWRPDWHG $QDO\VLV RI 6RIWZDUH 9RO SS -DQXDU\
>@ ' . +DPPHU DQG 059 &KDXGURQ &RPSRQHQW 0RGHOV
IRU5HVRXUFH&RQVWUDLQW6\VWHPV:KDWDUHWKH1HHGV"3URF
WK ,QW :RUNVKRS RQ 2EMHFW2ULHQWHG 5HDO7LPH
'HSHQGDEOH6\VWHPV:25'65RPH-DQXDU\
>@- 0DJHH 1 'XOD\ 6 (LVHQEDFK - .UDPHU 6SHFLI\LQJ
'LVWULEXWHG 6RIWZDUH $UFKLWHFWXUHV ,Q 3URFHHGLQJV RI WK
(XURSHDQ6RIWZDUH(QJLQHHULQJ&RQIHUHQFH6SDLQ
>@5 YDQ 2PPHULQJ ) YDQ GHU /LQGHQ DQG - .UDPHU DQG -
0DJHH 7KH .RDOD &RPSRQHQW 0RGHO IRU &RQVXPHU
(OHFWURQLFV 6RIWZDUH &RPSXWHU SS >@'.+DPPHU&RPSRQHQWEDVHGDUFKLWHFWLQJIRUGLVWULEXWHG
UHDOWLPH V\VWHPV +RZ WR DFKLHYH FRPSRVDELOLW\" ,QW
6\PSRVLXP RQ 6RIWZDUH $UFKLWHFWXUHV DQG &RPSRQHQW
7HFKQRORJ\ 6$&7 (QVFKHGH 1HWKHUODQGV -DQXDU\ WREHSXEOLVKHGE\.OXZHU
>@0$ 5HQLHUV 0HVVDJH 6HTXHQFH &KDUW 6\QWD[ DQG
6HPDQWLFV3K'WKHVLV78(
>@',.DWFKHU666DWKD\H-.6WURVQLGHU)L[HGSULRULW\
VFKHGXOLQJZLWKOLPLWHGSULRULW\OHYHOV,(((7UDQVDFWLRQVRQ
&RPSXWHUV
>@&6]\SHUVNL&RPSRQHQW6RIWZDUH%H\RQG2EMHFW2ULHQWHG
3URJUDPPLQJ$GGLVRQ:HVOH\
>@0+.OHLQ75DO\D%3ROODN52EHQ]D+*RQ]DOH]$
3UDFWLWLRQHUV +DQGERRN IRU 5HDO7LPH $QDO\VLV *XLGH WR
5DWH 0RQRWRQLF $QDO\VLV IRU 5HDO7LPH 6\VWHPV %RVWRQ
0$.OXZHU$FDGHPLF3XEOLVKHUV
>@/ 8QQLNULVKQDQ 6 ' 6WROOHU < $ /LX $XWRPDWLF
DFFXUDWHVWDFNVSDFHDQGKHDSVSDFHDQDO\VLVIRUKLJKOHYHO
ODQJXDJHV 7HFKQLFDO 5HSRUW 75 &RPSXWHU 6FLHQFH
'HSDUWPHQW,QGLDQD8QLYHUVLW\)HE
>@. - .ULVWRIIHUVHQ . * /DUVHQ 3 3HWWHUVVRQ DQG &
:HLVH([SHULPHQWDO%DWFK3ODQW9+6&DVH6WXG\8VLQJ
7LPHG $XWRPDWD DQG 833$$/ 'HOLYHUDEOH RI (35,7/75
3URMHFW9+69HULILFDWLRQRI+\EULG6\VWHPV
>@$ :DOO & (ULFVVRQ DQG : <L 7LPHG $XWRPDWD DV 7DVN
0RGHOVIRU(YHQW'ULYHQV\VWHPV,Q3URFHHGLQJVRI576&$
,(((3UHVV
>@- :DUQHU $ .OHSSH 7KH 2EMHFW &RQVWUDLQW /DQJXDJH
$GGLVRQ:HVOH\
>@3% /DGNLQ 6 /HXH ,QWHUSUHWLQJ PHVVDJH IORZ JUDSKV
)RUPDO$VSHFWVRI&RPSXWLQJ
>@% =RUQ ' *UXQZDOG (YDOXDWLQJ PRGHOV RI PHPRU\
DOORFDWLRQ $&0 7UDQVDFWLRQV RQ 0RGHOLQJ DQG &RPSXWHU
6LPXODWLRQ
>@*7 /HDYHQV 0 6LWDUDPDQ )RXQGDWLRQV RI FRPSRQHQW
EDVHGV\VWHPV&DPEULGJH8QLYHUVLW\3UHVV
>@- /HKRF]N\ / 6KD < 'LQJ 7KH 5DWH 0RQRWRQLF
6FKHGXOLQJ$OJRULWKP ([DFW &KDUDFWHUL]DWLRQ DQG $YHUDJH
&DVH%HKDYLRU,(((5HDO7LPH6\VWHPVV\PSRVLXP
80
Type Handling in a Fully Integrated Programming and
Specification Language
Gregory Kulczycki
Clemson University
Clemson, SC
[email protected]
ABSTRACT
bine formal specification with programming. Examples of
such unions include JML, Eiffel, Resolve/C++1 , Z variants, and Larch variants [3, 7, 9, 15]. Most of these integrated languages have resulted from appending a specification language onto a preexisting programming language.
In contrast, Resolve [12, 14] has been developed from the
beginning as both a specification and a programming language. The language is only one part of the Resolve system for predictable software development. The system also
includes a framework and discipline for building software
that is—among other things—reusable, verifiable, efficient,
and understandable. The language is intimately tied to the
framework and discipline.
Integrated languages combine formal specification and programming features, and make it possible to specify, implement, and verify programs within the same framework. This
paper examines the consequences of this fundamental integration on the type system of a software engineering language, using Resolve as an example. It explains why name
matching for program types coexists naturally with structural matching for math types. It describes a formulation of
set theory and its relationship to the type system. And it
poses a variety of discussion questions concerning the use of
types and subtypes in the specification portion of the language.
For the past few years the author of this paper has been involved in designing and implementing tools that would bring
Resolve into the world of practical programming. The current focus of this effort is the development of a Resolve
compiler. The project is complex, not only because the compiler must deal with a programming and specification language combined, but because ongoing research makes the
language a moving target (e.g., performance specification
and verification [13]). During the course of writing the compiler we have been forced to refine our ideas about how types
should be handled in both mathematical and programming
contexts.
Keywords
Type checking, verification, subtypes, set theory, software
engineering
1.
INTRODUCTION
Verification of component-based software requires languages
that integrate programming and specification features, and
types are at the heart of this integration. Programming
languages are not suited for specification, and specification
languages are not used for implementation. The elements
of both languages must be integrated to verify that an implementation is correct with respect to a specification. This
requires that programming objects—in particular, types—
be described in mathematical terms. A wealth of papers
have been written about types and type systems, but these
papers invariably focus on types in programming (implementation) languages or types in specification languages.
The contribution of this paper is its description of a type
system for languages concerned with both implementations
and specifications.
This paper addresses the following question: What are the
implications for the type system in a language that integrates programming and specification? Using Resolve as
an example, we look for answers to this question. Section 2
presents the type model of Resolve and demonstrates how
types are treated in programming and mathematical contexts. Section 3 summarizes Ogden’s formulation of set theory in Resolve [10] and explains how it relates to types.
Finally, section 4 examines a few specific issues involving
math types and subtypes.
The desire to build predictable, component-based software
has compelled many in the software verification community to develop integrated languages—languages that com-
2. OVERVIEW OF TYPES
An integrated language is much more complex than either
a programming language or specification language alone, so
simplicity is a primary concern. It is essential to have type
matching rules that are easily understandable. A programmer (or compiler) should not have to sift through a myriad
of rules and exceptions simply to evaluate the type of an
expression.
1
Resolve/C++ uses only the specification portion of the
Resolve language
81
Concept Stack Template(type Entry;
evaluates Max Depth: Integer);
uses Std Integer Fac, String Theory;
requires Max Depth > 0;
Realization Array Realiz for Stack Template;
Type Stack is represented by Record
Contents: Array 1..Max Depth of Entry;
Top: Integer;
end;
conventions 0 ≤ S.Top ≤ Max Depth;
correspondence

Rev
|S.Top|
Y
Conc.S = 
hS.Contents(i)i ;
Type Family Stack is modeled by Str(Entry);
exemplar S;
constraints |S| ≤ Max Depth;
initialization ensures S = Λ;
Operation Push(alters E: Entry; updates S: Stack);
requires |S| < Max Depth;
ensures S = h#Ei ◦ #S;
i=1
initialization
S.Top := 0;
end;
···
Procedure Push(alters E: Entry; updates S: Stack);
···
end Push;
end Stack Template;
Figure 1: A Concept for Stack
···
Mathematical and programming elements in the Resolve
language are kept as distinct as possible. Thus, assertions in
requires and ensures clauses2 of operations are strictly mathematical expressions, and conditions in while loops and if
statements are strictly programming expressions. Likewise,
all variables and types found in a mathematical expression
are math variables and math types, and those found in programming expressions are program variables and program
types. This means that the same name has a different type
depending on whether it appears in a programming or mathematical context. Furthermore, mathematical expressions
and programming expressions are type-checked differently—
in mathematical expressions, types are matched according
to structure, whereas in programming expressions, they are
matched strictly by name.
end Array Realiz;
Figure 2: A Realization for Stack
piler analyzes it as a math variable. The variable S has been
declared as program type Stack, but since the variable occurs in a mathematical context, the compiler instead uses
the mathematical model of Stack given in the type family declaration. So the variable S appearing in the requires
clause has math type Str(Entry). The rest of the concept is
analyzed similarly.
In Resolve, like in other model-based languages such as
VDM and Z, a handful of math types are used for modeling
many different program types. This mirrors scientific disciplines like Physics, where the same mathematical model
is used to capture widely different concepts. Different program types such as Stack and Queue may both be modeled
using mathematical strings. This makes it convenient to
write specifications such as the one shown here:
2.1 Math vs Program Context
Figure 1 shows a Resolve specification of a Stack component. This simple example turns out to be sufficiently powerful to illustrate the ideas in this paper. The Type Family
declaration introduces the program type Stack and gives its
mathematical model. We use Type Family instead of just
Type because the concept (and therefore the type) is generic
until it is instantiated, so the declaration of Stack here encompasses an entire family of types. In the type family
declaration, the left side contains the program type Stack,
and the right side contains the math type Str(Entry). The
fact that mathematical and programming elements come together in a type declaration underscores the fundamental
role that types play in an integrated language. The exemplar introduces a variable of type Stack to describe properties that hold for any arbitrary variable of type Stack. For
example, the constraints clause indicates that the length
of any Stack must always be less than Max Depth.
Operation Stk Q Transfer(clears S: Stack;
replaces Q: Queue);
ensures Q = #SRev ;
2.2 Structural vs Name Matching
The implementation or realization of Stack Template in Figure 2 introduces a Stack type with a specific programming
structure. It indicates how a Stack is represented for this
particular realization. The conventions clause provides the
representation invariant—it indicates which representation
states are permitted. The correspondence clause, or abstraction relation, shows how this representation is related to
the mathematical model of Stack given in the concept. Notice that the correspondence clause contains two variables,
S and Conc.S, that are not declared directly in this scope.
These variables are derived from the special exemplar variable in the concept’s type declaration. Figure 3 illustrates
what the compiler does when analyzing the declaration of
Stack in a realization. It locates the exemplar from the type
In the specification of Operation Push, parameters E and
S are program variables. When a call is made to this operation, the compiler checks that the first argument to Push
is of type Entry, and the second argument is of type Stack.
When S appears in the requires clause, however, the com2
preconditions and postconditions
82
Stack Concept
Stack Realization
Module Scope
Module Scope
Type Scope
Type Scope
exemplar S
Table 1: Type Evaluations of Variables
Variable
Program Type Math Type
S
Stack
(Z → Entry) × Z
S.Contents
%Array(10,20) Z → Entry
S.Contents(1) Entry
Entry
S.Top
Integer
Z
S: Stack
Conc.S: Str(Entry)
(denoted by the infix operator →)3 [10]. Also, the program
type Integer is modeled by the mathematical integers Z.4
The generic type Entry is treated as a primitive type when
seen from a math context because its math model is not
known before instantiation.
Figure 3: Affect of Exemplar on Realization
Now consider a variable S of type Stack. Table 1 shows how
a compiler will evaluate the variables in the first column depending on whether they occur in a program or math context. For example, if S.Contents occurs in a requires clause,
it evaluates to the math type Z → Entry. If the variable
S.Top occurs in the condition of a while loop, it evaluates
to the program type Integer. The type %Array(10,20) is a
unique name created by the compiler.
family declaration in the corresponding concept, and uses
its name to create two variables within the type scope of
the realization. The first variable is named S and has program type Stack. The second variable is named Conc.S
(read as “the conceptual value of S”) and has math type
Str(Entry), the mathematical model of Stack. The correspondence clause describes the relationship between these
two variables.
A compiler for Resolve must keep track of more type information than typical compilers. It must have access to
the program name of the type, the program structure of the
type, and the math structure of the type. The program
structure of the type is not needed for matching purposes,
but it is needed to determine whether variables of that type
may use the special syntax of Records or Arrays. For example, since the type Stack in the realization above is structurally a record, any variable S of type Stack can use special
syntax to refer its fields—S.Contents and S.Top.
Program type matching in Resolve is done strictly by name.
This is reasonable because a primary motivation for introducing different type names is to keep objects of different
types distinct. Also, in a language that separates interfaces (as specifications) from implementations, clients will
not have access to the structural programming representation of a type, so that structural matching can not be accomplished consistently.
3. SET THEORY
Math type matching is done by structure. The structure
consists of math types that can be simple or composite.
If a program type name is encountered in a mathematical
context, the compiler uses its corresponding mathematical
model to convert it to a math type expression. In Resolve,
like in Z, built-in composite types include set theory operators ×, →, and P. Composite types are parameterized types
that take other types as arguments. Resolve also permits
the use of user-defined composite types. In the type expression Str(Entry), Str is a user-defined composite type
(defined in the module String Theory, which is imported
through the uses clause in Figure 1). For a composite math
type to match another by structure, the types of their arguments must also match. For example, Queue × Fahrenheit
matches Stack × Centigrade if and only if the mathematical
models of Queues and Stacks match, and the mathematical
models of Fahrenheit and Centigrade match. Constraints
on mathematical models—given by the constraint clause in
the type family declaration—are ignored by the analyzer;
checking constraints is the responsibility of the verifier.
Sets are the fundamental building blocks of the Resolve
language. There are several reasons why sets are a natural
choice. First and most importantly, sets are foundational to
Mathematics. All programming objects must have a mathematical model, and sets can be used to describe any mathematical domain. No matter how complicated a real world
problem is, it can be captured with sets. The same could not
be said if we were to use, say, real numbers, as the building
blocks of the language. Another reason for using sets is that
the basic notions of sets—membership, union, subset, and
so forth—are familiar to most students and programmers.
Finally, sets are flexible enough to describe the language
itself.
3.1 Echelons
The particular flavor of set theory used in Resolve has been
developed by Bill Ogden at The Ohio State University [10].
The core of the theory is traditional: It starts with the notion of a universe of all sets (Set ) and uses the notion of
membership (∈) as a basis for defining all the operators we
expect to see on sets (∪, ∩, ⊆, P, →, etc.). A distinguishing
To illustrate the difference between name matching in the
programming world and structural matching in the math
world, consider the type declaration of Stack in figure 2.
The representation uses both a record and an array, which
are composite program types. In Resolve, the type Record
is modeled by a Cartesian product (denoted by the infix
operator ×), and the type Array is modeled by a function
3
Strictly speaking, the Resolve type Array is modeled
by a Cartesian product composed of a function and two
integers—one for each bound.
4
This model will obviously have constraints, involving minimum and maximum values, but recall that constraints are
ignored during type-checking
83
aspect of the theory is the notion of special sets known as
echelons. Echelons are large universes of sets that are closed
under the operations of ordinary set theory, such as unions
and power sets.
Most often only the first two will be seen. The first type, T0 ,
is a simple type, while the remaining types are composite.
Like all composite types, primitive composite types cannot
be used in isolation—they must have parameters. For example, if Str: Set → Set, then one cannot declare x: Str,
but one can declare an x: Str(Gamma), where Gamma: Set.
The motivation for echelons comes from the need to provide
a collection of sets that is (1) large enough to model everything one would normally want to model in a computer
program, and (2) small enough that it does not exhaust all
the sets in Set . Henceforth, let the set Set (pronounced “fat
set”) denote the collection which we draw from to model
all program objects in our language. Certainly Set must
have sufficient modeling power for all programming objects.
Using Set as Set, however, would not leave a specifier any
sets to describe the language with. For example, one would
require sets that were larger than Set when writing the specifications for a Resolve compiler that was written in Resolve.
A primitive type, like every other object in Resolve, is a
set. Abstractly, a type is distinguished from other sets of
the same cardinality by its properties. For example, it can
be shown that the sets N and Z have the same cardinality,
but the set N is not closed under subtraction, while the set
Z is. Primitive types in Resolve are introduced via two
constructs. First, a definition spells out the properties of
the type:
Def Is Natural Number Like(N: Set, 0: N,
suc: N → N): B =
(*P1*) ∀n : N, suc(n) 6= 0 and
(*P2*) Is Injective(suc) and
(*P3*) ∀S : P(N),
if 0 ∈ S ∧ ∀n : N, n ∈ S ⇒ suc(n) ∈ S
then S = N;
To provide sufficient models for programming objects, Set
must be closed under the basic type operations of the language. Assume A and B are types that are modeled by
sets in Set. Then any type expression that can be derived
from A and B must also be contained in Set. Resolve
currently permits the operators ×, →, and P in type expressions. Therefore, if A and B are elements of Set, A × B,
A → B, and P(A) must also be elements of Set.
Then an assumption introduces a set that satisfies that definition:
Assumption Is Natural Number Like(N, 0, suc);
Echelons are closed under these basic operations. The properties of echelons include closure under membership, pairing,
unions and power sets, which means they are also closed
under operators × and →.5 We can define an echelon operation on A, E(A), to be the smallest echelon that contains
A. If we take E0 = φ, then E1 = E(E0 ) contains the sets
φ, P(φ), P(P(φ)), . . . , which are traditionally used to model
the natural numbers. It can be shown that E1 is only countably infinite, so it will not be large enough for real world
models. E2 = E(E1 ), however, does provide sufficient sets.
It contains models for N, R, P(R), R × R, R → R, etc.
The properties in the definition (P1–P3) mirror the axioms
one would normally see in an axiomatic description of the
natural numbers. The approach of using definitions to describe the properties of a type simplifies the semantics of the
language—we do not have to concern ourselves with special
syntax and semantics for signatures and axioms. In Resolve, definitions are used to introduce all mathematical
objects, whether they are constants, variables, functions, or
types. The above assumption indicates that the set N (together with sets 0 and suc) is any arbitrary model of the
natural numbers. This enforces abstractness because the
natural numbers are not identified with one particular representation.
If Set is at least E2 we know it has sufficient modeling power
for all ordinary programs. In Resolve, Set is generally assumed to be E2 , but whether it is E2 , or E3 , or E100 , the
important fact is that a specifier still has access to E(Set) to
describe the language itself. A rigorous treatment of echelons can be found in [10]. The objective of this summary is
only to present enough information to give an idea of their
significance for program specification.
3.3 Objects as Sets
Every programming object in the Resolve language can
be modeled by a set contained in Set. That is, any variable,
function, or type that occurs in a programming context must
lie within Set. Though math objects are exempt from this
restriction, most math objects seen in programs will also
be in Set because they are typically used to describe program objects. When we want to describe complex software
like compilers and verifiers, our specifications will draw on
objects that lie outside of Set.
3.2 Primitive Types
If sets are the building blocks of the Resolve language,
then primitive types are the cornerstones on which the other
blocks rest. Declarations of primitive types take the form:
T0
T1
T2
T3
..
.
:
:
:
:
Set
Set → Set
Set × Set → Set
Set × Set × Set → Set
Simple primitive types are directly contained in Set, and
composite primitive types always take parameters, which
also puts them in Set. The set operators that we are permitted to use in math type expressions (×, →, and P) are
all closed under echelons. Since all math types that are used
to model program types are constructed by applying composite types and set operators to other math types, all such
math types are in Set.
5
Assuming appropriate
S definitions of × and →, we can show
that A × B ⊆ P(P( {A, B})), and A → B ⊆ P(A × B).
84
All program types have a mathematical model, which is a
math type expression. The declaration:
To analyze this expression, a compiler needs to know that
Even is a subtype of N, and it must have an algorithm that
determines which + operator to use if there is more than
one choice. This can become non-trivial, and as a rule, if
something is complex for the compiler, it is also conceptually
complex for the programmer or specifier. One way to simplify things is to require explicit type casting, so the above
expression would produce an error if there were no + operator defined that took two objects of type Even. To use the
+ from natural number theory, a specifier might be forced
to write:
Type Family Stack is modeled by Str(Entry);
is the text equivalent to:
Type Family Stack ⊆ Str(Entry);
The subset operator is used instead of the equal operator
because of constraints on the model. For an example, see
Figure 1.
∀e1, e2 : Even, ∃n : N  2 · n = (N)e1 + (N)e2;
All programming objects in Resolve belong to some type,
as indicated by the type membership operator (:). Since
all types are modeled by sets in Set, the type membership
operator can be replaced with set membership (∈) to describe the mathematical relationship between an object and
its type. Finally, since Set is closed under membership, all
programming objects must be in Set.
4.
This makes the expression harder to write since the specifier must do the work that the compiler would have done
to decide which + should be be used. In Resolve, where
emphasis is on qualities such as reuse and understandability, readability usually takes precedence over writability. In
this example, there is an argument for both sides in terms
of readability. If the + operator is overloaded in an unconventional way, explicit casting may clarify things; if the
+ operator is not overloaded at all, explicit casting simply
adds unnecessary clutter to the expression.
DISCUSSION TOPICS
During type-checking, a compiler needs to be concerned with
a number of questions, such as how to treat subtypes, when
to require casts, when to report errors, and when to give
warnings. Although these questions must be answered for
both program and math types, we focus on how they apply to math types, mainly because of the rich diversity of
views on how types should be handled in specification languages, ranging from traditionalists [2, 3, 15] to those whose
type systems incorporate theorem provers [11] to those who
question the necessity of type systems altogether [6]. Issues
involving program subtypes will largely depend on how the
language in question handles polymorphism, a topic that
merits a separate paper.
In some programming languages, casting to a parent type
is implicit, but casting to a subtype must be explicit. An
analogous example in the math world might define:
Definition Vertex : P(Z) = {z : Z | 1 ≤ z ≤ Max Vert};
Definition Cost(G : Graph; v1, v2 : Vertex) : R6
If casting to a subtype is required, one must write
∀G : Graph, ∀z1, z2 : Z,
Cost(G, (Vertex)z1, (Vertex)z2) ≤ 4.7;
The distinction between types and other objects (variables
and functions) is quite clear in the programming world: program types are introduced by the keyword Type. However, in the math world all objects—variables, functions,
and types—are introduced by the keyword Definition or
through quantifiers in expressions. This uniformity is intentional, since all objects are sets, but it forces specifiers and
compilers to rely on other cues to tell them which mathematical objects can be used as types. Examples based on
subtypes are discussed in this section.
(1)
instead of
∀G : Graph, ∀z1, z2 : Z, Cost(G, z1, z2) ≤ 4.7;
(2)
This may seem quite reasonable for a programmer, but some
specifiers may consider the following expression perfectly
reasonable:
∀G : Graph, ∀z1, z2 : Z, if z1, z2 ∈ Vertex
then Cost(G, z1, z2) ≤ 4.7;
If an object T is declared to be of type P(A) where A is a
type, then T is also a type, and we say that T is a subtype
of A. Permitting such declarations requires the language to
have reasonable semantics for handling the relationship between the type T being declared and the type A being used
in the declaration. Consider the definition:
(3)
There is nothing wrong with expression (3) as a mathematical formula, and it is obvious that the Cost function is defined for all z1, z2 ∈ Vertex. But if we insist that the compiler must report a type error for expression (2), then we
must insist that it does the same for expression (3). There
may be merit in exploring ways that allow the specifier more
flexibility in writing expressions while still insisting that he
provide sufficient clues to the compiler of his intentions. For
example, we might allow:
Definition Even : P(N) = {n : N | n mod 2 = 0};
It is reasonable to want to declare objects of type Even and
add them together using the + operator defined in Natural Number Theory (the theory introducing N). The type
of the result would be N, so a specifier could write:
∀G : Graph, ∀z1, z2 : Z, if z1, z2 : Vertex
then Cost(G, z1, z2) ≤ 4.7;
(4)
6
We can imagine that the Cost function indicates the expense of traveling from v1 to v2 in graph G.
∀e1, e2 : Even, ∃n : N  2 · n = e1 + e2;
85
Expression (4) replaces the set membership operator (∈) of
expression (3) with a type membership operator (:). This
could indicate to the compiler that z1 and z2 are to be
treated as belonging to type Vertex for the remainder of
the expression scope. Unfortunately, we would have to develop another mechanisms for the case where the if part of
expression (4) were in a precondition and the then part of
the expression were in a postcondition. If we introduce too
many distinct mechanisms for handling a conceptually similar situation we run the risk of significantly complicating
the language.
to describe this relationship. Practical concerns compel us
to treat programming and mathematical objects differently.
Program types should match according to their names, and
math types should match according to their structure.
All of the questions that arise with subtypes due to the
power set operator may occur with primitive types as well.
It is reasonable to think of N, Z, and R as distinct types—
after all, their algebraic structures are different. It is also
reasonable to want to treat N as a subset of Z and Z as a
subset of R. If these relationships between primitive types
are desired, a mechanism different from the one for subtypes
must be provided that allows the compiler to treat them as
such.
The handling of subtypes in the specification portion of an
integrated language offers a series of trade-offs. Systems that
allow a specifier greater flexibility in writing expressions run
the risk of permitting poor expressions that could be caught
quickly with a less tolerant type system.
5.
The theoretical basis of the specification language will affect
which objects can be used as types, and will determine the
kinds of models that can be constructed for program objects.
We need to distinguish sets that model real world objects
in a language from larger sets that are needed to describe
compilers and verifiers for that language.
7. ACKNOWLEDGMENTS
Several people contributed important ideas to this work and
made helpful comments about drafts of this article. I would
especially like to thank Murali Sitaraman, Bill Ogden and
Steven Atkinson.
RELATED WORK
Many examples of integrated languages exist, though the
degree of integration varies widely. Eiffel [9] is essentially
a programming language with a few specification features
built in. Like Resolve, it was created independently of
any preexisting programming language; unlike Resolve, its
specification features are limited—it does not include a complete formal specification language (see p. 400 of [9]). JML
(Java Modeling Language) [7] is a behavioral specification
language that was created for Java. Used together, JML
and Java form an integrated language. Unlike Eiffel, JML
provides models for its programming objects. Mathematical expressions in both Eiffel and JML are designed to look
similar to programming expressions. Accordingly, they will
also type-check similarly. Recall that Resolve type-checks
mathematical expressions by structure and programming
expressions by name. Resolve/C++ [5] applies the Resolve framework and discipline to the C++ programming
language. It uses the specification portion of the Resolve
language for reasoning. Integrated languages formed by
combining a preexisting specification language with a preexisting programming language will type-check mathematical
expressions in accordance with the rules of the specification
language and will type-check programming expressions in
accordance with the rules of the programming language.
We also gratefully acknowledge financial support from our
own institutions, from the National Science Foundation under grants CCR-0113181, DUE-9555062, and CDA-9634425,
from the Fund for the Improvement of Post-Secondary Education under project number P116B60717, and from the
Defense Advanced Research Projects Agency under project
number DAAH04-96-1-0419 monitored by the U.S. Army
Research Office. Any opinions, findings, and conclusions or
recommendations expressed in this paper are those of the authors and do not necessarily reflect the views of the National
Science Foundation, the U.S. Department of Education, or
the U.S. Department of Defense.
8. REFERENCES
[1] M. Abadi and L. Cardelli. On subtyping and
matching. ACM Transactions on Programming
Languages and Systems, 18(4):401–423, July 1996.
[2] D. Gries and F. B. Schneider. A Logical Approach to
Discrete Math. Springer-Verlag, New York, 1993.
[3] J. V. Guttag and J. J. Horning. Larch: Languages and
Tools for Formal Specification. Springer-Verlag, New
York, 1993.
Most practical specification languages allow some form of
subtyping [2, 7, 15]. The PVS verification system [11] permits downcasting to predicate subtypes by generating a proof
obligation when a type is detected in a place where its subtype is expected. Problems similar to those presented in
section 4 cause Lamport to question whether specification
languages should be typed at all [6]. Topics relating to program subtypes include behavioral subtypes [8] and matching [1].
[4] D. E. Harms and B. W. Weide. Copying and
swapping: Influences on the design of reusable
software components. IEEE Transactions on Software
Engineering, 17(5):424–435, May 1991.
6.
[6] L. Lamport and L. C. Paulson. Should your
specification language be typed? ACM Trans.
Program. Lang. Syst., 21(3):502–526, May 1999.
[5] J. Hollingsworth, L. Blankenship, and B. W. Weide.
Experience report: Using RESOLVE/C++ for
commercial software. In Proceedings SIGSOFT FSE.
ACM, November 2000.
CONCLUSION
Integrated languages must have an effective method for handling program and math types. Integration requires that
a mechanism exist for relating programming and mathematical elements. Type declarations are a natural place
[7] G. T. Leavens, A. A. Baker, and C. Ruby. JML: A
notation for detailed design. In H. Kilov, B. Rumpe,
86
and I. Simmonds, editors, Behavioral Specifications of
Businesses and Systems, chapter 12. Kluwer, 1999.
[8] G. T. Leavens and K. K. Dhara. Concepts of
behavioral subtyping and a sketch of their extension
to component-based systems. In G. T. Leavens and
M. Sitaraman, editors, Foundations of
Component-Based Systems. Cambridge University
Press, Cambridge, United Kingdom, 2000.
[9] B. Meyer. Object-Oriented Software Construction.
Prentice Hall PTR, Upper Saddle River, New Jersy,
2nd edition, 1997.
[10] W. F. Ogden. The Proper Conceptualization of Data
Structures. The Ohio State University, Columbus, OH,
2000.
[11] J. Rushby. Subtypes for specifications. In Software
Engineering - ESEC/FSE ’97, pages 4–19. ACM
SIGSOFT, September 1997.
[12] M. Sitaraman, S. Atkinson, G. Kulczycki, B. W.
Weide, T. J. Long, P. Bucci, W. Heym, S. Pike, and
J. E. Hollingsworth. Reasoning about
software-component behavior. In Procs. Sixth Int.
Conf. on Software Reuse, pages 266–283.
Springer-Verlag, 2000.
[13] M. Sitaraman, W. F. Ogden, G. Kulczycki, J. Krone,
and A. Reddy. Performance specification of software
components. In Proceedings of SSR ’01, pages 3–10.
ACM/SIGSOFT, May 2001.
[14] M. Sitaraman and B. W. Weide. Component-based
software using RESOLVE. ACM Software Engineering
Notes, 19(4):21–67, 1994.
[15] J. Spivey. The Z Notation. Prentice Hall, New York,
1989.
87
A Formal Approach to Software Component Specification
Kung-Kiu Lau
Department of Computer Science
University of Manchester
Manchester M13 9PL
United Kingdom
[email protected]
Mario Ornaghi
Dip. di Scienze dell’Informazione
Universita’ degli studi di Milano
Via Comelico 39/41, 20135 Milano
Italy
[email protected]
Abstract
There is a general consensus that the paradigm shift to
component-based software development should be accompanied by a corresponding paradigm shift in the underlying
approach to specification and reasoning. Work in modular specification and verification has shown the way, and
following its lead, in this position paper, we outline our
approach to specifying and reasoning about components,
which uses a novel notion of correctness.
only point of access to the component. It should therefore
contain all the information that users need to know about
the component’s operations, i.e. what its code does, and its
context dependencies, i.e. how and where the component
can be deployed. The code, on the other hand, should be
completely inaccessible (and invisible), if a component is
to be used as a black box.
The specification of a component is therefore the specification of its interface, which must consist of a precise
definition of the component’s operations and context dependencies, and nothing else.
1 What is this paper about?
3
As the title suggests, this paper is about an approach to
formal specification of software components. The purpose
of such an approach is to allow formal reasoning about components. The ultimate goal of Component-based Software
Development (CBD) is third-party assembly. To achieve
this, it is necessary to be able to specify components in such
a way that we can reason about their construction and composition, and correctness thereof, a priori. Work in modular specification and verification, e.g. [9, 14] has shown
the way, and our approach follows its lead. However, our
approach is novel and hence different in the way we define
correctness. In this paper, we will discuss how we specify components, and in particular how we define and reason
about correctness, and why this is useful for CBD.
To reason about components and their construction and
composition, we will coin a phrase, a priori reasoning, which
is essential for CBD to achieve its goal of third-party assembly. As its name suggest, a priori reasoning takes places before the construction takes place, and should therefore provide an assembly guide for component composition.
For CBD, a priori reasoning would work as follows:
2 Specifying Components
Ideally components should be black boxes, in order that
users can (re)use them without knowing the details of their
innards. In other words, the interface of a component should
provide all the information that users need. Moreover, this
information should be the only information that they need.
Consequently, the interface of a component should be the
88
Reasoning about Components
it requires that it is possible to show a priori that the
individual components in question are correct (wrt
their own specifications);
(This enables us to do component certification, see
below.)
it then offers help with reasoning about the composition of these components:
– to guide their composition in order to meet the
specification of a larger system;
– to predict the precise nature of any composite,
so that the composite can in turn be used as a
unit for further composition.
(This enables us to do system prediction, see below.)
4 Predictable Component Assembly
4.2
A priori reasoning addresses an open problem in CBD,
viz. predictable component assembly. It does so because it
enables component certification and system prediction.
Consider Figure 1. Two components A and B each have
their own interface and code. If the composition of A and
For system prediction, obviously we need all constituent
components to be certified (a priori correct). Moreover, for
any pair of certified components A and B whose composition yields C:
A
B
Interface
Code
Component A
Interface
Code
Component B
+
System Prediction
before putting A and B together, we need to know
what C will be;
C
and furthermore, we need to be able to certify C.
?
?
This is illustrated by Figure 3. The specification of C must
Component C
Figure 1. Predicting component assembly.
A
Interface/Spec
Code
Certified
component A
B is C, can we determine or deduce the interface and code
of C from those of A and B? The answer lies in component
certification.
be predictable prior to composition. Moreover, we need to
know how to certify C properly, and thus how to use C in
subsequent composition. A priori correctness is just what
we need in order to do system prediction.
Certification should say what a component does (in terms
of its context dependencies) and should guarantee that it will
do precisely this (for all contexts where its dependencies are
satisfied). A certified component, i.e. its interface, should
therefore be specified properly, and its code should be verified against its specification. Therefore, when using a certified component, we need only follow its interface. In contrast, we cannot trust the interface of an uncertified component, since it may not be specified properly and in any case
we should not place any confidence in its code.
In the context of a priori reasoning, a certified component A is a priori correct. This means that:
5
=
Spec for C
A will always remain correct even if and when it becomes part of a composite.
C
C
Interface? A
Code?
Component C
Spec for A
+
A
Interface
Code
Verified module C
This is illustrated by Figure 2, where component A has been
+
Modular Specification and Verification
Current approaches to modular (formal) specification and
verification, e.g. [9, 14], use modular reasoning. This is
specification-based reasoning that tries to say before running the software whether it will behave as specified or not
(subject to relevant assumptions). This is illustrated in Figure 4. Before a composite module C is deployed, we can
A is guaranteed to be correct, i.e. to meet its own
specification;
B
Interface
Code
Component B
C
Interface/Spec
Code
Certified
component C
Figure 3. System prediction.
4.1 Component Certification
A
Interface/Spec
Code
Certified
component A
+
B
Interface/Spec
Code
Certified
component B
=
Interface
Code
Verified module A
Spec for B
B
+
Interface
Code
Verified Module B
Figure 4. Module composition.
predict whether it will work according to its specification.
For example, if component modules, say A and B, are to be
used in C, the correctness of C is established based on the
specifications of A and B (even before A and B have been
implemented). The components A and B are then verified
independently. The contexts of A and B are taken in account
when using and verifying A and B.
Thus modular reasoning is a priori in nature. It predicts
correctness, based on specification. This kind of prediction
is we believe subtly different from the prediction that we
Figure 2. Component certification.
certified, so we know how it will behave in the composite
C.
However, we do not know how B will behave in C, since
it is not certified. Consequently, we cannot expect to know
C’s interface and code from those of A and B, i.e. we cannot
predict the result of the assembly of A and B.
89
intend to convey in Figure 3, which predicts specification,
based on (certified) correctness (we will discuss this in Section 11).
is
open if its signature contains parameters. In this case,
’s axioms
have many potential
models, depending on
the parameters in the signature .
Example 7.1 A simple example
is first&
#%$'&(of
*),a+-closed
%$'context
.
contains the
order arithmetic "!
unary function . (successor)
and the binary functions /
),+
(sum) and 0 (product).
contains the usual Peano’s ax
ioms for . / 0 (and all the instances of the first-order induction schema).
6 Our Approach to Specifying Components
In the rest of this paper, we outline our approach to specifying components, so that we can carry out a priori reasoning about their construction and composition. Our approach
differs from current work in modular specification and verification, however, in that we use a novel notion of a priori
correctness.
Diagrammatically, our component looks like Figure 5,
and in the subsequent sections, we will explain the key inName
CONTEXT 1,23 ;
S IGNATURE :
Sorts:
)
;
;
;
CONTEXT(
Signature:
Axioms:
Constraints:
A XIOMS:
;
5
?
CEDGF
I ?KJ
IC J
I FJ
INTERFACE
Operations:
specifications;
op1(
),
op2(
),
;
Dependencies:
;
constraints;
CODE
Code for op1, op2,
4
Functions:
687:9;<4>=
687 4@9;A4B=
687 4 D 4@9H;A4B=
6LNMOD6PY 4QSR ?PT MU'VW5X= Y
LNM
6S4ZQ ?PT MU[V ?PT
6LNMOD6PY 4Q_M C C5`VaMb
=
LNM
6S4ZQPF M ?PT Y U'V
6LNMOD6PY 4Q_M 5dF VWY5X=
LNM
6S4ZQPM ?PT U[V
U\;]M^V Y =
?PT M CcY U*=
T M F\Y U C MQ
The standard structure of natural numbers is the intended
model of "! .
Figure 5. Ingredients of a component.
Example 7.2 A simple example of an open context is the
following, which axiomatises lists with generic elements
and a generic total ordering e on .
gredients, viz. the context and the interface, and their specifications.
We should point out that this is work in progress, so we
do not yet have all the answers, so to speak.
7 Context
I MPORT :
1"23
Tkj Dml 6N7 j D j 9nU*=
;
S IGNATURE :
Sorts :
j Dpo
Functions:
A component is defined in a problem domain, or a context. We will represent a context as a full first-order logical
theory with an intended (mathematical) model.
Relations:
7.1 Signature and Axioms
CONTEXT fbg'hi3
A XIOMS
v :
;
qHrst
v 6u7Kj 9N; Dpo
6u7
qxzyGy{6u7 j Dpo
|}x ? 687 j D 4
o =
9w; o =
9w;<4B=
Dpo 9~=
Iqrs D J 6KLNM DYwDp€ 6 j v D LX DpY ‚wv ‚ D sb6 o € v Q
T R„ƒwrsHVaM %… T
V sH; Y V € … ‚ VWskUU*=
D
J
j
T
IqxzyGy 6KLNM†D6 Y QPqD xzyGy M o qrskU‡VW5ˆ=
LNM
6 j Lwsb6 Q
Y
M^V DY ;AD qxzyGy T o M DY Q s‰U\VWqxKy*y T M D skU CaŠ =
LNM
6 j Lwsb6 Q
R‹M^V Y ;AqxKy*y T M DY Q skU\VaqxKy*y T M D s‰U*=
I|}x ?KJ 6KLNM†6 j DD LwD sb6 o Q Y
T |}x ?PT M 5 skU\Œ 6 j D Ž6 o QSsV Y v …"M^V Y U*=
LNM†6 j DD Lwsb6 D o Q
T |}x ?PT M ?ST rU s‰U\Œ< Y 6 j D Ž6 o Q
v
sV Y …d|Nx ?PT M D r D SUU*Q
is composed of a signature
A context
(containing sort symbols, function declarations
and
relation
declarations) and a finite or recursive set
of -axioms.
A context axiomatises a problem domain and thus enables
us to reason about it. More specifically, a context contains
the abstract data types (ADTs) and all the concepts that are
needed to build a model of the application at hand. A context is thus a (first-order) theory with an intended model.
We distinguish between
closed
and open (or parametric)
contexts. A context
is closed if its
signature does not contain any parameters. In this case, ’s axioms
have one fixed model. By contrast, a context
90
The context (ADT) >‘"’ is imported, together with its
signature “”'• and axioms –,— .
˜[™š and › are the constructors for the sort œ of lists of
elements of sort  . (For an element ž and a list Ÿ , ž„› Ÿ
stands for the list with head ž and tail Ÿ .) Their axioms are
the list constructor axioms (plus structural induction).
¡ˆ¢}£ ž\¤ ™ ¤ š¥ means that the element ž occurs at position ™
in the list š , where positions start from ¦ .
˜'¡S§:§ˆ£ ž\¤ š¥ is the number of occurrences of the element ž
in the list š .
8
Interface
The interface of a component is defined in the context of
the component. The interface is the only part of the component that is visible to the users, and it should provide all
the information that the users need in order to deploy the
component. Since the interface is defined within the context, the latter should be regarded as part of the former. As
we already made clear, the interface should contain specifications for the operations, and the context dependencies, of
the component.
7.2 Constraints
8.1
In an open context, some of the parameters in the signature may not be instantiated just anyhow. In fact their
instantiation must be subject to strictly defined constraints.
In the interface, operations are represented by their specifications. In a context דE¤Ø , a specification of a new (relation) symbol Ù is a set of axioms that define Ù in terms
of the symbols of the signature “ . For example, suppose in
¨„©iª%’ we have operations for sorting, such as insertion sort
and bubble sort. The specification for these two operations
are as follows:1
Example 7.3 In the context ¨‡©iª’ £ «¤z¬®­\¯ «¤±° ¥ , in order to ensure that ¬ is a total ordering, we have to add the
following constraints:
CONTEXT ²‹³[´¶µŽ·k¸O¹Gº¼»}½ ¸O¹p¸†¾n¿*À
Á,µ
I MPORT :
Operations
ÅwÚb»SÆÄNÛ_ÜKÝ}·~Úk¿‡Ê
ÅNއ»_Ԇ¹[ÅwÆb¹Ç^»_¸ßÄη·áàNâ_ãS·kƹ޹Úk¿HÉàNâ_ãP·kǹãP·kÞ¿*¹Úk¿¿'ÍAÆ,ºÌÇο
ňä_¹på@»SÆÄzæçÜzèB·éä_¹åο\ÊêÅwÆO»_¸ßÄXëwâzìGìP·kÆb¹käS¿‡ËíëwâzìGì_·kÆb¹påο
ňä_¹på@»SÆÄXî*âKÜ:ï·éä_¹påο\ÊÐæçÜKè>·éä_¹å}¿HÉBÛKÜKÝw·~åο
ňä_¹på¹Úb»PÆÄPâzÜKÝw·éäS¿HÉ^âzÜzÝw·~å}¿'Í
·ð,ç:Ü:ñXç_·éä_¹åw¹pÚk¿'ÊAâzÜKÝw·~ډ¿ÉdàwçÜKèB·éäNòGåw¹pÚk¿¿*Ä
;
S IGNATURE :
Sorts :
¸O¹Ã ;
Functions: ÄÄGÄ
Relations: ÄÄGÄ
A XIOMS:
ÄÄGÄ
C ONSTRAINTS: ÅwƹÇw¹pÈ-»P¸ÄN·kƎºBǏÉ@ǺBÆ¿'ÊAÆ^ËaÇwÀ
ÅwƹÇw¹pÈ-»P¸ÄN·kƎºBǏÉ@ǺÌÈS¿'ÍAÆ,ºÌÈÎÀ
ÅwƹÇw¹pÈ-»P¸ÄPƎºBÇ`Ï"ǺBÆbÄ
We represent operations as logic programs. For example,
the operations insertion sort and bubble sort are represented
by the following logic programs:
Operation: insertionSort ·ð,ç:Ü:ñXç¿
î*âKÜ:ïm·½z¾¹m½K¾n¿ôó
î*âzÜzïG·kÆbÄ äP¹Úk¿ôó
The purpose of constraints is to filter out illegal parameters of the context: only parameters that satisfy the constraints are allowed. For example, if in the context ¨‡©¶ª%’ £
c¤b¬Ð­¶¯ c¤*±° ¥ , we want to substitute  by the sort Ñ of
natural numbers, and the ordering ¬ by Ò on Ñ , then we
can express this as a closure (or instance):
CLOSURE Á"µH²‹³[´¶µ
Operation: bubbleSort ·º%¿
*î âKÜ:ïm·½z¾¹m½K¾n¿ôó
îGâzÜ:ïm·kÆbÄ ä_¹ÇwÄ Úk¿ôó
àNõˆÜzïG·½:¾~¹:½z¾¹m½K¾n¿ôó
à}õXÜ:ïm·½ Æ}¾~¹G½ Æξ¹m½K¾n¿ôó
àNõˆÜzïG·kÆbÄ ä_¹m½ Æ}¾~¹ÇwÄ Úk¿ôó
àNõˆÜzïG·kÆbÄ ä_¹m½ ÇS¾¹ÆbÄ Úk¿ôó
²b³'´iµŽ·k¸O¹mºÓ»N½ ¸O¹p¸†¾n¿*À
Ô ;
BY
º
ÅNÆb¹Ç"»PÔZÄN·kÆ,º>ǎÊ]ÆOÕ«Ç}¿ .
This closure of the context ¨‡©iª’ £ «¤z¬­%¯ c¤c° ¥ satisfy the constraints of the context since Ò is a total ordering
on Ñ .
In this example, we have closed  and ¬ within ¨„©iª%’
C LOSE :
¸
OF
î*âKÜ:ïm·éä_¹påο*¹ð"çÜ:ñXç_·½ Æ}¾~¹på¹Úk¿
BY
àNõˆÜ:ïm·kÆbÄ ä_¹m½ ÇS¾~¹påο*¹mîGâzÜ:ïm·~åw¹Úk¿
ƎºBÇw¹kàNõˆÜzïG·éä_¹m½ ÇS¾¹Úk¿
ÇdºÌƹkàNõˆÜzïG·éä_¹m½ ÇS¾¹Úk¿
The operation insertionSort computes the relation ö ¡ ÙP÷
(as specified by the specification given above) in terms of
the relation øúù_Ù_ûNù (also as specified above). It therefore
needs a program for øúù_Ù_ûNù in order to complete the sorting
operation. As a result insertionSort has øúùKÙ_ûwù as a parameter, hence we write insertionSort( øúù_Ù_ûNù ). In any context
that is a closure (instance) of ¨‡©iª%’ , insertionSort will need
a program for øOù_Ù_ûwù .
itself, for simplicity. In general, of course, they could also
be closed within another context Ö , after importing ¨„©iª%’
into Ö .
Obviously constraints define context dependencies.
1 For
91
lists ü and ý , üXþpý stands for their concatenation.
Thus parameters to operations also define context dependencies.
By contrast, the operation bubbleSort has only the parameter ¬ , which is the parameter of the context. So bubbleSort will work for any context in which ¬ is instantiated
(closed) by any total ordering.
Iterate
8.2 Context Dependencies
CODE
Code for iterate
These consist of the (global) parameters in the signature
of the component, the (local) parameters of the operations,
together with the constraints in the context.
So now we can define the context dependencies completely in a component.
Figure 6. The Iterate component.
CONTEXT INTERFACE
Operations:
Dependencies:
!#"# $&%' ( ) ;
iterate #,7.1032546/ ;
*+-,/.1032546 ;
CONTEXT 8:9<;
=?>&@BA5CAD7E ;
9 Code
IMPORT :
FHGI9
S IGNATURE :
Sorts:
@
Functions:
The code should be inaccessible (invisible) to the user.
It is usually binary. However, if we allow parameters in the
operations, then the code has to be source code, which has
to be instantiated before execution.
If the source code is available, then the user or the developer can also verify its correctness with respect to the
specifications in the context.
A XIOMS:
;
;
D
JLK/MONP@BQ
JLK @BAR@SMTNU@BQ
V JLK @BARWXMONU@BQ
YTZ[J\@^] V >_Z<A`\EabDcQ
YTZ[J\@BAYTdeJcWf] V >_ZgARhc>_d<E-Ea V >_Z<Ad<E
CiZ<]
C
where jlknm is the closed context for first-order Peano arithmetic defined in Example 7.1.
In the open context oqprsutvxw*yzw+{c| :
(i)
10 A New Notion of A Priori Correctness
v is a (generic) domain, with a binary operation
and a distinguished element { (see the first axiom);
y
(ii) the usual structure of natural numbers is imported;
In our work the basis for a priori reasoning is a new notion of a priori correctness. So having laid out the specification of a component, we now turn to our definition of
a priori correctness of a component. Specifically, we consider a notion of a priori correctness of the operations in a
component, that we call steadfastness.
(iii) the function symbol } represents the iteration operation }~t<wR€:|qf{‚y‚ƒ… y‚„7†„/‡ „+ˆy 
‰‹Š‚Œ Ž-‘&’
(see the second axiom).
We can use the Iterate component to iterate € times the
binary operation y on some (generic) domain v .
Suppose in Iterate, or more precisely its context oqprs ,
we specify the “”{\•1–”{ operation by the following relation:
10.1 Steadfastness
A steadfast operation (program) Op is one that is correct (wrt to its specification) in each intended model of the
context Ö of the component. Since the (reducts of the) intended models of its specialisations and instances are intended models of Ö , a steadfast program Op is correct, and
hence correctly reusable, in all specialisations and instances
of Ö .
A formalisation of steadfastness is given in [8], with both
a model-theoretic, hence declarative, characterisation and a
proof-theoretic treatment of steadfastness. Here we give a
simple example (based on an example in [8]) to illustrate
the intuition behind steadfastness.
—:˜š™›-œ+*™›Iž
“”{\•1”{Tt<wR€w+Ÿ|q ¡ŸX¢}~tgw5€:|
(1)
The predicate “”{/•1”{Tt&£¤wR€w+Ÿ| means that Ÿ is the result
of applying the iteration operation } to t<wR€:| , i.e. Ÿ¥
}~tgw5€:|qf{¦y‚§… y‚„/†*„7‡ „+ˆy  .
‰#Š¨Œ Ž-‘&’
This specification of “”{/•1”{ can be implemented by the
operation iterate( ©O€ª«”5wc¬*­ ) defined by the following logic
program:
iterate ®«¯–°
±_²5³´+µO¶
· ²-¸*¹7º²«¸\®_ºTOperation:
³
»
«
³
¼
¾
¶
½
–¯· °
±_²*®_¼¶
· ²«¸*¹/º1²-¸/®_ºO³-¿c®_°<¶5³«¼¶¾½
-² ¸*¹7º²«¸\®_ºT³-°³-À‚¶5³7´+µ<®_À~³-ºT³-¼¶
Example 10.1 Consider the following component:
£ ¤w ¤*ù ¥ is defined as fol’
where the open context ©ÿ
lows:
where Á is the successor function for natural numbers, and
the relations ©
€ª” and ¬*­ are specified in o¨prs by the
92
specifications:
= is the set of natural numbers;
à (i)
¤Ã1ÄŋÆÈÇ
ÂqÕ-Ö
Ç
ÉOÊË«Ì*Í&ÎÏ
Ð
×*ØÙÍ&Ú:Û5ÜÝÛ5ÞzÏßÐ
ÎÒÑÔÓ
ÞXÑÔÚ[àáÜ
(ii)
(2)
(iii)
OÉ ÊË«Ì*Í&ÎÏ
Î
The
means Þ is the distinguished element
Ó predicate
×*ØÙÍ&Ú¤ÛRÜÝÛ5ÞzÏ
, and
meansÚ that Ü is the result of applying the
à
operation just
once
. Therefore
in
ÉOÊË«ÌÍ&âTÏ to and
â
Ó
ÌÓ\ä1the
å–ÌÓTprogram
Íå<Û5æOÛ5âzÏ
for iterate, ifÍå<Û5æϨÑfâ[
, i.e.
is
just
,
then
ã
ÑèÓ
ÌÓ\ä1åÌÓTÍå<ÛRʐÛ5éÏ
ã Ñìé§àíå
computes
Otherwise,
if âë
,
éêÑ ç Íå<ÛRÊ:Ï
×*Øi.Í&én
Û+å<ÛRâTÏ
ç
i.e.
,
and
,
i.e.
,
then
ÌÓ/ä1åÌÓTÍå<Ûî–ÍÊ:Ï*Û5âzÏ
Íå<Ûî–ÍÊ:ÏRÏBÑ¢âbÑ¢é¥àåïÑ
ã Íå<Û5Ê:Ïà‚åBÑèӂà‚å computes
à‚ð7ð/ð+à ç å
ç
.
ñ òó ô
õ Äö¤÷gøù úû-üý
ÉOÊË«Ì5Ûc×*Ø
The operation
) is defined in terms of the
ÉOÊË«Ì iterate(
×Ø
parameters
and
.
If
we
can
assume that operations
É
ÊËÌ
×*Ø
(iv)
is
Ó
æ
;
is ;
ç
Íå<ÛRÊ:Ïq
>bå
Ñf
?fðæ (bå
7ð7ð [ÑÔÊå
Consequently, the specification
and similarly
(in (3)), and
(in (2)) specialises to
 ÕÖ
(in (3)). Since, the operations unit and op are correct with
respect to
ÉOÊtheir
Ë«Ì+Û\HG×*(specialised)
ØÏ
G specifications (3),Êå the operation
unit op) will compute , and is cor(iterate(
rect wrt its (specialised) specification in Iterate+Naturals.
To illustrate the correct reusability of the iterate operation in Iterate, suppose now we have a component Integers
Integers
;
CONTEXT IJ
unit, op;
INTERFACE
Operations:
CODE
Code for unit, op
CODE
Code for unit, op
operations unit and op are specified as follows:
ÉOÊË«ÌÍ&ÎÏ
É
ÊËÌÍÎÝÏ
×ØÙÍÚ:Û5Ü<Û+ÞÏ
Î
æ
(i.e.
means is , and
and defined as follows:
Ð
Ð
Figure 8. The Integers component.
Î f
Ñ æ
ÞXÑ ÚbÜ
×ØÙÍÚ:ÛRÜÝÛ+ÞÏ
means
ÞXÑÔ
íÜ Ú
as shown in Figure 8, where the operations unit and op are
specified by:
(3)
 Ã1ÄŋÆ
 Õ-Ö
)
Operation:- unit
!#"%$&('*)
Ç
Ç
ÉOÊË«ÌÍ&ÎÏ
Ð
×*ØiÍ&Ú:Û5ÜÝÛ5ÞzÏßÐ
Î f
Ñ æ
ÞXM
ÑÔ
uÜÚ
(4)
and defined by:
Operation:- unit
!"%$&('*)
Operation:- op
+-,.$#/.021!0234'65
# K2L ;
unit, op;
Figure 7. The Naturals component.
Ç
ÎÒÑfæ
(in (2)) to
CONTEXT Ç
(1) specialises to
×*ؤÍÚ:Û5Ü<Û+ÞÏq
bÜ
СÞXÑÔÚ
Naturals
Â:ÃÄŋÆ
 ÕÖ
.
ÌÓ\äcåÌÓTÍÚ:ÛRʐÛ+ÞÏqÐ¡Þ Ñ Êå
ã
Â:Ã1ÄŋÆ
ÉOÊË«ÌÍ&ÎÏqÐ
for
and
are a priori correct, i.e. they are correct wrt
their specifications (2) in any interpretation
, then
É
ÊËof
ÌÛc×*þ¨
Øÿ
we can prove that the operation iterate(
) is steadfast, i.e. it is always correct wrt (1) (and (2)).
For example, suppose we have a component Naturals as
shown in Figure 7, in which the context is nÿ , and the
INTERFACE
Operations:
ÂA#ÆC@ BED%F CÆ B
3879/;:<1
Operation:- op
+*,.$#/.0E1N0234'65
Then in Naturals, unit and op are (trivially) a priori correct wrt to their specifications (3), and if we compose the
components Iterate and Naturals, the operation iterate in
the composite Iterate+Naturals will be fully instantiated
(and therefore executable), and more importantly it will be
correct wrt its specification (1) (and (2)).
The composition here is of course just the simple closure
operation on Iterate, but it is sufficient to illustrate the idea
of steadfastness. In this closure of Iterate:
3879/?OP1
Obviously the operations unit and op in Integers are a
priori correct wrt their specifications (4). We can compose Iterate and Integers by a closure operation on Iterate, and get a correct iterate operation in the composite Iterate+Integers.
In Iterate+Integers:
(i)
93
= is the set of integers;
(ii)
(iii)
(iv)
à
Ó
is
M
—¤˜#™›-œ™›
;
ç
is 0;
Íå<ÛRÊ:ϐQMÑèæ
and the specification
Â:ÃÄÅ3Æ
å ^ðM M/ð7ð
R
Â#ÆC@ BED%F CÆ B
,
((1) in Iterate) specialises to
ÌÓ\ä1åÌÓTÍ&Ú:Û5ʐÛ5TM
ÞzÊÏqÐL
å ÞXÑ
ã
(in (2)) specialises to
ÉOÊË«ÌÍ&ÎÏqÐ
(in (4)), and
åBSM
ÊÑ å
The operation iterate* has the same specification
(1) as iterate in Iterate, but it computes the relation “”{/•1”{
more efficiently than iterate: the number of recursive calls is
linear in iterate, whereas it is logarithmic in iterate*. However, iterate* would not be steadfast in Iterate. For example, if we were to use iterate* in place of iterate in Iterate, then iterate* would be correct wrt (1) and (2) in Iterate+Naturals, but it would not be correct wrt (1) and (2) in
Iterate+Integers, where, for instance, for
ÕÖ
Î Ñèæ
“”{\•1”{Tt<w+ÁtÁCt–Á–|5t|RÁ|5t H‚|*Tw |
(in (2)) to
×ØÙÍÚ:ÛRÜÝÛ+ÞÏq
JMÐLÞXÑfÚ
Ü
iterate* would compute  instead of the correct answer ƒ„  .
Thus despite the a priori correctness of unit and op in both
Naturals and Integers, iterate* would not be correct in
both Iterate+Naturals and Interate+Integers. Therefore
iterate* would not be steadfast in Iterate.
The reason for this is that in Iterate*, the constraints (5)
require that the parameters { and y of the context satisfy the
unit and associativity axioms. These imply that
(in (4)). Since unit and op are Ícorrect
É
ÊËÌÛc*G×*wrt
Ø<Ï theirG specifications (4),
the
operation
(iterate
unit op) comMÊå
å
putes
for an integer , and is correct wrt its (specialised)
specification in Iterate+Integers.
The iterate operation is thus a priori correct in Iterate
and we say it is steadfast. It can be correctly reused in any
composite with operations for unit and op as long as these
operations are in turn steadfast.
…‡†
¶
† _® ºT³-°g6
®_ºT³-°g6
¶
Example 10.2 Consider the component Iterate* (Figure 9)
obtained from Iterate (Figure 6) by adding the following
Iterate*
CONTEXT UWVXY>Z[\]^\_E`
Dependencies:
†
Š
† _® ºO³«?ˆ° \¶W‹Ùº
®_ºO³«?ˆ° \¶Š
ŽL:RŽ° ‘’”“k“
ŽL:RŽ° ‘•%–(•-—
which means that whenever y is associative, } can be computed in logarithmic time. So, if we were to use iterate*
in place of iterate in Iterate, then iterate* would be correct
in Iterate+Naturals because here ( v is the set of natural
numbers) { is  , y is ˜ , and so they actually satisfy the constraints (5) anyway, even though these constraints are not
present in Iterate. On the other hand, iterate* would not
be correct in Iterate+Integers because here ( v is the set of
integers) { is 0, y is ƒ , and since ƒ is not associative, they
do not satisfy (5).
However, we can prove that iterate* is steadfast in Iterate*, again assuming a priori correctness of operations for
unit and op defined in some other component. It will be correct in any composite Iterate*+C as long as C satisfies the
constraints (5) in the context dependencies of Iterate*. For
example, as can be seen from the above discussion, iterate*
will be correct in Iterate*+Naturals since ˜ is associative.
For something completely different, suppose Matrices is
a component with a context of ™ -dimensional square matrices. Then in the composite Iterate*+Matrices, v is the set
of ™ -dimensional square matrices, { is the ™ -dimensional
identity matrix, and since matrix multiplication } is associative, iterate* will be correct, where op computes matrix
products.
The component Iterate has no constraints in its context dependencies. To further illustrate the notion of steadfastness,
we now consider a component whose context dependencies
include constraints.
INTERFACE
Operations:
†
~Š
† _® ºO³°‰ˆ\¶Œ‹
®_ºO³°‰ˆ\¶Œ‹
~Š
ab c deKfKc d \ ag#hi c \ akjLl ;
iterate* ZKmon(prq\*stu` ;
[\]^\_-\Emon(prq\*st ;
constraints;
CODE
Code for iterate*
Figure 9. The Iterate component.
constraints to its context dependencies:
v ž
{¦w ž yá£Ò £
v £ vx
(5)
£:*yw<w+Ÿ vx
£Bw Cyí
ySty‚Ÿz|qzyO|ƒty‚£[Ÿ y
(these constraints stipulate that y should be associative) and
by replacing the iterate operation in Iterate by the following
operation iterate*:
iterate* ®«¯°O±_²³´+µz¶
· ²«¸*¹/º1²-¸/®_ºO³-»³-¼Operation:
¶
½
¯
O
°
±_²*®_¼¶
· ²-¸*¹7º1²-¸\®_ºT³-°³-¼¶ ½
{}|~{T °³ · ²-¸*¹7º1²-¸\®_E{ºTe³ ³-À¦¶5³
´+µÝ®_À~³-ÀI³«¼¶
· ²-¸*¹7º1²-¸\®_ºT³-°³-¼¶ ½
{}
u¿#{| c?® ¶
°³ · ²-¸*¹7º²«¸\®_E{ºT³ ³À¦¶5³
´+µÝ®_À~E€³-1ÀI¶5³´+€µg–® ³-ºT³-¼¶
11 Discussion
Since a steadfast program is correct, and hence correctly
reusable, in all specialisations and instances of its context,
a component with steadfast operations, which we will call
94
a steadfast component, when composed with another steadfast component will also be steadfast. In other words, steadfastness is not only compositional, but is also preserved
through inheritance hierarchies.
Consequently, in the context of system prediction (as
shown in Figure 3) when composing steadfast components,
not only can we be sure that the composite will be steadfast,
but we can also predict the specification of the composite.
This is illustrated in Figure 10.
A
Interface/Spec
Code
Steadfast
component A
+
B
Interface/Spec
Code
Steadfast
component B
OMT [11] or UML [12]. It may yet be an OOD framework,
i.e. a group of interacting objects [6], such as frameworks
in the CBD methodology Catalysis [3, 5]. It could even be
a design pattern or schema [4].
We believe that our approach to component specification
can enable predictable component assembly, which is currently an open problem in CBD. In addition, we believe it
can provide a hybrid, spiral approach to CBD [7] that is
both top-down and bottom-up for CBD, as illustrated in Figure 12. First a library of steadfast components has to be
C
Interface/Spec
Code
Steadfast
component C
Requirements Spec
Architectural Spec
Top−down
design
Library of steadfast components
synthesis
Figure 10. Composing steadfast components.
Correct software
In the context of modular specification and verification
(as shown in Figure 4), steadfast modules can be verified
and the specification of the composite can be predicted, prior
to composition. This is illustrated in Figure 11. We under-
analysis &
transformation
yes
Correct software ? no
Spec
synthesis
Library of steadfast components
Spec for C
C
Spec for A
+
Spec for B
Figure 12. A spiral model for CBD.
B
Interface
Interface
Code
Code
Steadfast module A Steadfast module B
A
Interface
Code
Steadfast module C
Bottom−up
built. The nature of steadfastness, coupled with the use of a
priori reasoning, then allows these components to be composed into larger systems in either a top-down (following
the traditional waterfall model or the software architecture
approach [13, 1]), or bottom-up manner, or indeed a combination of both.
Bottom-up development in particular is more in keeping with the spirit of CBD. Composition of steadfast components can show the specification of the composite, and
therefore the specification of any software constructed can
be compared with the initial specification for the whole system. Guidance as to which components to ‘pick and mix’
can also be provided by component specifications.
+
Figure 11. Composing steadfast modules.
stand that current approaches to modular reasoning need to
know the specification of the composite before predicting
if the composite will work according to its specification. If
this is the case (as shown in Figure 4), then steadfastness
offers the advantage of being able to predict the specification of the composite prior to composition. Thus, with
steadfast modules, we can do system prediction as shown in
Figure 10.
Acknowledgements
12. Conclusion
We are grateful to Murali Sitaraman and the reviewers
for their helpful comments in general, and for correcting our
misunderstanding of modular specification and verification
in particular.
For lack of space, we have presented the intuition behind steadfastness by means of simple examples. We hope
this does not detract from its presentation.A full account of
steadfastness can be found in [8]. Steadfastness is defined
in terms of model-theoretic semantics. It is thus declarative
in nature. We believe that declarative semantics in general
will be important for lifting the level of abstraction.
Our approach to specifying components is very generic.
The component may be just a class or ADT. It may be a
module, in particular what Meyer [10] calls an abstracted
module, which is the basic unit of reuse in the CBD methodology RESOLVE [14]. It may be an object model [2] as in
References
[1] L. Bass, P. Clements, and R. Kazman. Software Architecture
in Practice. Addison-Wesley, 1998.
[2] R. Bourdeau and B. H. Cheng. A formal semantics for object
model diagrams. IEEE Trans. Soft. Eng., 21(10):799–821,
1995.
95
[3] D. D’Souza and A. Wills. Objects, Components, and Frameworks with UML: The Catalysis Approach. Addison-Wesley,
1999.
[4] P. Flener, K.-K. Lau, M. Ornaghi, and J. Richardson. An abstract formalisation of correct schemas for program synthesis. Journal of Symbolic Computation, 30(1):93–127, July
2000.
[5] J. Küster Filipe, K.-K. Lau, M. Ornaghi, K. Taguchi,
A. Wills, and H. Yatsu. Formal specification of Catalysis
frameworks. In J. Dong, J. He, and M. Purvis, editors, Proc.
7th Asia-Pacific Software Engineering Conference, pages
180–187. IEEE Computer Society Press, 2000.
[6] J. Küster Filipe, K.-K. Lau, M. Ornaghi, and H. Yatsu. On
dynamic aspects of OOD frameworks in component-based
software development in computational logic. In A. Bossi,
editor, Proc. LOPSTR 99, Lecture Notes in Computer Science, volume 1817, pages 43–62. Springer-Verlag, 2000.
[7] K.-K. Lau. Component certification and system prediction:
Is there a role for formality? In I. Crnkovic, H. Schmidt,
J. Stafford, and K. Wallnau, editors, Proceedings of the
Fourth ICSE Workshop on Component-based Software Engineering, pages 80–83. IEEE Computer Society Press, 2001.
[8] K.-K. Lau, M. Ornaghi, and S.-Å. Tärnlund. Steadfast logic
programs. J. Logic Programming, 38(3):259–294, March
1999.
[9] G. Leavens. Modular specification and verification of
object-oriented programs. IEEE Software, pages 72–80, July
1991.
[10] B. Meyer. Object-oriented Software Construction. PrenticeHall, second edition, 1997.
[11] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and
W. Sorenson. Object-Oriented Modeling and Design.
Prentice-Hall, 1991.
[12] J. Rumbaugh, I. Jacobson, and G. Booch. The Unified Modeling Language Reference Manual. Addison-Wesley, 1999.
[13] M. Shaw and D. Garlan. Software Architecture: Perspectives
on an Emerging Discipline. Prentice Hall, 1996.
[14] M. Sitaraman and B. Weide, editors. Component-based software using RESOLVE. Special feature, ACM Sigsoft Software Engineering Notes 19(4): 21-65, October 1994.
96
A Pi-Calculus based Framework for the Composition and
Replacement of Components
Claus Pahl
Dublin City University, School of Computer Applications
Dublin 9, Ireland
[email protected]
'C/5YQ>+$;--5]/!.#X#1
!#/+(C_*5Y{%^#A!
>1+!>b
!216G7
~1#!G(1#AI#;1;
!**$;_;91#
!|1>!0#A)#=;-!1#$K*:5Y!b‚#1.e ŠAi/!?e ‹/ijK
21
bb/5~(*T=#/!b(1#A_#;1;
!**$;Z(1T!21Œ5Y!
#.!0#>.#/_/! 1/b5Y1"Q!>!1 /5N9% 6P_;
9*
#Q*$1_#!#/+(SS(1:;"!JK&A!>Z(1*
;+|=KI2)5]!:1#/>#Z5]/!.#N5B!0#%I!k/5b0(=#/1>
#1;[!|1>
!0#/Z5Y!C1'*"V6
7
@g?*!0#/C*J6lŽ3<79
h:%I9*!9;
1b*21#*'5G!C*"Z#/=;.!1#F
^$#/116N7
-†:5]**b-9*!0#/*FW2=#/*$;-.#/0(F
1>S#/=;…1/![0#2*($6DmN(1Z{}
[
F
*!9;$;…7
…Š96794‹Z*|1:(."5Y}
[5
19_*"JKN%'"(?k9>S#/!1#6
C1#?#/=;4(1$%ƒ<!$#*O#2?("!LM+??(1
*129c_/5C7
…‘96-’H=#/"KH%I.;**,!#A$;%N/!k#/=;
1;[%'"(Z* 1*16
Abstract
!"$#&%'"()!*+,
(-.#/0#/1#2"34/5(1*-
6879
:-;
<0(=#/1>?4(.9
"!1,!?;1@!A /5
1;9B;
=#/C6D4(1>(E1?0(1"F
>:#G#AH!$;
11>'(1I;=;1J23%I,1K
*#A!*:!1#G5H>(#/LM(1N?F
*"O56EP-*!9;1Q#)*"R#/=;S!F
#9$#T2=#*;@)(1:UVFW$#/11KX#$%'1>Q1
*"5Y@*"#/=;Z[!#*#2!#9#=;
("!CLM6
1. Introduction
\ 5]/!.#M*.#/9N5Y!'^#1;[^/F
*"4_**B#/N"5'!>!1#/=#"
*?#/=;!$#/*1>@(
;
1,#1;).#/1#5^T
T*(=#
2@;
1$$;M6a`b![29c+Q#/!@#5]/!.##/d5,21#*
*"
!11K9*#/!&?e"fKgK9h/ijK9#/=;:(^!A9*
/5&#_5Y!0#/%N/!k[5Y!l+(1#1>T#1;-
Q#/=#"
*6'mN(1 /F
#/?b1*N(1^UMFW$#1&&#*B#A!"3:23%I_(
5lnopqsr qYtsuT<(1:UVFW$#/11#=;Ev+w/or x9tsqjoy-)?F
1:+(1>6Ez-21{4;|11$;4#/_(1}$#1#"3S
0(=#/1>C(C19"3?/5J#1{%N!kKs6 6 0(=#/1>'(1'*1#/F
#/~|1>!0#AJ6_)#A!>? 
#/*Z#2l(1T+(1#>,5~11b2+3%N<16
mN(!5Y!KM(1 UMFW$#1C*'[2T#*0#/21T5]!.#/XF
0#AQ.;Q#_5B!0#%I!k}5Y!b*"|=$#A@#1;}!$#*F
>_#/2N1~*Z#1;VK9.=#A!*1#/!$K
F
)Q(1*,
6 \ l%I:%'G*_#A! VK%N,%'G
!F
*l*l0(=#/1>'T21#*lUMFW$#1I*.#I#/=;;
#<3
[€!11>@1:+(1>4
!16
mN([!*1"__#Z‚
$;)$#K2=#/*$;SSUMF{#1:21#*
#/=;.
I5Y!ƒ1~+(1>6&mN(l3
l
#$
T(1?!./5C(9>!0#//!$6<m&
T>/!S(1$%„=#/
#82}1*$;…E
!*.$#,e †/iW6OmN(1…#/**5B81#/*!
/5G2(1#A9
!$K#=;(1+.$#}#*_!1'19{[#1;.(
*!J21"3}#1;}V6
P)**B#/d;
|=#4*"d!%'"(‡;
"5YF
5Y![1(1#*ˆ<.#A+(>#/=;E1/!}0#21*(19$KIF
$#/#=;@‚
/5N(1?*+!
KG#)
$#/)!1"K
#/=;MKX#/+!TJKX;
1#,!1#6?mN(?;"LM!91(=#/*
%' 2@;*+!2;O298;"LM!9.*!0#/1*"R!16‰P<#/!>
(1#/N#T
!*FW!$;k.#AN~*"[I/5
.#$c/!T!*0#T5]! (:!#2"{#/=;Q.#0#1#21"3</5
91>_
6GPb%'J1~(1^!*C9%d
*"[%'"(O+(19;?)!$#*D#2
.!1#
/5I'<0(=#/1>>9
"!16CmN(1T</5
2. Components and Composition
`b!l19l9;X2=#/*$;QQ/!**F{21#*$;QK
%'(1+!_!*!!*b*!9KJ%'"()‚
!* #/=;<!*
F
!*5]#:5]!:!A9;$;S#/=;)!9$;*!96@mI%I</F
19l!*5s#/ #A!:
!*$;Z2$%“FC”$•–—˜™š›—}!$1>
*!9,#1;<œ9›ž—˜Ÿ—˜<!A9;1>}*!9FC2(@=#/!*T/5^#
;1^.#/11B#AQ#/=;}/!0#>,
Z6
,¡M¢@£&¡=¤X¥
¤V¦ ”$•–—˜™š›—
q]nl§
o¨0tI©v+¨+w$qsª+v+©
« —˜Ÿ¬—­œ
›V®{¯˜
°X±s²¬”9³V±jœ
›
« —˜Ÿ´9µœ
›V®3µ9›X±jœ
›J¶{¯·µ±{¸¹–1³
v*º+§
o¨0tN©v+¨0w$qjª0v+©
/·9—•œ9›J®{¯˜9°X±j²¬”³
« šŸ—œ9›J®{¯˜9°X±j²¬”V¶<¯·µ±{¸¹–³
mN(1.!*5s#/?*,*!9:5B!»(1.*!!:19T
!$1T¼s#;1½C#/=;}9;
"5Y@¼s!A½^;
16
,¡M¢@£&¡=¤X¥
¤V¦ œ9›ž—˜Ÿ—˜
q]nl§
o¨0tI©v+¨+w$qsª+v+©
v*º+§
¾o¾¨0¾ tN©v+¨0w$qjª0v+©
˜—­œ
›J®{¯˜
°J±j²¬”9³M±Wœ
›
¿ µœ
›J®3µ9›J±Wœ
›J¶W¯·µ±{¸¹–1³
À'#/!T;"|=;-2-ÁllŽ{IÂ[11"5Y!Ã!*
!T;
F
"|=!6~mN(l!$1'*!9˜—­œ9›,!!^#_;
19$K21
;^1N+(1#1>l(b0#/b5X(b*!!^19$K%'(1!$#/
(1l9;"|=#/[*!9 ¿ µœ
›,M;1#/^#:;
19I.(1
*!9!C*;%'"(1'!
!11>#:#/6
f
97
#/! !#$;Z2[!A$;[!C9;"|1$;-!*16'z-+(19;^
#%N!C%'(1+(1!C5]/!b‚#/1b(1 *!l!*5]#T/!l(T;
F
^*!!C$#Z2l!1#$;-*(=#/X2 *!9;1$;V6
79!9Q!*[#/!<.5,#/*};*!2$;OO/F
?!*5s#/6P-#/**1.(1*[!*,)2[*"|1$;S
*Tk
1;-5&>T(=#A#/$%'b+‚
!*C!FI#1;ZF
;
"1l#b#21*!0#/l5]/!b/!*:e ‘KMÄ/ijK1#2>?(1,;*>F
29FW*!0#/'#!#0()e Ä
K1Å/ij6&Æb#/!> !'9;#>l#A!
*"0#215Y!0#/%N/!k9}e"f$Ç9K^ff+iW6 \ !$1"! *|1$#/
/5G(1*+!
*! « —˜Ÿ´
µœ
›1;-k[kˆ
« —˜Ÿ´
µœ9›ƒ® ¿È œ9›X±Wœ
›J¶ ¿È ²·µG±{¸¹–“³
§=¨vɟšÊ°/µG®0³
§
o©ta¯·µ9š–—µG®+³
Àb1N*(1#V2bË zZÌMF{;N(1!K
%'(+(}$#}2
%I"FW5Y!$;4¼s/!*!0#/>}1>½'!b#/;4¼]%N"Fj5]/!$;<#=;
5Y!Í8#8;1-{
;+|=1"dÀ mNÀT½+6 \ *!9
!A
;
!C*"|=$#AZ1;-k}kˆ
¿ µœ
›Î®}µ›X±Wœ
›J¶-¯·µ±W¸¹–“³
§=¨vÐϗÊÊÑ9/˜ ¿ —µG®0³
§
o©ta¯·µ9š–—µG®+³EÒڛ$ӕ
/Ï
ʗµÔ—µG®0³
\ *!0##42[5Y!$;S2{%NE!*5s#/Z#/=;4;F
9.*+!!$6‡mN(1<*!9 ¿ µœ
›/5 (1<;
1.*!!
.#A+(.(1Q!$1"!.5 « —˜Ÿ´
µœ9›SF?#4*+!
<(=#A
>(9J2$#$; (19;
M!A9B;
$;b2C(19+!*5s#6 ¿ µœ
›
(1#l#:%N#k!$K*'!*!$;Z!1;"-F&Ÿ9šÊ°/µG®+³:1
ϗÊÊÑ9/˜ ¿ —µG®0³,FG#=;.#T*!>!'1;".FG(1C/c1F
<¯·µ9š–—µG®+³&Қ›Ó•
/Ï
ʗµÔ—µH®+³.1C¯·µ9š–—µG®+³6bmN(1
#1'(=#Al(T!A9B;
$;Z*!9,#/|=$;Z(T!9"!Õ
"C'}2*!'(=#/}!$1$;V6
P@%' 1><#…;+0#;d
!*0#/D/5_
*.#:(,!*0#/VÕI!,5]__(1@ªonb§
oÖ
©q]tsqsoyE©v+n?×y1tsqjª©6@mN(*…/5'1.e"fAgKCfh/i
%'V2 ;|11$;.1*>:(1lUVFW$#/11 e"f†KVfAŠ9KVf$‹Aij6IŽ{9+!0#
,(1.*"4!16@ØH!*:!!*:*!9_/5l#
$6GPb%'J;1>*(Q;"LM!^!C/5!*K6 >6
%'((1+!,#}*!9 !A9;$;<! !$$;V6?mN(1?*.#
/5&*!9:‚
Q'!=+$;ZZ(1 3
Ã(!1>(
!F,#1;…1;"6OmN(}3
}Ù?(1[kS2F
{%N[(lN#/=;?(1C*"}*.#6Æb$%^F
!$K(1[!F#1;41;"K~5Y!1>@#<*!0#+$KI#A!
#/*/!*0#N5Y!'(1l*Z!*6 \ 5]/!.#
=;
"-‚
!**N(=#A^3%I:/!*^.#/0(}21#*$;.[%'(1(!
#:!A9B;
$;.*!9 #/|='(1l1;'5#T!$1;}*!96
mJ+(1$#/"K(^.#/0(11>b!*&&5]#"0#/$;?(
!1>(?F
*!0#/T!* « —˜Ÿ´
µœ
›Úd#=; ¿ µœ9›Ú'6?mN(1?*!T!*5s#/
!9"!H#^*!9C¼j#10#A,Û ÜÝJ½V#/=;b(~;
19V*!!
!A
;
C#_*!9¼j#10#A<ÞNßàX½+6
3. Calculus - Syntax and Type Basics
mN(1T**(=#/~*!9;?2=#/*T5N!T$#/11KH*10(#/
0#/‚/5X(1l1/0#/-#=;*l3
l**K
25]/!b%Nbk
#/'!'5Y!l1^*"V6
3.1 Syntax of Component Composition
mN(1_2=#*? ;*!211>-#9"3<@(_UMFW$# #/!
#+16 \ T#/!::211$;Q[!*T‚
!**16 \ +F
l#A! ‚
!**;Z#'!+|1‚
N_(* !*l‚
!**1ˆ
U)ˆˆ ä ÞIñòXó
Ü ôXåsõçöÞIñ1òJóÜZôX¼sõ1½lö
÷
\ +1'$#/-2 ;
9;;}_
1
'#1 ôXåsõç~F(1b1#
õ@,*:#><+(1#1C¼s!:!*+½ôFKH1,ôH¼sõ½lFbõ@,!+F
;E#/1>)ôXK~#=;…#<*
F{21*!#2Z#+8÷V6P
(=#$.#/10#/;(1*[#+4!|‚,2)!*,3
KG%'(0(
%'‚
1#(1^!l5M(1C!*~%'(!*IT"5]b+l#+F
9~*10([#I*+!
'!$1I/!N*!9C9#/V6~Æl!'
(1^5Y11N/5X#/
!|1‚
K("!I/!*~{
&#=;?#/!"
¼]3
'#/=;[#/!"l%'X2 +‚#1$;[*=½+ˆ
ú
C$1
Uøˆˆ ä Û Ü
Ý ùQÚNåsù-æAç
ÞNßàSûXÚ^¼sûVæA½
ü
ØG!/9;
æ
ï
ù
s
å
ý
ì
ý
W
þ
*
ì
Q
ù
G
ÿ
ç
ú
3
Ž
9k
é*ê=ë
¾¾¾
G‚
íIî ÜZûVæ¼sôXïì ¾$¾¾ ìôìû ÿ ½ ü
Û Ü
ó ûJÿIå $ç
ú
C1"
Û Ü ù ÿ ¼sõ½
ü
C*1"
mN(1T
0#/‚}5*"Q‚
!**1C991>?(1T#/
!+|1‚
^^(15]$%'1>
ˆ
ˆˆ ä ù C*!
ï ö ð
ØG#A!0#H*"
ŽW!0#/
æVU ¾ 791.#/
Ç
Ž{=#+
C*!@$#l(=#Aù Z
*21:_6,791.#/
U ^$#l(1#/1:U N+(*)#1;<(:
!**!0#/5]+!
,¾ 0#/ 6ŽW!0#/ ‡$#/1I(1#/I(b
!*^N‚
$;
#<#A!21"*!0#Q91:2!'56CmN(1C5]$%'(1T!*0#/
5T(@UMFW$#1[‰e"f$ŠAij6 P@#*41;R#21*!0#/Kbs6 6
;+|=1>,91#/I/5J(C5Y!
,¼sý½ ä I6G&.(>((1
"9#;UMFW$#^C1;$;_2l1*$;MK
%I 5B-*b(1
1#;
,#/!#(!,@!0;
!b[k<(:0#A)*6
mN(1 *21"
Yý YØO#1N(1#/
l!1#lý.
_6
”A•–—˜™9š›—Eáä â]ã Û Ü
Ý « —˜Ÿ´
µœ9›Ú'å « —˜Ÿ´
µœ
›æAç ¾ ”A•–—˜™9š›—è
œ
›ž—˜Ÿ—˜ áä â]ã ÞNßà ¿ µœ
›Ú'¼ ¿ /µœ
›æ/½ ¾ œ
›ž—˜Ÿ—˜9è
mN(=#/N#A!1/I!#N5Y!'~,.#/0(.F1"
(:
!F^#/=;Q=;
"1b!!*$;Z(
!1>(Z3
b#/!6
791*5].#/0(11>^!*X (~0#/21*(1X51#C1F
/!'F&#_!#/b0(=#/1M23%I}(19~(=#/C#/$%'
1 ^?1**+!
l
!/9;;}2(1 /(1!$6
”A•–—˜™9š›— è€á*ä â]ã é*ê=ë « —˜Ÿ´
µœ9› æ åsµ›9ì*¯·µç ¾ ”$•–—˜™š›— è è
œ
›ž—˜Ÿ—˜ è á*ä â]ã íIî Ü ¿ µœ9›æås¹1ï$ì*¹9ð$ç ¾ œ
›ž—˜Ÿ—˜ è è
mN( 1*!'!*5]# $#/Z9kC(1*+!
¼ é*ê=ë ½&(
!1>(}(
!0#/<!* « —˜Ÿ´
µœ9›æ
K%'(10(Z%'X*!>>!C(1T‚
F
…¼ íIî ܽC/5 ¿ µœ
› æ 29}(1T*!+!$6mN(:*"VKJs6 6
0#21*(19&/5M#b11!$K^5=(^k,#/
"Õ(
/(1!&G!1#/$6&7H^/!GK
3.2 Ports and their Types
mN(1^9"?
!&*?
#/!^#1K!*&#/=;
196 ~#[#/!Q0(=#/!0#/!*$;O24(1Q*=#C#1
;.#1[#/[{6“mN(@}5T2=#/*<{
"! ï ì#! ð ì ¾¾¾ *(1#
2[#**$;VK2:1:‚
1""*|1$;V%
6 $I19:#/!
0#$#/"<0(=#A!0#!*$;<2Q#/@!*5]#,%'(<*!9:*>/F
=#A!K*1#/!0#/;-9_/!*C#1;}‚
!*C96
mN(1,b!*0#bb#/!,(1,!*6T&#0()/!*&
_**9#/"…#Z5s#/5l!*'
& ä (¼ & Ú ì & æ ì &MÿG½+6mN(1.|1!
!*) &MÚQ~(1Tªoyts¨*תtM§
o¨0tsK9**#".#/#2*!0#I!*5]#
;*!2$;S29#Q*>=#A!K~#Q!=;
"…#=;S#Q1;"F
V
6 &=æ-?(1-1/!.##/ ¼s!.!0#+½:/!*$6
mN(1 /!*T *$;Q-9k:#}*+!
6?mN(?!**
&Mÿ…$#/!*!$;
g
98
ùQÚ
ûXÚ
ù æ
ûJæ
ù ÿ
Q
û ÿ
mN(1 $#/1b(1#/(*_0(=#/1 #/!?1"@#$#/B#/21_.(1*
3%I?196
ˆ,+CñßH¼.-0/21¼43Gï$ì ¾¾¾ ì#365ì0ú7+lÛ Ü¼43b½*½+ì
ÞNß 8&¼jó
ßÜ
½+ì0ÞNß8&¼jó
à6ñM½*½
ˆ,+CñßH.¼ -0/214¼ 3Cï è ì ¾¾¾ #ì 3C5 è 9ì +lÛ ÜM4¼ 3CèY½*½+ì
ÞNß8&¼jó
ßÜ): ½+ì0ÞNß8¼jóà6ñ;:"½*½
ˆ,+'<'=X4¼ 3 ï ì ¾¾$¾ >ì 3 5 9ì +CÛ ÜM4¼ 3b½*½
ˆ,+'<'=X4¼ 3Gïì ¾¾$¾ >ì 365M9ì +CÛ ÜM4¼ 3b½*½
ˆ,+lÛ ÜV¼43b½
ˆ,+lÛ ÜV4¼ 3b½
3.3 Subtypes
Ž3<
!1K(_;
|=@/5N#*23
!#/b**2
5]/!#/^k9=;
:/5C:…!:1/0#/V6ÆlA%I!$KG%I[%'
5]1?…/!*_(!6SmN(}*2{?!B#AE%'^(14,
;+!1_%'((1! {%NZ/!*KX!
!*1>Z*+!
KG.#/0(
#1;E%'(1+(1![(1E$#/R2Q*$;V6“ÌX#/+!-JK'(1[
F
:%''#*@2.1*$;<;
!1.1*-¼s+LM*Fj5Y!$½
!B#/6
P(=#$S#/!#;
‡*‡(1#/Q(+(1#1T3
Q/5.
F
*!0#+!*_#/!-*!0#_*>)/5#<*!9}*>=#/
!K
#E
!=;"‡#1; #…=;"V6 ’!@#…!9"!$;d*+!*F
9bùZÚSˆ `+Cñ=ßHb¼ p/21od óß6Ü d ó
)à +ñ½I#/=;.#,
!A
;
$;*!9bûJÚ4ˆ `
+CñßHb¼ c/21e:2d óß6
Ü :4d ó
6à ;ñ : ½+K
%N #.(=#ACû Ú .#/0(1^ù Ú 5
p/1 ä p/21o:/Ò}ó
ß]
Ü l€ó
ß6Ü :AÒ}ó
)à ñ :ql ó6à ñ
mN(1N&(1C:21=#A5V3%I:#/**#!|=!#/
¼]%N#k:(1^!1;"#/=;_*!>(_(1^1;"=½
5Y!‰(1^C|=n
$N#1Cef$‘9K=fÄ/ijK9*C#*e"f$ÅAi=5]/!I/(1!
.#/0(1>?#!#0(16
?*@2A0BC ¥EDGF7Hl¡ C ¦JI"K1¤LE¦JMJ¥ @CON MK=¤X¤X¥PI¦9QV£¥ISR
(^!1"_5B! (1'*!9C9#/V6GPC;1>1*([#T/!*
{
#1;-#_0(=#/11V{l5]!C$#/+(-!*$6
T'o¨0ttsu0§v+©T;*+!2?(?5]11#"35^(1/!*:%'"(
(N19N¼s6 >6*!0#/!&1/!!*0½G#1;:"G!"F
90#A…¼s
F'#1;@*FW!*0½+6,ØH/!*3
'
UWV(¼ &M½'X
! &ˆ VY!l5Y!
/!* &#/!N;$;,29,hAFW+*!A%I!~$#*'#/212!$#/16mN(
#/10#/1^(1#/[!|‚?
0#/‚Q¼s* 7
}h
6fA½I;
F
/!*,{
KH6 >
6 ùQÚR_#[!$1T/!*$ÕûXÚDT(.;1#
!A
;
FW!*$
ˆ U V ¼ ù Ú ½ ä Û ÜÝd#1Z
; U V ¼sû Ú ½ ä ÞNß1à6d~#/+(
/!*,(=#:#*<#/!0#/Fl#$;(1?§
or×/¨+q]tsu/Õ&#~!*
/5^!* 5]#"@5Y$%Ã#"%N#$
(1_#?/!90#A1#/*F
+!Jˆ~ú:ì0ú:ìüR5Y!'!$1$;)¼s!*;=½~*!9K#
>_(=#A
*!0#N#1;?1/!N/!*N#/!'1
I/!*b#¼ [ \
ú [ ½&#/=;_(
!1"<!* #/)1b!*#¼ [
ü [ ½+KJ#1;4ü ì+ü ì0ú„5]/!T!A9;$;
¼s+‚/!*$;=½*!96&#0]
( [\
ú [$0#1;M5]/!# 1
V$#1#21"3
¼]( !*'$#/Z"-*1;=½+Õ [
ü [10#/=;
'5Y!b#}1
'$#1#21"3
¼](!*C$#/Z"[!A½+6
^_ ×y1yvr
tsu0§v+©H;
*!2~%'(1#/k9=; 51"G$#,2~*!0#/1F
/!*$;Vˆb#.*!0#+ !*X
&ÚDˆ `a+CñßHb¼ c/21edMó
ß)Ü dVó
)à ñ½+KX#.F
/!T##/</! 9+!0#</!*
&æ_ˆ `7+f<'=X4¼ 3Gïì >ì 365Vì
+CÛ ÜV¼43b½*½+KV#1;#.1+! !</!**& ÿ ˆ `\+lÛ Ü¼43b¾½+¾6:¾ mN(1
0(=#A!0#+!*l(1b+(1#1V29.*"5Y
1>?(1b‚
$;-#=#/F
"{SF%'(=#A.;1#A0#)$#/E2.*!0#*!*$;M6EŽW_%'l1*!0#/…(
*".#/=;_!0#/2{%Ng
6 $I9*!0#/
/!*G$#,*!0#*!*&1+!K%'(+(:#/!^0(=#A!0#!*$;:29 #
*!0# {
a
6 $I1+! !A9;,(1_1@2{%N
[…9k@#S*!9h
6 $I(=#1l3
i
U ` (¼ &M½!
&Zˆ `e!&5]/!'!*g
&-#/! ;
1/$;[2.hAFW+*!C#22!#/^0#/!**F
>_%'"(Q#Z1!'#* 0(=#/!0#/!$K1*T’H>!f6
\ 9*!0#/Q1*Q5?#…*+!
*>=#A!KT#…!F#=;
#<=;
"JZ
6 $I1+!_%'(…*!0#/15Y!$;4…+(1#1
(1#$Z#/5BD#9*!0#/[3
6‡`bO11!}#+#/
/!*K^;#/0#)##1;E#Q!40(=#/1^$#E2}*!0#/15]+!$;VÕ
)1/! !1"<!*KJ;#/0#}#@2:*!0#5]!;V6:mN(1?k
+!+!5]/!_.#A+(>KGs6 6J(1*15]I1/5^3%I
H(!1>(:#b1!$K#/!'#A!N*!0#/'¼](1H%'
2b‚
1#1;}}(1‚9^*21*+½+6~`b*" !0#/1
#/*(=#$.@.#/0(SE#Q*1*5]C*"…5b/F
_/!*6@mN(1.*>1#/!.5]/!#-!/.(19;+‚
*
ˆ -/1&4¼ 3Gïì #ì 365Vjì +lÛ Ü4¼ 3½*½+6~mN(Cb#/Q#;
$=#A!!*F
0#AJKG!+=¾¾¾ >-(1?5]#,(=#A:1#/!0#/!,#/!.=#/**$;VKG#=;
**21"?#C!*1"&(=#/b2I*!0#5]!$;?21#0kT?#l+(1#19%'(
#b;"LM!G$#/=#/"3[¼]3
A½+6H’1!$#/1(9;,‚
K(
*=#/11/0#/\
3Gï k
k'365]lm38#1"6GØG!FH#/=;_1;"F
1C#/! 5]/!$;}*¾1¾>_¾ (!$;
$#/{b*!1/!ÞNß8G6
$I1!&/!*H!!*9*+!
n
6 $I1/!&#/!^0(=#
F
~(1#/~$#.$#A!*!*.;1#A0#&FJ5]/!N(1'11!N##/F
-#;1;"1#"[#!1"0(=#/11jo
6 $I1!N!*N#/=;F
/!&!1"_/!*&#/!^"_*$;?#G!*!;-¼s!#/A½H0(=#
F
}2+3%NO19?(1#/[.#/0(821#*$;EO*!0#6
4. Contract Matching and Connectors
P_;|11_(_!0#/1#&*.# /5^1b/F
*"D8(1[*V6‰ùQÚIì*ûJÚÎ#A!@*!0#}!*KCù-æì*ûVæ
#/!}1+![#+#/E/!9+!0#E!*KI#1;…ùZÿ~ì*ûJÿ
#/! 1/!C!1"[!*6'¼sùQÚIìù-æì*ù ÿ ½IC#}^/!*$K
s6 6~#"!9?*!9:5Y!€(!19K~#/=;
¼sû Ú ìû æ ì*ûJÿG½Z#R1[/!*$Kl
!A
;
>S*!9.…/(1!
196‰ØH!*Z#A!@{
$;V6 mN()1/!-/!*¼j#+F
#AO#/=;4!1"1½_#/!}!*!$;E)1?.#A+($;
2=#/*$;))*!0#6:P,%'&9*!9;
1?#}91:2!b/5I*!0#/1*"F
.!1^;
*!21>:0#Ab0(=#>K
11;1>:#+9"^*10(
#T*!0#T.#A+(>KJ1+!T0#/21*(1$KJ!0#/
#1;S!0#/4!1"6mN(1[!1:%'C;|11(1<ts¨*×/y1©q]tsqjoy
©v+n×ytsqjª©6~mN(1,%'!1#l*^5M(1N*!0#/1*"!15]/!
(1C#**$#/MUVFW$#/11K9.=#A!*1#/!N(^!$#[!IFH*
6 >6Xe"f$‹/iHmH#2?f6 Š96N`l(1!^!C#/! X#;V6
4.1 Contracts
mI%N@19T$#/S!$#$K&s6 6$#/…2.1$;MK5C(1!
9*!0#/N{b¼s1;?N5J**210(=#/10½5]/!Ã# *12
F
3
_!B#A1*(J6QmN(:0(=#/1>,(!>=#/NUMF{#1T!+F
#+…![%'(0(S!$1"!:+(1#1N1#,@2.(1.#/6
Æb+!@%I)1"8!$!)#S*12
3
Q!#/*(1D23%IR(1
!*6bmN(1 !!#…תª0v{§=t#<1l2=#/*$;ZQ(1 {K
1/X(~1#6VP&#**&(&5Y$%'>0(=#1/3
6 !srXt ä
+CñßHb¼ c/21edVó
ß)
Ü dMó
)à ñV½J#=7
; !s5St ä +CñßHb¼ p/1e:4dMó
ß)Ü :4dVó
)à ñ :"½J5]/!
9*!0#/l!*'ùQÚ4#1;-ûJÚ^K!*"6ImN(1 *!0#'3
! 5 t)N#*23
^/5 ! r t^K"5(1'!=;
"&%I$#k1$;#/=;
(1:=;
*!1>/(1$;V6_79>=#A! #A!#**$;
Q2$=#/s6ZmN(?5]$%'1><*!0#1*"!ÂZ(1u
N ¡¤M¦ C K N ¦
CvB PY¥ e wfx+Cñ=ßiMÂ[;
*!2'.#/0(11>:5G*+!
ˆ
rXtnzre{J|
5Stn}~5S{c
Û Ü
Ý Q
ù ÚNåsùZæAç ¾ y ü0l y
ÞNßàSûXÚ^¼sûVæ/½ ¾ ü0l åo‚
Û ÜÝ ù Ú åsù æ ç ¾ y ö ÞNß1à4û Ú ¼sû æ ½ ¾ ü0€ l y* %'(1+!-*;}1;"…"‚hƒ„!s5…t†!#rXt'64mN(-1
á*ˆ
ä â]ã q‰ .¼ ‰ Yù æ y ö ‰ Yû æ 2T½_*!9;1[#)5Y!*(E#A!#21 ‰
y‡5Y !Ù
FC
. y #1Š
; ÎFb+!$#/1><#Z
!#AZ¼]!*!$;1½T0(=#/11
#
$
…
;
(
11!$6EmN(1?!-‚
!**:(1-1/!
‰
h
99
0#21*(19$6 Áb".#/K^%IZ%'b+(1#8>(1+!-*!0#
N(=#AC%'X/!*'*!9^5Y!Œ/(1!6
\ *1;}3
>_1*!0#/ll(B;;V6&Û ÜÝ)#1;QÞNß1à;
F
,!*l3
Ks6 6 ù Ú ˆ V Û ÜÝS#/=;Zû Ú ˆ V ÞNß1à&6mN(*_#A!
{
T#10#A1C_(1T!*6IÆb!K=(1 /!*l{C.#A+(Vˆ
Û Ü
Ý4 (? 5'ÞNß1à&KX#1;@(?#/!":#/!F
*"6~Pb%^!"7
U[¼ ù Ú n
½ ‹ŒU¼sû Ú ½N}(C#*6
m
}
T5]/!?(1[UVFW$#/11:1*1#"S*!0#E;1#/0#
(1#/II*$K9(1!'%Nl*!0#N!$#+)¼]('!0#/[2F
{%N_#/>0½+6mN(I9*!0#/G!1~$#1H2~*!0#*#/$;TC(
.#A+(
Fj!1C5Y=;}[*lUVFW$#/11^#/!#6~`b
!N9*!0#/
!^*#/!b*!0#*"_!1&;
*!211>!#:(=#/&#A!
21#*$;2=;
$;
1
ôHb¼ ½b%'(1!Ž
Z,*!9;
1$;#:#
211;@#/!#2_5]/!>Z#.!*!$;)0(=#/1^e"f$‹/ij6?P_(1#A
0(1*-?*!9; #:5B!*(Q#/!#2 ‰ $#;M6
y
ö
ˆˆ ä
ö
ö
ÌV1k3
-/1&¼43¨k ¾$¾¾ kŽ3¨kO§~½
79>=#A!
ÞNß&
8 ¼4b
3 ½
ØG!$;
#/
y
ØH/!*l#=;[+(1#13
© ¼jÛ ÜÝEö1ÞNßàOö é*ê=ë ö
= öÛ Ü
ó
½
ØH/!*'3
íIî Ü)ö
Û Ü
+ ñßH¼43ªki3¨kib
C
3 ½
$I*!0#
+'<'X
= ¼43ªk ¾¾¾ ku3™kOI
§ ½«$I1!l#/#A
+ Û Ü¼4
l
3 ½
$ 1!'!"
I
?*@2A0BC ¥%¬F7­\MJ¥IpQX¤M¦pKq®…¡G¯l¦JMJ¥Q¦9QV£¥PK=¤ AB K A ¥R
*16P'%'V#;1;
!*I(1'!#/}23%I(1'3
C
F
Î#=;(1C*!0#*-*.#/96&mN(l{l#/5Y3.
!!*{
>1#/!0#/9?(=#A_%N"Fj3
$;4‚
!**1Z¼s+‚
!**?%'(1*
3
X$#:2N5]+!$;:*>l(~3
~[½J;l1/H5s#/
11;!
*!0#*"J6P *($%d(1#/^(%N"Fj3
$;*^'!*!$;V6
P[#**1(1#/_#Z!#A.+(1#1 ‰ FC(1.11!:Fb(1#
2Z0#/21*(1$;Z2{%NZb#/=;[!A9B;
!$6~mN(1C+(1#1
&1*$;:29T(^9& 9kN#*!9^û æ #/&(1^*+!!&*;6
ØG#A!0#+!N;#/0#ý.Sˆ !#l%']
( !>Y†E!s #/=;?#b!"?0(=#1
ù ÿ ˆ
! rX‘ #/!:*=;Z.(1,!A9;!$6TmN(Y
N ¡¤H¤X¥ N ¦¡ C K N ¦ @2’ K1¦ @ ¡¤
CvB PB¥ e wfx+f<'=
iJb;
|=$;}#/^5]$%'ˆ
5.1 Typing Rules
\ 3
11>@9+‚
"° .#@|11"Z*./5211;1>?FT.#11>
5Y!Œ=#N_3
6&mN(
!3
^/5=c1;>9'#A! 1*$;Mˆ
°±.ôZSˆ 3
=#/ôZ(=#/^3
f
3
°±i²E†E3
3
7
²'*12{
5 3
°±Ž
‚
!**
“'%I"FW{
$;
mN(1{bB#/1>=#>:
0#/‚[C;|11$;[Q’H>!:g6NmN( F
*!1+!³
+Cñ;ß d+'<'=d+lÛ Ü8#A!Q(1Q1kFj3
Q*!1/!6
mN(1!N1!*bI,#**"5Y[0(=#/11I2=#*;[[(b;#/0# (=#/
G*!0#15Y!$;#/1>(Z6JPN$#$N(1^*+~/5#1N{G1F
*"|1$;V6TP:#**:(1#/(!_ #A $#T1_21#*_{6
-0/21#/=;,ÞNß 8#/!&0#1;1#/!0; 1*!!V5]!H*!9I*>1#/!
#1;[
!$;$#AK
(1b/(1!I3
b1*!!'#A! #1$#/
F
*"|1_(1'‚9$6
mN(1l*.#N/5J(l{C
a%'M2;
|=$;?2?3
F
1>@!1_5Y!.2=#/*Z3
K&3
}1*!!KN*12{
?#/=;
!*Z‚
!**16„P<%' $% #;;
!*[(1*);"LM!9
k9=;[5 !Kb*’H>
!)Š96f6amJ!0#/1*"R!1[2=#/*$;R
(1*3
11>,!1'(=#$b2->Z}( !9^*V6
m&
> !1~5Y!N(^3
'*!1/!¼s*!0#/$K91+F
!$KI*>=#A!KI!$;
$#/A½,*(=#'2-"*$;VK~‚
_5]/!(1
?5]/!?9*!0#/K é xs+CñßX6ZŽW5N(1?(
!=#/\
£0K &Xï:#1i
; &Mð
#/!l5V3
'*>=#A!K9
!$;$#AK#1;?!$;
#/K9!*+"K
(1}(1b*!0#+
+'ñßH´¼ £ì &Xïì &ð½N'/5*!0#+^3
ˆ
+CñßH.¼ -0/1&4¼ 3 ï ì ¾$¾¾ >ì 3 5 9ì +CÛ ÜM4¼ 3b½+ì0ÞNß 8b¼ µ ï ½+ìÞNß 8&b¼ µ ð ½*½
7
2{Z!B#A1Z#/!@R
!11@**21)23%IO3
1*!1+$;T%'"(T(1&#~*!1/!$6GmI%Nl*!1
!0#!
9*!2_[(1;
|=)/5N(1?*2{,!#/Ÿ
† ˆ(1
!1‚
9"3.!7
-0x3Û qÜ ¶W·_#=;.(1b*!0#/1*"9{}!\
-0x#wb0ß ¸ ê ˆ
ä ¹ 3
e -GxÛ Ü¶W·/i ² '
5S{”}~S“ 5S‘)
ü0l
ül åG‚
é*ê=ë ù æ åsýì*ùQÿGç ¾ y
y íIî ÜQû æ ¼sôXì*ûJÿG½ ¾ é*ê=ë ùZæåsýì3ù ÿ ç ¾ y ö íIî ÜQûVæ¼sôXìû ÿ ½ ¾ •ü€ l y* Bý#Yôc2
%'(!Ž
‚–ƒ—! 5˜{ †™! r{ ì*ýˆ&0šS›6[mN(_3
! re{ #1;œ! 5S{ #A!
(I1!G##/,3
g+f<'=X¼4!ïì ¾¾¾ ì#!sr,ì9+lÛ Ü¼4!½*½V#=;
+f<'=X4¼ !è ï ì
#ì !è5 9ì +lÛ Ü4¼ !èY½*½+K!*"6GmN(N!1",0(=#19
#/>#/…#Z
¾!¾¾ #/.0(=#/11~2{%N(1?3%IQ1 (=#A
!1#lù ÿ #/=;-û ÿ 6~m&
$=#/{@¼s!b#_*12
3
b!#/½
5Y! ù æ #/=;Zû æ C!$1"!$;Q"5&%I:#<>1#/!0#,(=#Al(
1/!N3
&#/5Y('*!0#+I3
I#1;_(=#/~(1'F
*!0#/^.#A+(> (=#/N*1*5]"[2.‚
$;M6 \ !=F
*"|=$;<@5Y! /5^#.1"5]_
_F^$#/)>=#/!0#/
(6&Pb%'H;**C(*; =;
Zý[cˆ &0š˜›*(1!*"6
mN( #'!1'C(
N ¡¤X¤X¥ N ¦¡ CŽC ¥
£ P2Q CvB PB¥ e wfxs+lÛ Ü9ijˆ
rX‘;}~J
§
ˆˆ ä
ˆˆ ä
§
¦ #* 3
¥
ö
ö
4.2 Connectors
r{vz~S“ rX‘6|
ˆˆ ä
3
5…‘;zž>|
Û Ü ,ùZÿI¼sõ1½ ¾ y 0ü l y Û Ü
ó ûJÿIå$ç ¾ ülˆ ån‚
Û ÜTù ÿ ¼sõ½ ¾ y ö Û Ü
ó û ÿ å$ç ¾ •üG€l—Yõs y* %'(!\‚Ÿƒ !s5S‘¡†¡!srX‘Iìsˆc&0¢…£c!+6~P #**‡! ž †E!s96nC(
!*1"C5G(1b!1#V0#AJK
s6 60ll#:5Y11+-/5ôX6
mN(*!0#Z%'"(d!F[#/=;R=;
"1Q$#/ 2@!F
1$;@#/b(1_1/! s6TP_#**#/
!F'#/=;<*F
=;
"1T%'"((1Fl#/=;*FW!*6[Ž31
ý) !$1"!$;
}#/5Y@(1:!=;
"O
&0š˜›#1;@
,!$1"!$;@
#A5YO(Z=;
¤
&0¢…£c!+6‡mN(*@#**!*1Z#A!<21"F
>#/Kb5Y!.#*$;R2…*!0#+KlS2<#/|1$;R29…
¼s
!A½T#=;
!A
;
![¼s+½:#A:!6QmN(1_#/*0#0(19,/5
21>#A1',(b1!N!*1"^}/!b
*!*_#=;
1k9N*!0#'#/=;.1+!6&ØG!F&#1;[1;"1'#A!
5Y!:1#K2,(1!(#A!.#/$;#A:!?%'((
!*!*=;>(19;.l9k$;}#/=;[‚
;V6
°±O²¤†¡3
e -Gxswlß0¸ ê + i °±O²¤†E3 °±"3¨† º
°±i²¤† º
mN(1+S*(1$%Î(1#/Ž
†ƒ?#Q
!!0;
!$6mN(}*2{1>Z!1,5]/!
*>1#/!'#=;.!;$#/^#/!a
-Gxs-/1<#=i
; -Gx*ÞNß 8ZFG* ’H>!
Š96f68mN(-1#"
=1à ê 8ndJó
ß)Ü dMó
)à +;ñ dp/1 ê #/=;S(1"!
!$;
#/!#:#/!.3
.#A!B#/216 \ =;
…:*12{
5l#
F
(!T"5^" 1 "$7
ˆ ==à ê 8Œ†»==à ê 8 è "g
5 =1à ê 8¡lˆ==à ê 8 è 6 \
5. Types and Subtypes
PN1*&(1I{
~
‡l*!9(N/!*!0#/21*(1$K
*@#=;…!1#[5T111[2{%N816
*#/"-*12{
'#/! !*0#/^5]!C(1^!*6
P^1*^3
>b!1&T;*+!2'!&3
^
Z670#/F
#/#*+I5M!~1/0#/.(=#$^2.;$#/"~%'"(!9
†
100
° ±³£ ˆ `X-/1&¼43Gï$ì ¾¾¾ ì#365Mìc+CÛ ÜM¼43b½*½ °±a&Xï^ˆ `'ÞNß8&¼43b½ °±7&Mðlˆ `'ÞNß8&¼43b½
e é xs+Cñß1i ³
° ±³+Cñ=ßH¼´£ì4&Xïì&Mð$½Iˆ `*+'ñßH¼.-0/21¼43Gï$ì ¾¾¾ ì#365ì9+lÛ ÜM¼43½*½+ì*ÞNß8&¼43b½+ì*ÞNß8&¼43b½*½
e -Gxs-/1Mi
°±"3 ï è †E3 ï ¾¾¾ ° ±u3 è ¡
† 3)°³±³+lÛ Ü ¼43b½e†Œ+CÛ MÜ ¼43 è ½
°±³-0/1&¼43 ï è ì ¾¾¾ ì>3 5 è ìcl
+ Û Ü¼43 è ½*½X† -0/21¼43 ï ì ¾ ¾¾ ì>3 5 ì9+lÛ Ü ¼43b½*½
==à ê 8
e -0xÞNß8Mi °±-ÞNß8=1¼bà ==êà M8 è8 l¼
ê è ½†8ÞNß8¼b==à ê 8J½
e -Gx+Cñß1i °±}ó
ß܎†Eó
ßÜ):O°±}ó
à)ñ:†Eó
à)+ñ¼°³±ip/1e:G†Ÿp/21
°±+Cñ=ßHb¼ p/21o:ìó
ß)
Ü :ìó
)à ñ :
½ † +Cñ=ßHb¼ p/21ìóßÜ=ìó
6à ñV½
e -Gx+f<'=i
°±uC
3 ï è †E3Gï ¾¾¾ ° ±"3Cè E
† 3)½°±³+CÛ MÜ ¼43b½e† +lÛ Ü¼43CèY½
°±³+'<'=J¼43 ï è ì ¾¾¾ ì#3 è ì9l
+ Û Ü¼43 è ½*½e† +'<'=X¼43 ï ì ¾ ¾¾ ìs3)ìc+CÛ ÜM¼43b½*½
e -Gx+lÛ Üi
°³±u3 è †E3
°³±³+lÛ MÜ ¼43 è ½ † +lÛ Ü¼43b½
?*@2ABC ¥¾6F7­‡QV£ @ ¤ AŠCvB PY¥ISR
;1#A0#<{
_#/=;S11!?!1"{?#1;(1"!?1/!
#+#/-3
6
¿ W¥ À¤ @ ¦ @ ¡¤ Š6 g9
6 ËZY
v É4v Â&y\
v ÆIvr]r"ÖWtsu0§sv ÉyMv+©e
© Äo¨T©q]nb§=rv_תÖ
tsqjoy©T×g
© Äor]r˜o Æc© È
½ ΅ot _ v+j¨ Æq]©v
Ì °Í±“Û ÜÝ ùZÚ^åsù-æAç-q Ä]UÅ`¼sù-æA½@ö ä UÅ`¼sùZÚ&³
Û ÜÝ ù Ú åsù æ n
ç Ä×qsr c© Ê
½ Îot _ v+j¨ Æq]©vCÞNßà
Ì °±-ÞNßà…û Ú ¼sû æ ½lq ÄoU ` ¼sû æ ½^ö ä U ` ¼sû Ú ûXÚ^¼sûVæAo
½ Ä×/qsr c© Ê
½ Î
Ì °Ï± é*ê=ë ùZæåsýì*ù ÿ ç@q Ä"!”õ &›¼sý½+#ì UÅ`¼sù ÿ ½4ö ä UÅ`/¼sùZæAœ
ot _ v+j¨ Æ&qY©v é*êë ù æ åsýì*ùQÿGg
ç Ä×q]r p© Ê
½ Î-ot _ Ö
Ì °Š± íIî ÜZû æ ¼sõìûJÿ½,q Ä*!”õ &›¼sõ½+#ì U ` ¼sûJÿG½ö ä U ` ¼sû æ Y
v+9¨ Æq]©v íIî ÜZûVæ¼sõìû ÿ n
½ Ä×/qsr c© Ê
mN(1:‚
)/5N#/#/@5s#KJ5~(1:;1#A0#[*T#/1>[(1
0(=#1J;b1/C#/5YZ( +(1#1V*!0#$6 \ !$#/
5s#/-5,2/(R=#/!*1#/1>…#+1-#/!<%N"Fj3
$;VKC2.(1
3
1*!0#/9C'1/l#A|=$;M6
¿ W¥ À¤ @ ¦ @ ¡¤ Š6 h
u
6 Ð _ i
v ÆIvr]r"Öjtsu+§sv Éyv+©©Q#o Ä:§
×/¨*×r]rvr'ªonl§
o©qsÖ
tsqjoy©q]7
© É4v Â&yMsv É[pu¨+x
rvTe Ѩx*Þ ¸J6ß +C)à Ò'ó
>i È
ç °±-ÞNßà…ûJÚ^¼sûJæA»
½ °³±iUÅ`¼sûJÚX
½ †ŸUÅ`¼sùZÚ&½
°±-Û Ü
Ý ùQÚNåsù-æA»
°±}Û Ü
Ý ù Ú åsù æ çö ÞNßà…û Ú ¼sû æ ½
Ó2Äu°±‰Û Ü
Ý ùQÚ^åsùZæ$ç@×y ɜ°±„ÞNß1àSûJÚ'¼sûVæA9½ Ã.px9t?y=o
t °½±
U ` ¼sû Ú ½ †ŸU ` ¼sù Ú 9½ Ã&t _ v+yZÛ Ü
Ý ù Ú åsù æ çö ÞNßà…û Ú ¼sû æ g
½ Ä×q]r p© Ê
P"Fj3
$;
1*.>=#/!0#/-!*!-*"d#=;O
F
!0#/ 2(=#$9
!#//!0;1>RO(14*|1$#/1>
(!1>((1G3
G
¼s!F1#1;=;
10½V1*!0#/F
1>S2(1#$
![#1;8.#/0(1>6 mN(1Q2
c3<#/!}8%'
2.)*(A%Î%'(1(!_!#9:!*+![%I"FW{
$;*Õ
5]/! ‚#T.*(A%‡(=#/l"
5 °%±@Û Ü
Ý ùQÚNåsùZæAçö ÞNßà4ûJÚ^¼sûVæ½
#1; "5?/!*<ù Q!B#/$;d29Dù è Kb(1D8*(A%»%'((1!
°»±dÛ ÜÝ ù èÚ åsù-èæ çö ÞNß1à4ûJÚ'¼sûVæA½:(;KIj6 6%'((1!?!*!+
2(1#A9
!C'
!*!$;[2[!1#6
P *(1#X{b#/5]+3Z
!!*l#Cc!C"K
%'"(1l#:5]/!.#V!/536
*!0#.5Y!.#)*2{}5T#/1/(1!."5 ".!=;
"8
%I$#k1$;.#/=;"N=;
}N*!>(1$;?FX*7-Gx+'ñß
Fb%'(1!i
p/21Gìó
ßÜMì*ó6à ñXjì p/1e:ìóß6Ü :BK&#/=;4ó6à ;ñ :&;1.*>1#/F
!?#/=;<!$;
#/:{
6:mN(1_/!*T!0#/#*}(=#
2.1*;+!$;V6}P.#**?(=#A_/!*:;
Q1/:0(=#/1>.("!
/!0#/V6‡’![1+!}##/%NQ‚
.*2{
!B#A1'5]/!'(1#1l3
N?(;[F&*\
-Gx+f<'=J6&mN(1C;+5YF
Z'F*#/!':(*>1#/! *2{IF&*!0#$#A!#
(1:!1")+(1#1s6 \ 1!T!"0(=#/11&:#-*12
F
{
,/5N#/1/(1!l"5~(,#,{C(1#/l$#<2,$#/!*!$;Z5]/!
# *23
NFX*'
-0xs+lÛ Ü6&7
23
H5Y!N(^#/1'k91;?*(=#/12
>+$;)5]/! (1,!T5N(_1#! F^%'(0((1#T#/:#[*F
1(=#AX(!I#A!Il
!!X*12{
J2+3%N:*>=#/
!
#/=;-1/!b#/#A1C#/=;}!6
5.2 Type Safety
m
:#A5]{Q!l(1T!#/)2{%NZ(1T3
T
#/=;)(!0#A=#/N*.#/96-mN(1.!0#/1#N*.#
#A!.;|11$;@# *!0#/1*"*.#/KX*|1$;2Q!1 *+(
#/.*!0#+..#/0(11>#=;411![0#/21*(1$6Rm
#A5]{!* {%NZ**16-’H"!"KH#/1#/*(1;)1/
5]#I%I"FW{
$;)
!>!0#/F'%N?%'I*!9;1#-1//5
%I"FW{
$;*X*(!*"6G79=;"K$*!0#/1*"1J*(11; !*!
{
11>
6CmN(1'c=;
>f
°±
;1l(1 %IFj{;1*l/5
*"D‚
!** y 6 y mN(1[%' 2Q(1Q1*!-
9>#/ 3
b
!*!#/-1=;
!^*!0#*"J6
PT1$;[.;|11T#?1/<5#A5]#25Y! %N,$#
;
|=%N"Fj3
$;
1*6 \ 1!C3
#A|=l#_9*!0#/
{
-"5b(}*>1#/
!.!*!*=;…#1;VKN"5l(1-
!=;"
(;K(1^‚
?/5(1N*!9C#/*0#/+($;:(N1+!
/!*C0#2*(C(=;
"J6
¿ W¥ À¤ @ ¦ @ ¡¤ Š96f'
6 Á“ªoyyMv*ªtWo¨btsu0§o
v 3 æ ä +f<'=X4¼ 3 ï ì >ì 3 5 ì
+CÛ ÜV4¼ 3b½*½©+×tsqY2© ÂIv+©N×bª0o/y1ts¨*תtJtsu0§
v 3JÚ ä +CñßHb¼ p/1edVóß6Ü ¾dM¾¾ ó6à ñV½9Ã
o/n
¨ 3 æ ö ä 3 Ú ÃXq ÄÄo/¨b×T©v+¨+w$qjª0v~§
o¨0Wt &@t _ vbªoy1yv*ªtWo¨I§
o¨0Åt & æ ©×/tjÖ
qY2© ÂIv+©Tt _ v Äor]rvo Æ&qYÅy Ç}ªoy©ts¨*×q]ytsc© È-0/21~4¼ 3Gïì #ì 365Vjì +lÛ Ü4¼ 3½*½ ä
c/21‡×/y ɘÃNq Äbó
ßÜ _ o~r É© Ã^t _ v+yt _ vv*ºv*ªx9tsqjo¾y…¾¾ >o Äe&˜æ ÃNq Ä,q]t^t{v+¨0n_qsÖ
y=×t{v+© Ã'v+©tW×pr q]© _ v+©Có
6à n
ñ Ê
P#**#)#1#>_;
|=5N#/5s#/S2{%N
Š
101
,¡¤Ô¥ N ¦ BC ¥ Š96f6
Õ Ê'Ö1xp©tsq]tsx9tsqjoyOrv+n_nׅÈQq Ä\°ª± y ×yɳ°¨±Oôdˆ;3'ìs×Eˆ;3aÃ
t _ v+O
y °±³×>Ycô y Ê
y ÆNvrYr"ÖWtsu0§vsÉ'§=¨oǨ*×n:©cÈ'q Ä°³± y
Ø Ê*ÙNw/×r x×tsqjoy[ª×yyo…t Ä×qsrq]Y
t _ v+y@t _ v_v*ºv*ªx9tsqjoy#o Ä y ÉoAv+© yo0t Ä×qsr Ê
Ú Ê]Ð1¨×y1©q]tsqjo/y@§1¨v+©v+¨+wv+©.tsu0§=q]Wy ÇWÈ.q Ä°Ÿ± y ï ×/y É y ï l y ð
t _ v+O
y °± y Wð Ê
2'*;!$;(=#/I# 1&$#/2C2/(N#/=;
!A9;!$Ks6 61#Z2/(Z!*C#1;}‚
/!*'*!96
ù & á*ä â]ã ¼jÛ ÜÝù Úï åsù æ ï ç ¾ Ç1ö ¾¾¾ ö Û Ü
Ýù Û þÚ åsù þæ ç ¾ ǽ ¾
y ¢/Y
¼ ¼ é*ê=ë ù æ ï å ¾¾¾ ç ¾ Û qÜ =<ù æÿ ¼ ¾¾¾ ½ ¾ Ç
ú
ú $¾ ¾¾
ÿß
þ
é*ê=ë ù æ å ¾¾¾ ç ¾ Û Ü=@ù æ ¼ ¾¾¾ ½ ¾ nj½
ú
?¼sûGïì ¾¾¾ ì*ûVþs½D½
mN(1&!$1"!V(=#$'2~#A|1$;VKs6 6/1/!H(=#$G
2I0#21*(1;VK2+5]!N#T*!9N$#/:2~!A9B;
$;V6 \ *+!
%'(10(-N
!/9;;}#/=;[#1#"}9k$;$#[(1*!>>!'(1
9$#/S5^!*;)*!96ZmN(1*"|1$#/S/5'?F
*;-
';C1/'
(1b**21"3-5Y!C
FG(!1>(}(1C!1#/^/5G1IF*:5s#/!$6~mN(N%'
2 k;Z#/C}(1‚9'*+J6
5.3 Types as Formulas
mN(!CN# !B#A1*(}2{%N?(1C*!0#+N#1;?1+!
{
6o$I*!0#+^3
N$#/-2l* #^Æl#A!> /!C;
=#/
¼s9;#B½:><5Y!:1#?1*1>5T#<!=;
"O#/=;…#
1;"VKb1$;…2O#*>1#/
!6‰PQ(1#A<#
{%N/F{#!;Q{
,
Ã%'"(@#B#+!5&*!0#l3
l#=;
#.#! /5I1!b3
l%'"()#1)/5I#A5]#2F
{%N(1Z6<mN(*3
,!*!*=;Z(.;14/5
*"|=$#A?#/=; 10#/5]!&#^$6HmN(IF
*!0#/^3
‡
+CñßHb¼ p/1edMó
ß)Ü dVó6à ñM½&!*!*=;
N,(l5]/!_B#
ó
ß
Ü l e û¼sý ï ì ¾¾$¾ qý /½{iIó
6à ñ;91#,>?%'(1+!?ûOˆ p/1&6
mN(T!+5]! }(_*|1$#/5^*+!
,/5^#-$6
mN()$%N+!Z3
<#$!-!*!*=;}4(<0#/V6
m
^5]!l=#A!0#+!'#/! #1{6
7. Replacements and Evolution
Ž3,
>l
K1J>(H0(=#>NT(1"!*+F
"|=$#A?/!0#/VK/!~#/!N!#$;,2T(1+!/F
19N%'"(Q;
"LM!'*"|=#/Q#/=;[0#/V6mI%N
11.#/!*6d’H"!"K^$#/R#)2-!#$;E29
#(!N&%'"(N#/LM+> (1'2(=#$9
!^#1;_(1
A!0#/C1*1+8/5(1Z
Ž
à€mN(1.$#O2Z#1%I!$;
1*>)#Q0#A-#1#"
*_2=#*;4S(1.1:*!0#/6
7
1;"K%'(1#/l#/! ( *$1'"5&#_!1#'5s#jà
mN(1:$#4#ALM#-!1>Q
Z6<mN(1[#/=#"
*?(=#/,<2
$#A!*!;-
'2=#*;}[(1b#1#V1/!^23%I}/F
19,4#Z!111>Q
Z6ZP}#/**1(=#A?1"S#Z*1>
19T !B#/$;2)#(!,#/:#}i
6 $I19
#/!( 1'/5G0(=#>6
PT%'I#;1;
!*!1#b21#*$;<@(1T3
:
Â[0#/$#/Z#1;Z;
=#/$#"[Â}#/=;}(T;+!1#/}55BF
5]'5*+(-#,!#9^!*1"'}11*16^m&
#/!^+‚:!0#AJ6mN(1#/G%'=#/$%E1X0(=#/1>I(1
3
,¼j#1;.0#/=½/5G#T1$K*7
+Z‘6f6
mN(1?#4S2[;
1};
1#$#"5Y!.#Z!11>QZK
*_7
+)‘96 g96bŽ3Q$#/*:(1 {l$#/12,!*!$;MK=(1
LM+ 5'#[+(1#1>?1$;<}2?;
!1$;MKV*.7
S‘6 h
6
P[*(=#/Nk4#/:!1#/T|1!"4#_#Q0#/FW1*!1+$K
(1.%IC%'M9*!9;
1C"^T(l0#AJ6GPb#/**1'(=#/
!B#/1>.#_^$#/1N!B#/1>‚
1>?/!*K=F
*21".#;1;>:%O16PC;
*1*I(C!#9I5X#,*
F
>:!*l1"QQ/!0;!l[1*!0#A:(1T**16mN(,5YA%'>
;+|=1"^5]!.#/*,#_1*,¼sLM+*FW5B!A½I!B#/$6
¦ á q]©}optW×q]ysv É%Æ _ v+yR× _ orv
¿ W¥ À¤ @ ¦ @ ¡¤ ‘6f'
6 ÁhN ¡¤M¦Å¥ ®Ji
e ¾ ib¨v{§=rת0v+©×y4o$ªªx9¨0¨v+yª0v->o ÄÇ)q]y×_§=¨*o$ª0v+©©[v*º+§=¨*v+©0©qjo/y ÊZËQv
ƨ+qYt{v á e biÄo/¨ t _ vT¨*v{§rת0v+n.v+ytCo#Ä e ¾ i'puaÃq]y á Ê
¿ W¥ À¤ @ ¦ @ ¡¤ ‘6 g9"
6 âNq]wv+y ×y רpq]ts¨×¨+uEªoyt{v*ºt á Ã.ׅª0o/n?Ö
§
oyv+y1O
t ã{×-§=¨o$ª0v+©0©)v*º+§1¨v+©©qjo…y ä y ª×ydp0u
v N ¡¤ I @ I¦¥¤MJ¦ P2Q C Å¥ å
£ P2K N ¥ L pu[×[ªonb§
o/yMv+y1t y è Ãq ÄX°± á e y iIq]nb§r qjv+X
;
© °± á e y è >i Ê
mN(1 ;
*!2(:
!*!#/<5~%N"Fj3
$;
1*l1=;
!b!+F
1#/$6EŽ{>=#/!0#/(=#A?!1#/.;)1/.#/LM+
(1b*Q2(=#$9!$6
H C ¡=£¡ I @ ¦ @ ¡¤ ‘6f'
6 Ó2Ä"°—±
q]nl§r qWv+]
© °—± bè Ã_t _ v+Ÿ
y °—±
á e y i^q]nl§r qWv+e
© °± á e y è i Äo¨T×rYy rXªoyt{v*ºts© á Ê y
ÞNßàJ6à ¶æ`b2996
6. Client and Provider Life Cycles
Ž{Z(1T!
1C*KV%I:(1#$ *<*+!0#H0#/>Z(
"5] +b5#,1N*+(}#'*!9.#A+(1>:#=;.F
/!Z0#/21*(1$Kl!Z*+!
)
$#/V6ÃmN(@5Y1 5Y
+</5:KC!A9;![#/=;O
.*>45T2(
#/=;S!A9;!_*(=#^A%ƒ2}*|1$;4…#<0#1;1#/!0;
5Y!Z6…mN(-$KN1#/!0#+!*$;S29S#@.5C!$1"!$;4*!*F
9K1$#}2 *"|=;Z#^5]$%'ˆ
y ¼sù ï ì ¾ ¾¾ *ì ù ï þ ½ ï á*ä â]ã
Û ÜÝù Ú så ù æ ç ¾ ¼ é*ê=ë ù æ ï så ý ï ì*ù ÿï ç ¾ Û Ü,ù ÿï s¼ õ ï ½ ¾ ǽ
ö
ö $¾ ¾¾
Û ÜÝù þÚ åsù þæ ç ¾ ¼ é*ê=ë ù þæ åsý þ ì*ù þÿ ç ¾ Û Ü,ù þÿ ¼sõ þ ½ ¾ ǽ
C$1H(=#$&b2N#A|1$;:2+5]!'#/T!0#/:$#:(=#
F
J6&`bC#T1.I0#21*(1;VK
#*!9C$#.2'1*$;
*!0#&6[Ž3/!0;!T-5Y11+!!"#/I*!9!F
l$;-.2T#/|=;QFI‚
!**;Z29[(1T1#/!0#G?F
*"Q5#/X=;
9;1#V!*6
79!9<!A9B;
!.1;82Q!1$#/; »R!0;
!}
;
$#J%'(<*!0#G#Al(:#/ 6`l(!*%'*,("!
2(=#$9!C^(1 ;
=#M_(1#/'5G(6
?¼sûGïì ¾¾$¾ ì
û ½ á*ä â]ã
¼DÞNß1àSû Úï ¼sû æ ï ½ ¾ ¼ íIî ÜZû æ ï ¼sõ ï ì*û ÿï ½ ¾ Û Üó û ÿï å $ç ¾ ǽ
ú
ú ¾ ¾¾
ÞNß1àSû Ú ¼sû æ ½ ¾ ¼ íIî ÜQû æ ¼sõ ì*û ÿ ½ ¾ Û Üó û ÿ åç ¾ ǽ'½
\ !A9B;
!b;C1/l$;}1>#/>,Z9+!0#l%'"(<#
".!*KI%'(1+(8.9;
;E241*1>)(1Z0(1Q!0#A!
$#;-/5G(11#/!0#/J*"J6
$IH#/=; #N*!!H#A!~*; 1#/!0#/ y ¢/Y
ù &²Gqõ £ á*ä â]ã
?¼sû ï ì ¾¾¾ ì
û ½&ö y ï ¼sù >ï Û ì ¾¾¾ ì*ù ´ï Ü Û ½ö ¾¾$¾ ö y;Ý ¼sù Ý Û ì ¾¾¾ ù Ý ÜgÞ ½
:5]!ƒ#_*$;}
Z6 \ 1/(1!N$#*%'(0(Q#/*_1$;
‹
102
mN(I;9
=#X!1#H#/=#"
*X21#*$;T{
M>J!
1‚
21{6TÆb$%N!$KM(1,!*1" >(b2?#@LM+ @(!
^-5]/!Ã5&#_0(=#/1> /5G111T¼s21{1½+6
Pb(=#$ #_*#/!C*"=#AZ5]/!C( *!9 !A9;!$6
H C ¡=£¡ I @ ¦ @ ¡¤ ‘6 †'
6 ÁE§=¨*o/w$qbÉvsÉ:©v+¨+w$qsª+vI§
o¨0tMûJÚ4ˆ `'ÞNßàEª×y
p0v:ªoy©0qY©0t{v+ytjr u}¨*v{§rת0vsÉ-pu[× §
o¨0tHûMèÚ ˆ `^ÞNßàRq Ä
7.1 Replacement and Subtypes
$I(1#>QD*!1
!@F_!=+$;d28+(1#1>ZD1+!
{
}F?#/!@1*=#/R;(
ç }…;$#/b%'"(JK2}+(1#>}
U…V¼sûXÚ&½ ä UWV¼sû èÚ ½VÒiUÅ`/¼sû èÚ ½e†ŸU`/¼sûJÚ~½
2(=#$9!~FH(1+!C!1$;2?0(=#/1>I.*!0#/I{&FK
;
.#/"%^#
.#/LM_(1-A+!0#'*14/5 #<*
¼]( *1-b#ALM$;Z"5(1 *|1$;-2(1#$
!lC1/
!*!;=½+6-Ø!*+!#AS5^%IFj{;1*: (1?0(1$#
+!+!Z5]/!C(Ck9=;[5#/=#/
*6
791Z![#/Ù;!}%'(1+(1!.1Z
#!B#/[#(1+!$KH%N$#/S*;!,(1_{
»#=;
"}*12{
6‰PQ%' kR#/-2=;O=#/.d
!A
;
!
#/=;-5B!T=#CZl-=#/!*#/!$6NPT;1/C*B;
!
{
^$1#/1'(!Õ!~!&(^!1#&5V
'2-#/1/(1!^!"
1>?-(1b*12{
b!#/V6
$IK=/!C*!9!$1/!K=*(=#/J2T#;1;
!**$;}|1!$6 \
/!*Tù ä ¼sùQÚdˆ !*Ú^ìùZæ[ˆ !æì*ù ÿ ˆ ! ÿ ½l*(1#~2:!1#$;2
ù è ä ¼sù èÚ Sˆ ! èÚ ìù èæ ˜ˆ ! èæ ì*ùQÿ è ˜ˆ !ÿ è ½+6ÌX#A!NJK%IC%'M#**
(1#/C=#/';:1/l0(=#/1>K11"[(1"!^3
N%'s6
Ž{:*I*"=#A1K/!B#/G
!*!X%N"Fj3
$;
1*ˆ
5Ya
! °¤± á e y i&#1; y èG!B#/ y KM%I_>+7
°¤± á e èiG5]/!T#
‚9 á 6 mN(1}*(1#b$% 2Q9>#/$;EFT|y !…5]/!}#
*>T1$6
H C ¡=£¡ I @ ¦ @ ¡=¤ ‘96 g9'
6 Á ¨sv èx1v+©0t{sv ÉE©v+¨0w$qjª0v.§
o¨0tù Ú ˆ V Û ÜÝ
ª×y)p0v_ªoy©0qY©0t{v+ytjr u.¨v{§rת0sv É-pu[× §
o¨0tGù-èÚ ˆ VTÛ Ü
ÝEq Ä
UWV¼sùQÚ½ ä UWV1¼sù èÚ ½é
Ò UÅ`¼sùZÚ
½ †ŸUÅ`¼sù èÚ ½
ÞNß1àV)à ¶æCù»b#?!|=C5~ù è 6bù è (=#/b1*$19"Z#
*!1>!.¼s!,!*!A½l
!1;"#=;@#%N$#/k!.¼s*
5 °¨± ùQÚNåsùZæAç,#=;
*"|=A½:1;"V¤
6 °¨± ù èÚ åsùZæ$çT'
U ` ¼sù èÚ u
½ †ÏU ` ¼sù Ú ½:#1;%NZ#/**1.(=#A"
U ` ¼sù èæ u
½ †ÏU ` ¼sù æ ½
5Y!l1+!6~mN(1!+5]!K1%N"Fj3
$;
1*''!*+!$;V6
PN*(=#/k,#AG(1G**1^1*;!>N=#A!*1#/!&F
+‚
$ˆ-(=#/?5T#@=#/!0#/b*"E%'(!Q#[#/=;…#
!A
;
!?.#A+(V6<Ž3(1,=#A!*1#/!‚9$KG%N[$#S*
( *!0#'5]!'%IFj{;1*6
H C ¡=£¡ I @ ¦ @ ¡=¤ ‘96 h
'
6 Á ªonl§
oyMv+yt è ª×y8¨*v{§rת0vZתr qWv+yt
ªonl§
oyMv+yt y q]yתonl§
o©q]tsqjoy y ö 8§=y ¨v+©v+¨0w$q]Åy LJÆIvr]r"ÖWtsu0§sv ÉyMv+©© Ã
bq Ê]Jv Ê°± ö ™lê°± y è3ö YÃ&q Ä*U`/¼sûJÚX
½ †ZU`/¼sù-èÚ n
½ Äo¨Tשv+¨+w$qjª0v
û[§=¨*o/w$bq Éy sv É:pX
u YÃV× ©v+¨0w$qjª0v&ù ¨sv èx1v+©0t{sv É?pu y ×/y ɨv{§rת+v+nv+y1t
ù è Äo¨^Š
ù Ê
ÞNß1àV)à ¶æb7
1*T#:* y ö +‚^%'(1+! û)/g
5 1$;<}ù€5 y KJs6 )6 U ` ¼sû Ú ½ †»U ` ¼sù Ú ½+6 \ b1>-#
UÅ`/¼sûXÚ&³
½ †UÅ`/¼sù-èÚ ½:(1}!A9B;
!#A|1(1-!9"!6
mN(C#1&(=#A y è $#/[!1# y %'(
C#/LM>:(1l2F
(1#$
!:5'(1.*"J6QP"FW{
$;*,#:5Y!:1#/$;
Q(1T%N"Fj3
$;
1*C!1T5]!*1_¼sÀb|=Š6 h½
<79QŠ96 g:l
!*!;V6
7*!1>/(11>)(Z.*"|=#/O>(9.2Z#*F
#/216 \ !|119-ù èÚ 5.ùZڌ@#0#/214#@1>O#
UÅ`/¼sûXÚ&7
½ †»U`/¼sùQÚ½b >1#/!0#/9$;V6?mN(1?=;
Š
UÅ`¼sùZÚ&
½ †
UÅ`/¼sù-èÚ ½_;.$;S2Z#A|1$;VKN21_%N;VKN"5*!K
>=#A!0#?(1?%I"FW{
$;* 5^(_!1#/$6[ØG!*"F
O‘6 h<?!.=+‚2.(=#/…Ø!*"R‘6 g9KN2_Ø!F
*"‘96 h.$#@Z2:0(10k$;Q;9
=#$#/-5]! #[*$;
Z6‡mN(1.=;"O%IB;E(=#$Z2<0(10k$;45]!-#
1l-#:!111>:Z6
ÞNßàJà6¶æ \ =#/>1*"-ØG!*"@‘96 g96
Æb+!K!+|=1'#/!T#"%N#$
C!"*$;-#/C!1#6
\ 1#>*@-KJ!1#T#/!1*.¼sLM+*F
Y5 !A½^#C1>#/^(1 11!'!.#/^90#/$6
H C ¡=£¡ I @ ¦ @ ¡¤ ‘6 Š96'Á ªonl§
oyMv+ytXèbª0×/y¨v{§rת+v[×-©v+¨+wv+¨
ªonb§
o/yMv+y1tG q]y_תonl§
o©q]tsqjoy y ö 8§1¨v+©v+¨+w$qYyÅLJÆNvrYr"ÖWtsu0§vsÉyMv+©©
q ÄoU ` ¼sû èÚ e
½ †ŸU ` ¼sù Ú ½Äo¨b×l§=¨ow$qbÉvsÉ?©v+¨+w$qsª+vNûEªoy1yvªt{vsÉ?tWoù
×0y É.t _ v ¨v{§rת+v+nv+y1tû è Ê
ÞNßàJà6¶æ \ =#/>1*"-ØG!*"@‘96 h
6
’1/!G(1G5]!‰/5M#1#"
*&%I^(=#$Nk$;?#/*!0#&/!*
# 1;_(1"!&3
"6’H"!K2$#*^(1'*!0#/I.#A+(1>
l( !1#/G#9"3MÕ=%I,**B#/Z*B;
!1"}*!0#+
!* !B#A$;#/
",#T21*!#26[7
=;
"KV("!T+(1#
F
1~3
,9?([*!0#,Fl%'(+(S(11/!?#/!
‚
;@-21>6mN(1T,+‚$;@}>1#/!0#
(1T
!1;"@#1;-(1T!A9;!lb‚
+$;}.>1#/!0#
(1b=;"-5J(1
!=;"}C#A|=$;M6ImN(b3
5C(1.1!?#1;1/!_!"S!*:(=#$(1!+5]!
2}1>$;M6
7.2 Dynamic Replacement
Ž3@!0;
!TZ#/$%a;
=#/_*"1,#/=;@!1#K
%Nl9*!9;
1l#T1%E5]$#A!bT
!^1/0#/V6GPC*!9;
1
#+‚~|=>!0#Ai
+f¶S1Ÿ£(¼ &-Sˆ ! V ½H5Y!N#!*&(=#/I#$%'
19N_+(1#1>(1"!'*|1$#/<;
=#/#"Vˆ
y‡ë2ì ›$û! ‡šv¢˜× ìbí ›Jš
á*ä â]ã ¼.+f¶S1¡£¼sùˆv! r
á*ä â]ã ¼.+f¶S1¡£¼sû@ˆ˜!s5½
½ ¾ y åsùQç*½
¾ ?åsûXç*½
%'(1+! y #/=;i‰#/! ;
|=$;}#/'Z7
+Z‹96ImN(!*C*+F
"|=$#AS#/=;)0#/VKXs6 6J*!0#+_#/=;@1/!K
#/! !A
;
$;}2[*+‚
+!=#V!*6
Ž3>1/!>}1#,+(1#>bF^(Q$#/#/"%^#
2_*!9;$;
$#/*"[9#T!1#1>IFG(1N1*!^**9#/"}#$%''1I
0(=#>C(1l{
l/5G#T!*';91#$#/"n
6 $I(1#>^[*!0#+
3
~$#[2l;$#/I%'(V6&mN(1C3
l
a*(=#/=(!5Y!2
!9*"$;V6)ØH!*_#/!}#**#A$;4%'"(S3
K6 >
6H(1{1>
9+‚
o
°Z$#/0#/.#2=;> ùQœ
Ú lï
î +CñßHb¼ c/21ed óß6
Ü d ó
)à ñ=½+6
mN(1*'#**#/1I,(1I{1>C‚9G$#/?0(=#>I(
!>(
(1b‚
Z5H5Y!l‚#
+f¶S1¡£¼sù Ú ˆ+Cñ=ßH¼bp/21o:4d ó
ßÜ):4d óà6ñ;: ½*½
%'(1+!p/21od ó
ßÜ)d ó
à6ñR#1;Ÿc/21e:2d óßÜ6:4d ó
à6ñ;:I;
1/Z*>1#/!
#1;!;$#/?{
6.P.#**_(=#AT(111!T3
;C0(=#>6NmN(1T|=>!0#AQ(=#/b#/ZLMl}(13
9+‚
$68mN(1-*.#a
5 +f¶S1¡£(¼ &“e
ˆ ! V ½,(1#//5T#;9
F
=#/;#/!0#/Zi
°&Õ9%Nl%^!‡
°~e +f¶S1Ÿ£(¼ &-Sˆ !´V½{iW6GPb$;
#…1"#C
|=>!0#/…5Y![#)/!*$KI2?#@!B#/_$#
‘
103
**B#/-(=#/1-#/l#.ˆ
!B#/$;1*"6-Ž{$#/*[(_!B#/,(=#/ Z0#k
1#/CFJ5]/!N‚#';1NT0(=#/1>I?(1^‚
99"!
F
^¼]0(1$#sK>#sK96 ½ FJ2;
1/&!*1"&_#b1*F
X!1#$K( (1I+LMG/5(~!B#/X_/(1!
11$;8?(=#/.2<;!$;V6DmN([1;
#>#@2?;1,0#/$#/"<2Zk
>Z#/#G9#/G/F
*"1b2=#*;ZQ(1TA!0#/X *"|=$#AE¼j#/H
#1;!A9;!,*$;S1#/!0#B½+K&21
T*(1;!0#/(1+!_2
;)-(1*.1T#+=#"1$;@Q#Z?F
&?5Y!„5M1!l¼j#1;_111$;:
(1*A½NQ#_*$;[Z6
790#A!*1> 5]/!I(1~;
=#/^#1#"
*~&(^1{%N!k:5
11$;1I#/'# !*0#/}I/5J6mN(N
(1‡
õ^˜o ÆǨ*×+§ _ /5N(1?
ZKV%'(10(S;*!2 (1?*!!
5J(1lƒ[!~5X^1k#>^2{%N}1&F
(1~
5=1A%'>/!0#(1H;
*!2I(I*=#A#
*!1
!N5
11$;<!**, *!9;$;<…e"fAŠ$X
i $I(1#+! †6f#/=;
Å
6 h96&’H$%'>/!0#1(^#1;?;=;
1_#1#"
*I2=#/*$;_*!0#+
3
I*(=#M1$%D2k$;[#/$6 \ N‚
/!*';=;
.(1l1J [ I/!*$Õ
(l/!*';=;~}#(1+!
19J [ '‚
!*$6NmN(1l;1;.!#/Q'*!0#*
#1;}#/$%'^I_;
!1'%'(10(}/(1!N1N#A!b/F
#"Q#ALM$;-"51T1'(1#'?2T+(1#1>$;V6ImN(1
*1;
1;?!#/Z1;I:2b!|=$;V6GmN(1b!$#/*
H(=#A&#l0(=#>N,(1I+‚/!*9+!*5s#N51N^¼]
(1:%N!*$½T>( I#A5Y(_!$1"!9b5'#-*+!
!$1$6SŽ3S(1?#*}(![Q5]!*(!LM$6SŽ34$#/*Z#
*=;?I#/LM+$;VK(1?"~$#2N*!$;_!1#
(1'19^#'%N&¼s1*1>?0#A:#/=#/
*0½+6
¿ W¥ À¤ @ ¦ @ ¡¤ ‘6 h
u
6 ÐÆ~7
o ö/q]0y É© #o ÄǨ*×+§ _ ©b© _ ×r]rVp0vbq]y1ts¨Jo Éxª0v ɅÊ
£ M q]©~
Á¤÷ q¡ ø AGC K;
× Ç¨*×+§ _ Æ _ v+¨*v^y=Jo Év+©^ר*vG§
o/¨+ts©XùQ
Ú Ã9ùZSæ Ã
ù ÿ Ã
û Ú Ã9û æ Ã9ûJe
ÿ à ¾¾$¾ ×y É sv ÉJÇv+©NרvNªoyyMv*ªtsqjoy©N¼sù Ú ìû Ú ½+ì$¼sù æ ì*û æ ½+ì
¼sù ÿ ìû ÿ ½+ì ¾¾¾ Ê Ð _ vZvsÉJÇv+©-רv³ÉqY¨v*ªt{vsÉ×yÉv*º+§=¨v+©©OÉv{§v+y=Ö
Év+y=ªqWv+c© Ê,¼sùZæ/ìûJæA½:v*º+§=¨v+©©v+©_t _ ×t'×[¨*sv èx=v+©tù-³
æ Év{§v+y É/©_o/y×
§=¨ow$bq Ésv É}©v+¨0w$qjª0vbû æ Ê'Á LX¥9£&¥
¤ LJ¥¤ N Q A0C K;£ M q]©Tf
× õ^˜o ÆǨ*×+§ _
v*ºt{v+y Év É-pu-ªonl§
oyMv+yt^q]y1t{v+¨0y×;r Év{§v+y Év+yªqWv+© ÃCJv Ê ÇWÊH¼sûVæì*ùZæA½
©+×u/q]Åy Ç@t _ ×t,v*º+§
o¨0t'û æ Év{§v+y É/©-o/y…qYnb§
o¨0t^ù æ Ê Ð _ x9© Ã × ÉvÖ
§v+y Év+yªO
u Ǩ*×+§ __ ×/©_t Æ~i
o ö/q]y É©?#o Ä[sv ÉJÇv+c© ÈZsv ÉJÇv+©¼sùZæ/ìûJæA½.ר*v
ªoy1yv*ªtWo¨+©-p0v+t ÆIv0v+yOªonb§
oyv+y1ts©-×y É)sv ÉJÇv+©[¼sû æ ì*ù æ ½[רv}q]y1Ö
t{v+¨0y×'
r Év{§v+y Év+y=ªqWv+c© Ê»Ó2Ä-(¼ &Jïì &Mð$½Q×0y É4(¼ &ð/ì &ù$½-t _ v+yd(¼ &Xïì &ù$J½ Ê
Ð1u0§v+O
© ã§
o¨0tltsu0§v.×y É<ª _ ×yyMvrGtsu0§>v ä-© _ ×r]rp0vש©+o$ªqj×t{sv ÉÆq]t _
v*ת _ §
o/¨+t~yJo ÉJv Ê
7
.#$#".(1;
1;.>!0#/1(-C#:2=#/!*">/!0#(Z;+F
|=$;T:{%Nb;"LM!H!#A1ˆH(b©xptsu+§vC¨*vr×tsqjoy23%I
19l#1;Q1*FW9+!=#X;=;1l23%I
*!9'‚
!*~#1;?*!9~/!*6 \ 19&$;G
#/5B.&!*&!0;+!IT!A9;^*!9I /(1!I?F
6 ¦ …;+5s#"$K^#'_211#/?23%I…11
#/=;
1
?*!9#A!-11;$;4S(1};1;S>/!0#1(V6 \
!&!*N#9X59+!=#9;
1;X$#/T2I;
!$;
5Y! #-1 "5].
*|1$#/O¼s**"|1$#/
5 y ¢/Y
ù &S=#/>[‹½+KG%'(0(4;*!2,(‚9=#/9*2
!0#Q2(=#$9!C/5&#_1$6&C$1N(1#/C
!
25Y!.#-*!9
!/9*1;$#/.#[#~;=;
16
mN(1G1;:2~!|=$;,+‚",2(1I1G;
!$K
21
^(1'%N;}!$1"!?1*;+!l(T#1#X*+!
T1F
0#/16
mN(1%IFj{;1*,/5l#Z*S*(=#N2.‚
!**$;
2}#_*1}1/-5Y!l;=;1.>/!0#1(6
¿ W¥ À¤ @ ¦ @ ¡¤ ‘6 †'
6 Á½Év{§v+0y Év+yª]
u Ǩ*×+§ _ ã{o¨,
× õ^˜o ÆǨ*×+§ _ ä.qY©
¤ I @ I¦¥
¤V¦ q ÄgÄo¨ ×r]rXv ÉpÇv+©T¼sù)ì*ûJ½:>o Ä t _ v:ªoy1yv*ªtWo7
N ¡
¨ ö/qYy ÉWÈ
U ` ¼sûX
½ †ŸU ` ¼sùQ½,
Ò U V ¼sùQ;½ ‹ŒU V ¼sûJ½
á*ä â]ã +f¶˜1¡£¼sùZÚ4ˆv!srXt~½ ¾ y è åsùQÚç
è
¼ +f¶˜1¡£¼sùZÚSˆ˜!srXt~½ ¾ y è åsùQÚç
á
*
ä â]ã Z
y
ú
Û Ü
Ý ùQÚNåsù-æAç ¾ ¼
+f¶S1¡£¼sù Ú Sˆ ! rXt ½ ¾ y è åsù Ú ç
ú
¼ é*ê=ë ù æ å ¾¾¾ ç ¾ ¼
+¶S1Ÿ£¼sùZÚSˆv!srtI½ ¾ y è åsùZÚ&ç
ú
Û Ü =<ù ÿ ¼ ¾¾¾ ½ ¾ ǽ ½D½
mN(';*!2N(1#/N#T!#9I%'V#"%N#$
N!*"^-# !F
0#21*(19N5X(b1!$K
s6 69(1C!$1N5Y!C#T*!9
%'M2b.#;C#>#J6&Ž{5V%NC%^#/9~:.#/k'1*l5V(1'!*1"N/5
%I"FW{
$;*!*!9>[!1#_¼j#!FW0#2*(
/511!1*#A!*,,(=#A$#*A½+K%N^$;,l.#k
(}‚
"-O(<10#AJ6‰P<*!9;
1<#3
FW21#*$;
>=#A!0;VK/!"b*#/!XC(~.#A+(
F{!0#//!X5Y11; T*
UMFW$#1I#/!#/9ˆNe 3‡ðMiAU ¾ D%'(!*
3ðZN# 2$#/}+‚
!F
*Q2=#*;ZQ#:{
Nc=;
>$6~mN(1{
Ic1;>9C#/l#
# *1'=;"..#/k
>b(1^3
> ‚9&‚
1"N?(
0#AJ6&Ž3}
!l*"1#/VK1%N 1;-*"5Y
¾$¾¾¾ +f¶S1Ÿ£¼sùQÚSˆ !srtI½ ¾ e ñ^b¼ °± y ½{i y è åsùQÚç ¾¾¾$¾
+‚
!**1>T(=#AN""5J{1> N1/N
!*!$;MK(1'!FW0#/2F
*(19'/5&#_11Z'1*#/!*-#/5B!#,!1#$6
mN(?*12")5I(_3
:‚9 $#/2_5Y!:1#/$;
{%N¤
É/uy=×n_qjªtsu0§=q]Åy ÇQ¨+x
rv+©b2=#*;))!*1" 5Y!Ù79
‘6f6QØG!*"E‘96 g-!A (*11;*T5^(1:5]$%'1>
£ P2K N ¥¢)¥
¤V¦ CvB PY¥ e ‡
N P @ ¥
¤V¦ C ¥9;
Û xs+lÛ ó ·/iV5]!C(1l3
Zˆ
°³±[ùQÚ:ˆ `W!Ú
°±[ùZÚ:ˆ VJÛ Ü
Ý
å;! Ú †E! èÚ
°~e +f¶S1¡£¼sù èÚ Sˆ ! èÚ ½{i ±}ù èÚ ˆ V'! èÚ
%'(! %N !B#/Tù Ú Sˆ ! Ú 2[ù Ú …ˆ ! èÚ 6IPT#**(=#/'(
*>=#/
!.5N(?!*Tù;
T1/T+(1#1>6P?#*<#**
(1#/n
!èÚ I# *!0#+~{6GmN(1'!1'‚
!**N#*21"
-(b3
‚9$6
$I/!*!*1;1>(I!B#/!1N5Y!~9K%N'$#
5Y!:1#/'# £ C ¡ ’)@ LX¥ CC ¥
£ P2K N ¥¢)¥
¤M¦ CvB PY¥ e ‡
Û x*ÞNÛ ó ·i
FJ21#*$;
QØG!*"@‘6 †6
°±.û Ú ˆ ` ! Ú
°±[û Ú ˆ V Û ÜÝ
å! èÚ †E!Ú
°&e +f¶S1¡£¼sû èÚ Sˆ ! èÚ ½{i ±}û èÚ ˆ V'! èÚ
òl-(1#/1"S(1[3
.!$1"!_5Y!(-9*!0#/(1#
0(=#/1>$;V6€mN(1S+‚‡5?(Ÿ
+f¶S1MF3#/‰;
<1"(!
#ALM}(1<*"D1!}(1<19[0#A6ΎW-1"
0(=#/1>^(13
‚9C;
=#/$#"6
H C ¡=£¡ I @ ¦ @ ¡=¤ ‘96 ‹
'
6 ó'v{§rת0v+nv+y1tlpשv ÉQo/yt _ v:¨0x
rv+©?ªr qWv+yt
¨*v{§rת0v+n.v+yte ‡
Û x+CÛ qó ·Ai×0y É_§=¨*o/w$bq Év+¨?¨*v{§rת0v+n.v+yte ‡
Û x*ÞNÛ ó ·i
§1¨v+©v+¨+wv+u
© ÆIvr]r"Öjtsu+§sv Éyv+©p© ÊôJoa
¨ °Z± y ×y É y è ¨v{§=rת0v+© y pu
o/yMv:>o ÄTt _ v ¨+x
rv+© ÃnÆN
v Çv+gt °± y sè Ê
ÞNß1àV)à ¶æl’1$%'l5B!ŒØG!*" ‘6 g?#/=;-‘96 †6
79#A![![5Y!-;
=#/-!1#/$#/R2<;|11$;
21#*$;}ZØG!*"1b‘96 h#1;-‘6 Š96Nz-(19;
'_#1#"
*T#=;
!#*<#/2
C!1#N%'J2T#;1;9!**$;[1‚9$6
y
7.3 Non-preserving Replacements
mN(_|1!T))!1#>Z1l,#/%N#T#/#/=#"9F
*l53
6 ¦ #*$;QZ(*T!"!#.#?1C>(C2
Ä
104
\ >/!0#1(d1M;#/@<#d1M;1#A)/5:{
#/**#/@5Y!
9;T¼s/!*0½+6ImN(l/!*!*1;^_(!1#'5G{
2=;>
°~e +f¶˜1Ÿ£(¼ &Z˜ˆ !.V½{iV}3
9+‚
°6
¿ W¥ À¤ @ ¦ @ ¡¤ ‘96 Š9'
6 Ó2Ä_
× Év{§v+y Év+y=ªi
u Ǩ*×+§ _ qY©,y=otbª0o/y1©q]©t{v+y1t
Äo¨.×Qªoy1yv*ªtWo¨-v ÉpÇv.(¼ & ð ì & ï 9½ Ã't _ v+ySt _ v W¥ úI¥ N ¦ >o Ä_t _ vqYyªoy=Ö
©q]©t{v+y=ªu?q]©'t _ v ªor]rv*ªtsqjoyZ#o Ä×r]r1(¼ &ì & Ý f
½ Æ&qYt _ ìoû g9bì ü û f?©xª _
t _ ×t & Év{§v+y É©:o7
y & ïÊ
mN(-LM?/5#/…*1S#42}#1#A$;E21#*$;S
(l*!l5V(1C;=;1:!#/Vo
6 $IB#/**$#J#>/!"(1
#Z2 *$;}(!6~mN(1!+5]!K1(1'*(=#/J2 >;V6
9. Conclusions
mN(1l*1"0#2"{}/5X(bUMF{#1I5]/!^(1l;|11"[5G#,?F
-*"D5Y!0#/%N/!kO(=#/}!O2D;F
*!0#/;VKM*,5]!‚#1 (1:Ø(1ÀbFj(1*_e hÇAi&#1;4e h9fij6TmN(1
;$#}5^*>Q#-
!*T$#1T-9;&T?F
*".(1#&(1!^2$#/!*!$;_5Y!*(1+!~2:‚
1"1>(^*?F
#/!"3}5X21"3[#/=;}J6GPb(=#$;
$;}#,*?F
1b5B!0#%I!k5]/!^(1b;!1#/[5XLM^/5G+(1#>^
*$;@6`b
!5Y!0#/%N/!k)#;1;9!** 1#/!*1#A!
(1b!2Ã5G!#1>_*>T1^Q#_
Z6
z-2"{?FH(1'0(=#/1>l5V11[23%I19
FC(1?k+Q5]$#A!)(_UMF{#16?P?(1#$_*!9;$;
(
!>(<!1#T9}
!:#/!#/9$6mN(1T
F
?*+%'(=#/;"LM!_5B!€21"36l#9_
!l5]11;1#/0#M*1 "'C#_0#/FW!0#/Z#/LM>_(1
;+|=1"-5H( ¼s-=#/!*#/!'(1{b[½I1F
;+!}1*;
!0#/V6 l1#.$#R$#/1*<2"{EF,(1
0(=#>l5H1NF&#N(C!*"'5X(l0(=#/1>[{6
C1#NF&#^%I(=#$l*}F&$#/-2*!9;$;.9,(1
$#/11K!*1"1>?Q#_;
=#/#"[{
$;[#16
mJ!0#/1*"1bZ(:
2=#/*$;ZQ(:0#/21*(1l5
1+%S1+1G!:*!0#9#/!#6Xl$#/:23%I
3%I<1,:*!0#1;42!*,3
:#=;S0(=#/11
3
6HØH!*G/5M;"LM!H{
H.#/0(,1=;
!;
LM+!G"!1?F
0#K95]/!.#*$;2#T*12{
N!#/V6ImN(C!#^#/!
*!0#*"1:#-*!0#1*"4
ZKJ%'(1*[0#/,!1,(1
0#/:5~*"@(1#/b!* #A!_J6~#/+(@!*b$#@=#/*
(!1>(Q;"LM!l*"Q0#>lF~‚
!**;-2}( "5Y
5]/!C9l#1;}
!/9;+!6
¦ *_B#A1X#1;*#/!J!#/X/59#/12{%N
!**#A![**B#/N1
:([UMFW$#1T5]!_?F
=#A!1>[!**6,mN(1b(1!*Q1;Q2?#/11$;Q<!
F
‚9$KC"5,%I@%IB;R1*;+!-(1Q!#9}5,
[5
*$;<16,Ž3<(=#A $#/*KJ%I_%N1;)1"<2_
F
!;.(1C‚9!1#"2*!#/21b2(=#$9!I5V(1*C
F
6<mN(JKG%I$#k)21*B#A!"31;2(1I<;|11
#1;?#1#"
*^!1#5V*"16GÆl$%N+!$K
!I#/F
*1
?(!l(1#&2?(1#/~*>b&#/!'(1'1
5+(1#1>ª
6 $I1*$19"K&%NQ(1#A-2=#/*$;E!!#9
#1#"
*l.#/"}}(3
Z6
7
)-0(1>Q!A9;)5Y$#/
!Z5]/!Q(1
;*A+!*/5'*!96QmN(,_#/1",!*,(1+!K;+F
*!2$;42(1}*!0#+?!16…mN(-A!0#/'9;
^;1
9-#8!$;
#/!*68mN(1
$^`b ¦ \ 5Y!0#+%N!kS5Y!.(1
!0#)/5~!/T29cbb2=#*;<@#<29c+!$1
2!k!$6DÆl!K^(1?5Y11+=#/"{8[$6DŽ{O#/O‚9F
*/5V('#!#/+(VK9#_‚
1"I2
!k!~1;_2'*;!$;M6
\ (!bl/55]
! %N!k}1=;
'(1T‚
1!0#A<5
(1'!#/1*(1[5J9;1#/=>'#/=;_(C{'
„5]!N!
*"Q#/=;}!#9'#16
8. Related Work
\ *"[#1>=#/>l5Y!'&%'(0(.^#*_21#*$;
[(bUMFW$#NN!*$;@e gÇ9Kgfij6 \ #/!#A-/5J(
UMFW$#1*$;-[!#*#*)#>1#>KX$#/;
Þ /=0==6à ·˜¸GK%'(0(_*1/!*H#A!1G5Y!G511K#1;VK
(9KH#/! *S+(1#*6?mN(121#*T:#[5Y!*F
.#/#A[5J!0#/1>T29c^#~!**n
6 ý 1
#A!?>_9;
:5]/!T1b*1 #/=;@#;1#/0#AJK
#/=;Z#:*!1>?#/1>1#>T_‚
!*^(1^> 9;6
$N#A0#"
* #[;
1b#1
!#/+(<21B;
1>.1<Q(
ÁzZÌ!/!0#/1>'5]/!.#9#/*H*+(T#/X(1!+F#1; *F
=;
"0(111-e ggAijœ
6 $N#A0#"
*:1*,;$#/,5B! 5]/!.#
#/1>1#>*10(_#/` ¦þ SK $NÌX \ 4/!IzZÌ6mN(1I1G/51(
1/!~(1#/%N'(=#$^*$;_(!'&#/$;,2:(
$N#/0#"F
* #/1!#0(J6mN(1!KM1/! #$%“(1,:1#/
2+3%NQ!*l53%I[2
c36 \ 11!;|11C#!/F
^2{%N(.!*67
+!0#N/(1!?#(!:#*)#;1;9!*
*!0#.21#*$;…8
!F:#1;E=;
"15]/!.(1ZÁzZÌ&K
*:6 >
6Ge Å/ij6CmN(1T_211#/Q/5&( !FI#1;Z=;
+(11 #/=;[!+|=1^$#X'‚
1!$;}}6 >6Xe g/h/ij6
ý 2! \ e g/†/i#/1(!#/1!#0( %'(1+(,_21J(IÁ zZÌ
%'"(?(C=#A!0#;>Z6mN(1'2=#/*l*!!1>b+(
F
#/1*‰G(1bq]©0Ö{ªonb§
oyv+y1tjÖ{#o ÄG(1!0#A!+(K/5]!> #C*!+F{*!F
!$;)(!0#/!0()/5^19KJs6 6X*2FW196?~#/+(
[};*!2$;O2O#*</5:ÁzZ̉;#>/!0#6 \
.*-5,#*"|=$#A‰¼j#R#/21*!0#/-+‚/!*
!*5]#A½'#1;-#:!##/V6
\ T$#/!"T!*:/5(X=#+!H(=#/G#$#/!;,[e gŠAij6mN(!
%I #*?k$;-#A^(1l1-2{%N[(1lUVFW$#/11N5Y!
G*"?*.#/#=;T9;1#/9>6&Ž3[e gŠ$iWK
%I#;;
!**;<(_#/11$#A/5I(1T5Y!0#/%N/!kZ[(_Ál1"F
|1$;z-9;
><ÌX#/1>1#>Á zZÌ e g/‹/ij6[mN(1?1/!:;
$#}
0#/k.5Y! e ggAij6~Ž3[#(!'=#/! e g‘$iWK
%Nb(=#$b*$;[#,#/!"F
#/H5
(1o
ÿFW$#/11XC;
|=&*+!
&!$1J#1; !A9*1
*1>b!$;
1#G(1I+(1#* 5]!&.#A+(>b2{%N?*!*F
96&mN(N#/!#&&#$u
; ÿ1UVFW$#/11^e g/Ä/i#;1;
> #l1‚
2
1#/!0#/!.¼s.#/0(1>½l1 }(u
ÿFW$#16.mN(\
ÿ1UMF
#1_$#/…2.!!+$;S29c_*!1
!6QP.(1#A
*$;D#…UMFW$#1-#/!#/9-(1!Kb2#1*)"ZLM+!Z_
¼s1!*!+½N1+1C#1;-"l#A%'C?9;V{%N?#!ˆ
*!0#l#1;}1!6
P#k!e gÅ/iT*!9;}29cZ!_1$#AR9
(:UMFW$#16lŽ3Q
! #/1!#0(Q(1T1*!_¼](1,+½Cl(
#/N"3b%'(1+(,1"#/H(I0#/21*(1X51(I1F
16Ž{PS#/kJ! [ _5]/!.##/VKI(1.*!9}!A9B;
!_#*
!A
;
C(T:11$#AZ0(=#/116CmN(T*!9:*!#/F
!?(1Z*!0#[0(=#1sK~(18#$1"!?(Z!0#
0(=#/1:9#-(1[#!!#/.9*!0#/:+(1#1_#/=;|1=#"
*b(,!0#/@+(1#1l.9kT(9;C5&(1,*!*F
9 !/9;+!6
References
e"fi,^6 ý?06 òb!0;
(=#/>V6)Á ^ o/nb§=x9tW×tsqjo/y×r)ôV¨×n.v9Æ~o¨sö‡Äo¨1v+¨Ö
q Ä+u/q]Wy Ç'p Av*ªt ^ o/nb§
oyv+y1tÖ1xp©tsq]tsx9tW×pqsr qYtsu6_Ø&(À (*K
Áb!*"3./5~`b*
GK òlA_2+!f$ÅÅÄ
6
e gAi P“6P+k6MŽ{1(1+!0#/1:Áb*1>³$I*!0#+Ã`b2
c3\$I?F
*"V6.Ž3 TN¨*o$ª0vsv Éq]Åy Ç© Ø 0y ɖÓ0yt{v+¨+y=×tsqjoy=×Z
r Ë-o¨ ö/© _ o0§
oy ^ onb§
oyv+y1tjÖ N¨0qWv+y1t{sv ɇTN¨*o Ǩ×n_n:q]Åy ÇOË ^ nT
A6AmJ!k9
$I!5]/X
! $I1
!~7
K b1!0#/=Ø121$#A"
òb
6 Š$F
őK=mJ!k9-Ál1!*"3K
’HB#/=;MKXf$Åő6
Å
105
e h/i:76$I.#/:#1;[ØH6q$I#$#/!j6 \ ’1/!.# \ !#0(?,(
79"|=#/E5 þ #$¤
# $I16Ž{ ¦ 6 þ #/2K:6 mb6
ÌV$#$K_ØH6
z 1 !$K?#=; \ 6bØH *0(FWÆbL+!$K:;"!K
ôJo¨+n?×
r ÐMv*ª _ y1bq èx1v+*
© Äo
¨ 9×w/i
× T^¨o Ǩ*×n:©6GmX0(J6VCJ6XgŠ9fK
Ál1!*"{.5Æ#/>VKJfÅÅÅ
6
e †i ¦ 6NØ!@#1;8À_6N7#>!>s6^m&
>S#1;R7
2{1>@
z-21CØ!**6 9ox9¨+y=×r#o Ä)×t _ v+n×tsqjª×qr Ö1ts¨0x1ªtsx9¨*v+©lq]y
^ o/nb§=x9t{v+7
¨ ÖªqWv+y=ª0v+K=‹
¼WŠ½+ˆ †ÇÅA†Š/†
K&fÅŋ
6
e ŠA7
i ò,6 À ØG#/.#
K ØG6 ÌX#/1.#K #1; Ì&6 ¦ F
#A!0;V6 &*!1> Àb
=#/ l
|=>
!0#/
$IF
*6 Ž3 TN¨*o$ª0vsv Éq]Wy Ç
© At _ Ó0y.t Ê Ë-os¨ ö/© _ o+§ oy
^ o/nb§
oyv+y1tjÖ N¨+qjv+y1t{sv É
TN¨*o Ǩ×n_n:q]Åy Ç
Ë ^ nT Ø…Õ 6
(*Vˆ A!*#/!0(J6 !*/5Y$6 A1*! A ! A 9K
g/ÇÇ9f6
e ‹/i,Ì6mH#/JK ¦ 6.5s#1;#/!sK@#/=; ¦ 6ØG#>
!k6mN(‡7%^#/F
¦ A‚Mˆ \ mJ $I90#/1!D#/=;Ã# ’!0#/%N/!ka5]/!OÆl*F
%N#=#2 þ #$# ¦ $#/16
Ž3i
TN¨*o$ª0vsv Éq]Åy Ç
© /t _ Ó0y1.t ÊË-os¨ ö/© _ o+§
o/y ^ onb§
oyv+y1tjÖ N¨0qWv+y1t{sv É TN¨*o Ǩ×n_n:q]Åy Ç Ë ^ nT Ø…Õ 6
(*Vˆ A!*#/!0(J6 !*/5Y$6 A1*! A ! A 9K
g/ÇÇ9f6
e ‘Ai þ 6 ¦ 6GPS#/!+!?#/=; \ 6 :;6 ý 6 Ð _ !
v ^p Av*ªt ^ oy1©ts¨*×/q]y1t
"J×Åy ÇxJ× Ç½
v ÎT^¨*vªqY©
v @Jo Évr q]Åy Ç Ë}q]t _$# %"6 \ ;;*
F
P*KMf$ÅÅÄ
6
e Ä/&
i :6 mb6JÌJ#A1T#/=; \ 6 Ì&6 ¦ #/k!$6J1(=#/1>}(1_Ø!+FC#=;
ØH1;"@mX0(19 5]! z-!:‚
!**?79"|=#/F
16MŽ3QT6M’!0#/1:#1; ¦ 6MC1K1$;"!K TN¨*o$ª0vsv Éq]Åy Ç©
Ö Ð _ v # yq ÂNsv É))Jo Évr q]Wy Ç
Ø y ɟÓ0y1.t Ê ^ opy Ä$v+¨v+y=ª0v # %"' (OŠ
"J×Åy ÇxJ× Çv+67
!>! &!#>K1)Ì ò‡$^7@fA‘gh9KXf$ÅÅÅ96
e Å/i,Ì6 ’I6 \ 1;
!0#;
C#=; þ 6 Ì69’H#;
!69Ž{9+!1>,`b2
c3
9# $I*!0#/6TŽ3“T6T’!0#/1…#/=; ¦ 6 C1K:;"!K
TN¨*o$ª0vsv Éq]Wy Ç© Ø 0y ÉuÓ0y1.t Ê ^ oJy Ä$v+¨*v+yª0v # %" [\
Ö Ð _ v # y1q ÂNsv É
@Jo Évr q]Åy Ç'"X×Wy ÇxJ× Çv+6V7
!1>+f! &!#>
K=6Ì ò$^7QfA‘g/h
KHfÅÅÅ
6
e"f$Ç/7
i ý?6,6 \ $69mJ
*I$#A!N5JÆb#/!S [ ^ÌV>ˆ \ 79!,Â_ØG#/!*
Ž0*
6 Á ^ Ð1¨×y1©+תtsqsoy1©)oZ
y TN¨*o Ǩ*×/n_n_qYÅy Ç+"J×Åy ÇxJ× Çv+©@×0y É
Öu©t{v+n:©0K=h¼s†½+ˆ †h
f0†Äh
KX`b2!Tf$ÅÄ9f6
e"ffiTÀb‚9*
! ý ( Z#1; þ ! +-mN
!*V6=ÌV>l/5G!>!0#6Ž3
6þ G#/4ÌJ9%IJK;"!$K , ×y Épo$”o ö#o ÄÐ _ v*o¨*v+tsqjª×r ^ on?Ö
§1x
t{v+i
¨ ÖªqWv+y=ª09v Ã!or Ê.'KG1#>[‘ÄÅ$Â9Ä/†Ç
6I*
!}791
Ø12*(!KVf$ÅÅÇ
6
e"fAgAi:`:p6 òb!*!0# N#=;Tmb6 À_6z- c3+!$6C$1"!5]/!&
# $I?F
*"ÌJ#>=#/>6MŽ{<ØH)6 $IB#/1$#A!1sKX`:6 òb!*!0#/ KJ#=;
\ 6 *I1/ $#%N#
K}$;"!0
K 'p Av*ªtjÖ{pשv É1)Jo Évr ©8×0y É2"X×y=Ö
ÇxJ× Çv+G© Äo¨ ^ oy=ªx
¨0¨v+y)
t Öu©t{v+n:©0K=#/>&f†‘$Â=f‹
f679!1>!*F
&!#>
KJfÅŊ96
e"f$h/&
i :6 mb6 ÌV$#$€#/=; z)6‰7
"0#.#A!0#V–
6 ôXo/x
0y É×tsqjo/y1©>o Ä
^ o/nb§
oyv+y1tjÖ .lשsv ÉaÖ1u/©t{v+n_©S6 $N#:2!;>IÁb!*"3Ø!*K
g/ÇÇÇ
6
e"f†iTT6
z-1!$K þ 6
ØG#/!*!$% K=#/=;?À_6PS#k+!$6 \ $N#1^5Xz-F
2ZØ!**FT=#/!*3Ž /Ž*Ž0X
6 Ó0py Äo¨0n×tsqsoyR×0y É ^ onb§=x9tW×Ö
tsqsoy1KVf$ÇǼfA½+ˆf0Â
‘‘KGf$ÅÅg96
e"fAŠAiTT6Jz-1!$6 ^ on:n_x9y1qjª×tsqYÅy ÇQ×y É@opqsr\
v Ö1u/©t{v+n_c© È_t _ v U~Ö
^ ×rªxr x9©06 $N#_2
!;> Ál1!*"{[Ø!*KJf$ÅÅÅ
6
e"f$‹/iTÀ:67
#1>!>X#1;-À_6
PS#k+!$e
6 Ð _ v'U~Ö{ª×rªx
r x9©To
Ö Á„Ð _ v*o¨+u
>o Ä4@opqsr
v T^¨o$ª+v+©©v+©)6 $N#:2!;>Áb!*"3}Ø!*KMgÇÇ
f6
e"f$‘Ai\$l6»z-/!>#/J6êTN¨*oǨ×n_n:q]yÅLjÄ+¨on Ö§v*ªq ÂIª×tsqjo/y1© Ø v+6
\ ;;*
FjP*KfÅņ
6
e"fÄ/iTT6 þ 6 T6 ¦ #0k-#/=; þ 61-P!>(9$o
6 Ð _ v'óCv4ÂyMv+n.v+yt ^ ×rªx
Ö
r x9c© ÈÁ Ö1u/©t{v+n×tsqs7
ª Ó0y1ts¨Jo Éxªtsqjoy16M7
!>!*F´&!#>KVf$ÅÅÄ96
e"fÅ/i \ 6Tz-!.#6
5M#/!*k9#/=; þ 6 z)6TPR1>6:79"|=#/
zZ#/0(1>C/5795B3%^#A!X
$I196Ž3'
#9^6”ýT#*!$K/$;9F
"!$6K TN¨*o$”ª ÊÁ ^ ïÖÅÓvâÖ7nô'ПÖ1u/nb§
o©q]x9n o/
y ôXo/x
0y É×tsqjo/y1©
#o ÄXÖ#o Ä0t ÆI×/¨X
v ÙNÅy Çq]yv0v+¨0q]Wy ÇK9=#>N‹$Â=f$‘96 \ $^z 7
5B3%N#/!l&
F
>!1]
> òllg/Ǽs†½+K`b2+!,fÅŊ96
e g/Ç/i:z)6ÌJK þ 6 8F :679+(1;+!$K`:”6 òl!*!0# K#=;,’I6 \ 0(1!*F
.#J6,mX$%N#/!0;…#“’!.#i
$I*"ŒÌX#/1>=#>6:Ž3
:6 mb6lÌJ$#$Z#/=;dz)6b7
"0#.#A!0#JKl$;
/!aK TN¨*o$ª0vv É/q]Åy Ç©
ÙNx
¨o+§v*×y ^ opy Ä$v+¨v+y=ª+v'o]
y Ö=#o Ä+t Æ~ר*o
v ÙNÅy Çq]yvv+¨+q]Wy Ç*ÙXÖWÙ ^ 9AK
=#/> f$‘ÄAÂ1f$đ96J7
!1>+!*.F &!#>
KJfÅő96
e gfi:z)6
ÌJK
’I6 \ 0(1+!.#1VK9#1;-`:Å6 òl!*!0# 6 \ ’1!.#/
ÌX#/1>=#>~5Yn
! $I*"J6/Ž{:
:6 mb6ÌJ#A1X#=;:z)67
"0#AF
.#/!0#/JK~$;"/!*
K ôXox90y É×tsqjoy©Q#o Ä ^ onb§
oyv+y1tjÖ .lשsv ÉEÖu©0Ö
t{v+n_©06 $N#:2!;> Áb1+!*{}Ø!*KgÇÇÇ
6
e ggAiTÀ_6Y
À [ 79; ##1; \ 6 $l6PR&
6 ^p Av*ªtsj© Ã ^ onb§
o/yMv+y1ts©Z×y É
ôV¨×n.9v Æ~os¨ ö/©q]y # %"eÈIt _ v ^ ×tW×r u/©q]©.×+§§1¨*o$ת _ 6 \ ;;*
F
P*+KVfÅÅÄ
6
e g/h/i:z)6 ¦ +(
#=;T^67
k!1*k9s6/’1!.#/9z-(19;
X5]/o
! $I/F
19I795Y{%^#A!ˆ~mN(1Cl|119o
$N#/11NØH!*6Ž3
TN¨*o$ª0vv É/q]Åy Ç© Ø 0y ɇÓ0yt{v+¨+y=×tsqjoy=×o
r Ë-os¨ ö/© _ o+§-oy ^ onb§
oyv+y1tjÖ
N¨0qWv+y1t{sv ɟT^¨o Ǩ*×n:n_q]Wy ÇÏË ^ nT< A6 mJ!k9Í
$I!@5]/!
$I!7
1=
K b1!0#/Ø&21$#/œ
òb
6 ŠAF{őKXmJ!k9
Áb!*"3K
’H1#/=;VKVf$Åő6
e gA†\
i $l6 \ k91*VK þ 6 ¦ #!$KI`:6ÌJ#"92!>+!$KN#/=; þ >
6 5*s6
$I1*F ¦ #/*$; 7
/5Y3%N#/!Ù&>1+!>ˆ mN(¼
ý /F
2! \ \ !#0(J6.Ž3,
T^¨o$”ª ÊÓ0y1t{v+¨0y×/tsqjoy×r Ë-os¨ ö/© _ o+§ oy
^ onl§
oyMv+ytj?Ö .l×/©sv ÉÖ#o Ä0t ÆI×/¨a
v Ù^Wy Çq]yMvv+¨0q]Åy ǘÃ-"q]nv+¨+qsjª övÃeÓ0¨vÖ
r×0y É6g/ÇÇÇ
6=#Ž $^7d¼sŽ3!=#A=#/ $I5Y!1,Q795Y{%^#A!
1>!1>½NP!k9*(1J6
e gŠA\
i $l69ØG#/(1s6 $I1K $I*!0#I#=u
; $I1!~5]!~(1
Áb"|=$;z-9;1>)ÌX#>1#>6GŽ3E
TN¨*o$”ª ÊÖ1u/nb§
o/©0qYx
n ôXo/¨Ö
n×@r v+t _ Jo É\
© Ù^x9¨o+§v Ø(…Õ ÃA.lv+¨r q]qy Ã\â'v+¨+n?×y1u/6&7
!1>+!*F
&!#>K1)
Ì ò‡$^79F37
+!Kg/ÇÇ
f6
e g/‹/iTÆ:6 F{^6/!k9**#/=;_z)6ØH1k!$6 # %"ZÐo$or ö/qYts6 þ (1,PR
7
1KVf$ÅÅÄ
6
e g‘A\
i $l6/ØG#(s6z-9;1#9ÌV>H5]!Hl$#/*>b#/2
&`b2
c3*FW2=#/*$;
$I1Y
$I*"J6Ž{¡
T^¨o$”ª Ê>B#¨ ÉÓ0¨0q]© _ Ë-o¨ ö/© _ o0§
o\
y ôXo/¨+n?×9r )v+t _ Jo É© ÃCx
r u Ø( Ã@×uy=o$ot _ ÃÓ0¨vr×0y É6g/ÇÇÇ
6
e g/Ä/i,Ì&6 z)6 :6-’1 c6ZmN(1Í
$N#/11™
ÿ1U&6[Ž{é
Álr Çvp¨×qjD
ª v+t _ Ö
Jo Éc© ȄР_ v*o¨0vu ßÐ=o$or ©S×0y É ÁI§§r qsª0×/tsqjoy1©K_=#>hǑÂ9hg/Ä
6
7
!1>+!*.F &!#>
KJfÅÄÅ
6
e g/Å/iTÀ_6P#k!$6J`b29c+ <(1,UM#F $N#/116 Ó0py Äo¨0n×tsqjo/y4×y É
^ onl§=x9tW×tsqjoyKXff$Š9ˆ gŠ/hAÂ9g‘9fKf$ÅŊ96
e hÇ/i:z)6XÌJ1;6 ÁaU&Ö ^ ×rªx
r x
'
© .lשsv ɳÁI§§=¨o$ת _ ÄoY
¨ Ö#o Ä+t Æ~ר*v
^ onl§
o©q]tsqjoy6MØ&(À“(1*KMÁl1!*"E #/ ¦ !VKŽ3"'5 !
Ž3
5]/!.#/k.1=;[#>%N#1;
,zZ#/(.#/kKVf$ÅÅÅ
6
e h9fi þ 6 8F :6^79+(1;
!$6 ^ o/nb§
oyv+y1ts© Ã]Öª¨0q §=ts© Ã.×/y Ɍâ^r x1v+6NØ(1À
(1*K.Ál1!*"E #A ¦ !VKŽ3
5 !4Ž{5]/!.#/k‰11;
#>%N#1;
,zZ#/(.#/kKMf$ÅÅÅ
6
f$Ç
106
Analysis of Component-Based Systems – An Automated
Theorem Proving Approach
Murali Rangarajan
Honeywell Technology Center
3660 Technology Drive
Minneapolis, MN 55418.
[email protected]
Perry Alexander
EECS Dept., Info. and Telecomm. Tech. Center,
The University of Kansas
2291 Irving Hill Rd, Lawrence, KS 66044-7321.
[email protected]
$#0&D'&=8A+0&3+)
+705& &D$#05<&7% B^7%/
& J(%<cBO L& ;
(+)D70;L+ <C20‚8&%6%/
72%#%# CB> C5)5&Y5;5BL7%& =CP) ƒ'/
*#0&(J #%/\70546, 7
$/>2%#+%& +%& C7%&5W/
&D 346&70&127V+)#.70&59& -
=.?6+)
%+
&<70C20* D)D; BI7%&5k=„+C&
7%7&C
F
D@+ %&
…BO C5)5&Y)8BH2%)&5)5I D/
;5BL
7q2%c+*70&5-#0D=
ABSTRACT
!"
$#%&')(*+),&- .0/
1+%2)3546 7%870&509
38+:20/
%;&<>=?6+%&$5#0#%@+A)50&+)5)5&&8 BC<5 &52)
D
E#05#&F2@+G6BH2%)D& I5( %
&B>D& J()6DFI*<* &863
67%</
5#)
%(I+2))50B>7%&59 B
$46&+AB>46
7%&5-K)54C=LM &DMD NM#BO 786<5 & 26&<&M5B
& 5=QP)53
$&& Q&& *
(;5)5&&R2)AB> D@+%0&:2&+%& +%&9#0BO %&A&#% <&7%,+),+0&5+)
&D<*5B;&55="ST28+)#% %&
U46&+V2)WB> 5F5)5&/
&8+%0&:2&8+)8+)X -&+8%50&,B> &5
7%&5)( D:20+%& +%&9#&5&Y79Z)546&7%-#D7
%XB>4E&$#D #%&=A?6+0&$#%<%+
5[ &\W B+
7%&5W# #%2%&& VBH
]2)-2@+,B>5
^ &FX+)
7%&5#%=_H-+%&M# #5(4^F70 2%F5#0#%@+-BO 5)5&&F B`
$#N %/>)7-
6B>56BH2%)&5)5L5/
82)9+)D a#05<1+%0&:2=]?6+
$#5)%
5)7-+*70&5W5F#b72c+*dFefTg^hi#Nb&5
&5)52)=C?6+;
7%&C &78% G:2%&< 5&%;
70
j+)8fIdFe-#b&51&5)52)(^ 7W<5 & 2* D)
#% #N&* * 2
& &WD'7-BH
]+)*
7%65)7
+8#% B>8 8#05B>8 3 2
& !9
*#)7A2)
#N& &YD7k(C7%)
$& !17(T#% Bl
=,mC20&
5BL5#0#%&)3 2%@+%%&:2)*<5 &52)C
7%c#% %&
;5
#%5<&70D7n(J 7+oD20& F7&2)D7n=
_O*%T&
D(M2
oN65B)4A@+%%&:2)^ 7
+705& /
&DM+ <;3#05#D7-$+)5)7&*
;7%&5,
$#%&'/
&=L?6+)L%<5&<C#B>);D:20
%t*CmC:2%
%
e#b&5"†J 2- 71 &Y)V#b&5)35/
&<*C+F D)D; B`70D& =Ci2
oNF5BI
$/>B> 7$B>5
%5)5&T+5<TD$#% #N7=Ce
$/>B>5
+%/
7%k 7FB> 5
D+)7%L
$#%&5)F+%0&:2I2)+*J
70/
+)Z$5MDFF #%#%&)DM;+%& +‡705C B52)
&5
51,+0&D<792)A+)D-@+%%&:2)=ˆST28
$/>B> +7%;7%‡6#%5<&70+F:20&&*& l$* #%#0&D %&
B>58 B>D%‰ *&& Q&&D FD
=.Š-70/\+)D@Z„7
&DF ;&D7%c+;#% %&
‹ B`/\#*'#%& /
& .Œ><V B>*+)82)8 B/>B> &7)r(6#N& &V*+)
+%& +,&<&F5BI &5B!:2)%&-)D 2%%7,;+F7%/
& -#%+=IŠ- D <5()D
$#&& ^ &&;2)8
7%/
+)Zj&*) &5+%B> 4657n=ŽP) 5C
+7%cD
$#0&5/
c+5
…#%5<)+5<*46&70F * BI5#0#%&50&H\5)7
5„#%5<&703+)3
+
& C& :2%7AB> *5)5&Y)
BO%‰5
$&& ,&&D LD
=IST2)I+ 7q‚‡20&C* #%/
#%&-;+:2%$%/\70#+WZ54ƒ&D70c5BTBO 5k&5)
7-+ E#%5<)3+0%&:2)D=
1.
p 7%46INTRODUCTION
3 7A B>\46 8
* 8
$) &
D
$#%&')=Ip;570465C
L5)& B
$&56 BN &/
5F 75B>4^ *
;:2%)+2%7q7%* B^+)52)5)7%
5BkC BJ7%F C)541D
50#%&D=CM&5)*46&+-+MD
$/
#%&'&\ B
(
+705&5&T+ <6< &<D7M+ 7q&C+
er2%#%# TBO I+%&L46 Z*46k#05<&7%7# k%*+)Ch6gIgTsle0e
?LD@+%)5&9ft 3(;5%2
oN-PLuuv0wyxy/\zu5/{h^/\|u}|%(
5)7~+mCFe%efa?L@+% &€fL5
(,5%A2)
F
PLuuv%w5xy/\zu /{hT/wDu0wDv0=
M#%#%&&5W5BL+ Q#05<B> C5)5&Yc7%&5) 2%&7n(
D 7)-8+$P 5IŠ-+)7%F
o2%%&(+)5<8 &
$#;X+o7q2=Fp546<5(
70,70&5)* F& 7A
*#0&')(C5)7AB> C5)5&& Bl2)+V70D& c7&
&F)o#%&D >=,?6+)B> (I3&
$#0b79
7%6&* &YD7
B>55(6BH
46+%&@+Ž+)3 D)D Bl+)8 &5)5
7%k&C2)
D7n=^ST2)C+%&6)D7c6F &4^ C2=I?6+)5/
Q#05<$+)6+;5#)50&\-$7&8 &YDo&5;5)7
$#0&D'7%& =Ger2@+X7* &&$#%5<&70
2%/
;%B>5
&5W5 2C+)F5;5BI70D& =6?6+)%(
26 B+)D #%5<)FD@+%0&:2I *&7$6I70&5)=
?6+)D ]#05<c&C);2%%&#%&5LB> l$2
oF B
=8?ƒ+$b%;#050&D
&;&7%%B>W46+);)D70*c
#% <7="?6+0&8&W7%&<)5&"
*#0&'VZ=?ƒ+-5)7
#% %&
‘&8+8 Bl#BO)V4ƒ+7%8#% <7„
107
$# %L&T+546$8Pk&520Fw=L?6+)6%&ž¦¯¥ƒ&k&7%%&5
+*”$©Fª$«°%&\5)2=I?6+0&C#05<&7%;+;%B>
B>5L+6”$•–C—C˜E#Db)D& =6?6+t#Z6 2k&k5&
&
$&5;F+I B^”$©Fª*«I(46&+8+)C'D#)&5-5Bk+6Z4^ 7
±² ¥%¤ ³´ 0=?6+0&C\#F#b+)TG7%70D7,”$•–C—M˜
%&F+)70D& F*#BOcD
$#%&'8#D646&+)52)C &<
%8#)5&2%& F&
$#%&
%& J=
+ D
€#05<R&5)52)=8?6+
$#0&D'5)7,
+/
&5))20 B2+c&5)52)C
5ZI+%&TF7% 2%%)Z
BO *
F70&5)=8?ƒ++%7#% %&
&F+F5BC
7%)
+C70
33+)C
M#Nb&5-& 2FT+I BJ+
+5
=I?6+)6b%)5)#050&D
’&I+)T5B)#05<+M+5
5)D$+c+5<F,#Nb7,+o&5)52)5BIc+5
#%5<5=A?6+#05BF#0D<5 &846&7q&V46&+1++5
N)8#05<7n(J+$7%& ,<b7n(J 7-+o2%)7%&
70& ,46+%&@+,+F+)D E&C)7n=
?6+)F
7q2%&8ž¦¯¥ ž Ÿ ¡oD &2)F‡”$•n–C—C˜µ#b)& B+3ž¦¯¥-%&=G?ƒ+-ž §ž)¢¥¢¶r ¥%¦&52)8&&
$& 3
&&<&&65)7*+)C·%¤)¢¥CD
%Ldp;›;†8¸;&I70b0
46+)+6
$# %L&L&<=^_“&t&5&MN &5c#%7/
&M7q&)846+8 ‡%&*+)520&785D'2)%=6?6+)
BH2%)D& ):2%
%L 67%b%)7F2)F+T¯% ¹ ² ¢¯% ž6ŒH#%/
5)7&& NM5)73 §ž ² ¯% ž;ŒH#/\5)7&& NM& 2=6?6+;\46
&52)C7%b%)C
$# %6BH2%)D& 3I;&&5)+%&#-4^
2%%* 7R'F8'&
& &=3M%&
$#%&
%& +;
ZD;+o#/\ 7q&&5V2)FW+F)'(5&<
+C+)C#0/D 7q&&5&C2M,+;2%%C(&C*< 5&7
&
$#%&
%& ,5B+)DƒD:20
%=6?6+$¢§¡´ ²%º žI& 2
&T278;)2)7%FfTdle$7%b0%&& M3*”$•–C—C˜»7%#& J=
?6+) C 75# C70b07-+;fIdFe8+)D &6
7
%+8¢§¡´ ²%º ž;&52)D -F2)D7,+)*”$•–C—C˜¼7%b%0/
& J=8_HW+'
$#%&c#Nb&51BH
€Pk&520-w(J+8ž¦¯¥
$# %* #F5&A5%0&&5C*46+))<
&L0#%2)^@+ ^ 7$#072;58 2#02I+)t&I 7%75)7
&F#
F2)& A5B6+$%#02=*s;$+l ¶% §%¥‡&c#%7%/
b%)7‡”$•n–C—C˜‹#%7q&D;+L&I2)646+<I&I&7
& I+ < 52)DM,+;#0<&52)FF@+ =
?6+$#%20#8 B^+0&*46 Z-&F370D<&c8
D@+ %&
B>5F520/
D7„5)5&&5B;D
$#5)%/“D7970&5)B>58
&65B5=L626+;”$•–C—C˜‹#Db)D& 3& 2
F7%
5)C 2%65#0#%@+J=6P0
Q”$•–C—M˜™#Nb&5)(
D:20&<5 &%cfIdFe-+ & 8 2
& &A)7=?6+
7,+ & %5W<b&5A %&& Œ>C+ /
D
tB>56%B>C 7c%D %)D& =CC2)
78#05B
& M&L#% <&7%7B>5I+)6<b&5-D&<&&=6?6+%&T5#0/
#%@+j46 #%#0&7A3c<55&, B^'
*#0&#% %&
=?6+
D20&*ŒH#0%7c,D& ,|I+)54673+)6&ƒ&6#0&
8fIdFe-
70&$5#5)7)X-”$•–C—M˜š#b5/
&5)( 7+T#% #N&;5 26%B>C 7c%D %)/
&5) 3F)7-C+ D
=6?6+8 &8+)546D7+
&I&ƒ#N%&$* 2
& &3;#05BL#6B> ^/
5WD &F5BI
70&F2)+,+)C+)*7+5
D -F52)
&5&R#%5<7%8+FfTdlec+ D
…#%5<5=
eF+) J46I* 2
;+M#% Bk#%(;2)
F
5BI&
$#%b)&5V5&F46F705#)7=Pk(+)*
50/
&DL BI”$•–C—C˜]46kZ#k&
$#%&6%;
5<F 2%05
D')&5)(J46+0&C+)*
$&
()20-+F< 5&7q&\5B
+62%&)8
5%&=Is;'(r+)6#% #&DM;NM5)5&Y7
4^CD7cBH
’/\
I46;&D<&6-+C70D& +%&5/
+%- B^+
=F?6+%&;2%&oX
o2+,&
$#0&#05#&
#%5<*+)5B^46F46F85)&7%+)*7%& Xc46+ &=
mC20&<M5#0#%&&5B+%&L@+%%&:2)C;5)+T&<&L+
7%&5-#05<&7%60B>5
&5, 52)C+;5< LD 65B
+*70&5k=*Pk &(I+o#% BOF+)
&<* *)7,
D:2)L5B)†`_ef-
70(r+)I
LB>5
2)7;%FfIdFe)=
?6+%&F %&$+F#05B>;#F*'27, 2
& &
@+Z*46+)+I #05#;&I #%#%& %&FC;7%& J=
_>;&cN‡D7j+8+*+)#% B
* %&)
+F#%H\W BI#% BI
$#%&7(n%2)F+370
52)5 %6&=LA+)D+)I+T#% B)&L2 &
$#%&7* L
7%#)7%20#5V2)
F85BCB>5$2+1$+8
*#0&'&\
5BI+)F7%&5k(
$#%&'&3 BI+F#b&5)(J+;#05#
N)3 &YD7n(=
_Oj7%7q&&595&54ƒW+870&5)8-70DcB!20& :2%
%(ƒ”$•–M—C˜½ &, &54C+c7%&5)3-#DB>
#BO 5)3 %2),+-¡¦ §ž¥¯%¤)¢§% º ³%¾-&52)=
?6+0&*&52)370b%$&& 5< %< 5& %&82)+
k#N 4^I 2
$#)&5k(%&5 265$Œ>'#%7L;5207q
5'%(6+7&#&J(F&Z1#N715)7A#0%/\ />#%"&
$0=
h6 %L+ &DT5T46&FfT›†¿ | À\(5)7*<b7$2
+$&7A<552)& A5>=$Á;
-7%b%)+)*546
5)5%F 7+ &;BI7%7W¿ u À\=
?6+)IBH20&5)5kD
%&I ^
70&720#53+)6D
%&I B
”$©Fª*«…2%70^&
F20&& J=C?ƒ+BO (D+8%&*+ <6
,70#N)7%%F#0D(n%46&+,+ 2&7%46 &7
2)W
%5)7WD&<7V+052)5+1&$#N =WgI+
%&\$&6
7%&78^*hMef1¿ ÂyÀ%ÃJÄÅ5ÆÇyÈÈ(5)75@+%&2%C 7%&7A2)WhCefM­ FÃ)ÉÄ\ÉÊHÊ&ÇÊIÆÅË6ÃÅÈÌ!͓Ì!ÅÎ # 5=Xh6
$/
#5)%L%& 3&T#Db)D7‡3
L BIÇ5Ï5Ç5Î)ÍHÈ=gI<%I % 52)F& C+)T#%%C
C /\465&7-2%/
5B6%=8?6+$F5BC<%F &7%7W&<5 %FB>5
-#)5&20&5-7%#& .5BF V50[{$&D &79+50[{­ ÉÊ ÃÐ)ÉÑÇ ÍH=8E#%$#0%c++5<& #15B %[DC707-
C BLD<%6BH
E+; %[D­ C5#0+ /
=E:28 BCD<%F+F8#0Do# &#D‡X&
5&7W,Í>ÄÉÆÇ6 B^+)M#%=F"#%M&;B!20&,70b07-%
&I #%+)565)7+CL BJ50#0&FI B+L#%=
”$•n–C—C˜
2.
”$•–C—C˜]&T6:2%
%^#b&5&5)52)6B> Idp;ݠT=
”$•–C—C˜œ46; &5)5&W7%& 7WFc†J +X_O%BO*†k50/
5 2)FB> ƒd;p;›†T=%?6+)B> (”$•–C—M˜ 54CC$2
o;5B
BO2%kBH
"d;p›;†T=5?6+6d;p›;†3%&&(% +0&D20D(05)7
#ZT567&$27$%”$•–M—C˜=5?ƒ+T%B> & 8#% /
<&7%7$%”$•–C—M˜]&L#Db)D7‡‡;ž Ÿ ¡)¢£¢5¡¤¥¢5¦ §6D 2)=
”$•–C—C˜¨ž Ÿ ¡)¢£¢5¡¤¥¢5¦ §C 3&
$& 3,”$©Fª*«¬ +0&/
2%;X+);+c#%5<&708707&& C%B> & A5 2F D'&)F%&\=I”$•–C—C˜;­ k7%& &<6#Nb&5\&6
$/
#%&
%M+C7&& `d;p;ݠ- #& J\&=I?LD+)5(
”$•–C—C˜®5)7Xd;p;›†920#%#5
7%),BH
‹:2%
%
:2%&&& A+% 2 +X<b& X 7-%+)&=
?6+)C
%&LB> ƒ”$•–C—M˜‹&I &<88+MfIdFeF#b)& & 2-¿ÒwÀ=?6+0&;270*7%b0%&& $B>5F56+$5# 7\#L2)7*3”$•–M—C˜(5)7+6
D %)TB> I+C<5 & 2
”$•–C—M˜°&52)=^?6+0&LB> 7%b%0&&5, BJ +;#I B
+;& 2*,fTdlec %&;+FB> 5J &&F BI
70&(
C7% &D7R,+;)D';&5k=
F846 Z-'
*#0&(I3”$•–C—M˜¬7%#& Ž B^ 108
Ÿ¤¡ Ó¤Ô% Xž¦¯¥%Õ ŸÓ%Ô9¢5ž
¥¾Ÿ 9¢§%¥% Ô% ¯%Õ¤ ¯¯¤¾V¢5ž ±² ¥%¤ ³´ LÖ
§ º ž¦¯¥%Õ ŸÓ%ÔIÖ
² ž Vž¦¯¥%Õ ŸÓ%ÔIÖ
§%¥¢¥¾jž¦¯¥"¢5ž
Ÿ¦¯¥ˆ×¢§Ÿ ² ¥IØ¢§¢§%¥% Ô% ¯%Õ¤¯¯¤¾LÖ
¦ ² ¥Ÿ ² ¥Iئ ² ¥¢§%¥% Ô% ¯%Õ¤ ¯¯¤¾ÙÖ
§ º ž¦¯¥IÖ
² ž Vž¦¯¥%Õ ŸÓ%ÔIÖ
ž Ÿ ¡)¢£¢5¡¤¥¢5¦ §Až¦¯¥%՞ Ÿ ¡,¦£9ž¦¯¥.¢5ž
¢§¡´ ²%º žÚ¦¯¥Û¯% º ¢5¡¤¥% žLÖ
ž §ž)¢¥¢¶% R¥%¦.¢§Ÿ ² ¥6Ü\ ¶% y§%¥`Ö
¯% ¹ ² ¢¯% žR¥¯ ² LÖ
§ž ² ¯% ž
Ÿ ¯ ±² ¥%¤¥¢5¦y§^צ ² ¥5Ÿ ² ¥TÜHŸq¦ž¥LÝ8¢§Ÿ ² ¥Ù
¤ § º ¢§¦¯ º ¯Iצ ² ¥5Ÿ ² ¥TÜHŸq¦ž¥)ÙÖ
¡¦ §ž¥¯%¤)¢§% º ³%¾
Ÿ¦·% ¯1ÞßŽà ±%á ¤ § º ž)¢â% AÞßVã ²±.ä à ²±
¤ § º„å ¤¥VÞß.æ5ç ±%á ¤ § º ¡´¦¡ ӎÞß1àçèéâ
¤ § º ¢§Ÿ ² ¥%Þêë¦ ² ¥5Ÿ ² ¥WÞßŽà ± žLÖ
§ º ž¦¯¥%՞ Ÿ ¡kÖ
ìCíHîïLðñVò0ó-ô3õLöF÷;ø
ÿkñ%ÿý D$&
$#0&=V?L-D$5 2%)7V+0&$#% %&
(C+3Ú¥%¦¯% #N- 7„+-5)5% ± Ÿ%¥¾-5c#7V$# 8
*+,%&9+ &D-8+)-b0346# =ˆP)5
+
RD J(+),#!
%¦ ± Ÿ¦ § §%¥&5&„#79
# 5=^er*+); &4^ C&6­ ­+5‡B!
E46+%&@+
+; && (%+%&T#0DC)2%6+^ %&c5)lÚ¥%¦¯% "
7 %¦ ± Ÿ¦ § §%¥;5F<&0&8+% 2 + 2;+$D
=
_OBJ+;5& I”$•–C—C˜b%&;+7&
$#575%fTdle$+ &(
+4^ 2%&7&
$#57A*+0&F# %=G?ƒ+$ AB>5F&
$/
#5)3+)5&F+0&;#N %;&;+#D;7%b07-W+
+ &C
5FM7%78B> ^+)C
50$# CF+)
+ =l?ƒ+F&&5)* B^+)F2)7%7A+ &F5$#Nb7
%*+)C5# 7)$
#%'&)()*)()+C70D& & =_O8520^'
*#0&(
+, 2)7%7"+5&(M.¢ ± Ÿ¦¯¥¢§%Ô/
%85)7„+=V?6+)8
50„# 8 +F70& &5)* B`+);#N C<5 & %&=C?6+5F70& 7-
BH2%)D& ;BH
ˆ8Ú¥%¦¯% o+)l D# 7q-#N=
?6+);N703 BI+F+)58 6%7%&5)3 %l¡¦ ± Ÿ
+F#0D%+2%%
$# %=-CC+$#05#&
B`
*# %;5F70b075<+)C#N&<¡¦ ± Ÿ%=J?ƒ+%&
%&*+)F0Z8 BI<5 &52)F#% #&DFc#NbcD
$#5/
%=;s'()+ , § %¦ ± Ÿ¦ § y§%¥F 7,+)/
.¾Ÿ Ú Ÿ ¡)¢£¢D¡ %§%£%¦
+ &^ T2707=C?6+)0 , § %¦ ± Ÿ¦ § y§%¥6+ *#b)^ #NC B`+)C#0DoŒ>&D7-4ƒ&+3+*”$•–M—C˜a%&%
70#N)7%%!cBH
" %‡”$•n–C—C˜°
$#N %=I?ƒ+5&T#%/
%*#b;
$#5)%^#&5&Y
, § %¦ ± Ÿ¦ §% §%¥%=)?6+)
7%<5 %F B`+0&^ #%#0+-&6+)6<b)& ,51B , § %¦ ± Ÿ¦ê
§ §%¥6)D7 %&$I#B>5
75)=L?6+)T&+)D k7
;$#05<A+X&
=?6++ "
.¾Ÿ Ú Ÿ ¡)¢£¢D¡ %§%£%¦
7%b0F
$5# F+F *
,856\#=?ƒ+%&
+ &;2707A5)*B> l+W7%8\#$27RX+/
=
ùLñúû%ð5í>üký5íHþÿ9þAúþðý5í>ÿkî1ûþWütþ
3.
C,'TRANSLATION
*#0&3”$•–C—M˜ b0&$&F+546,b)520‡Âq(J 7R& /
D# 7q,D7q/\fIdFeRb%&&$+54ƒ,Wb 2%Fu5)7X|0=
?6+C&5#%L&T#%20&%& 7‡&I
$#0&D&
52)
D7%+*”$•n–C—C˜µ#)55=6?6+;+)5;5BI+)F5)/
BO & -FfIdFe$%< &<D ;ŒH!T5)B>5
$$# ^ 7c
<55& %&R%Žeq5#%%&5 85)7"ŒH!
%#02%&
+C¯% ¹ ² ¢¯% ž0(D §ž ² ¯% žƒ5)7‡ž §ž)¢¥¢¶ ¥%¦C& 2=6?6+60/
2)2%C B5)78fTdleo+5&6 ^&
$& 5(4ƒ&+
+6)&;7 6)F8+ƒ# ^;+M+5&(
5)7,+;& +%C+)5)7-&7% BI+F< 5& 2;'&
=
§%¥¢¥¾ ± ã¢5ž
Ÿ¦¯¥ˆ×,¢§Jæ"Ø¢§ ¢§%¥% Ô% ¯IÖ¢§¦ ² ¥æ9Ø,¢§¦ ² ¥¢§%¥% Ô% ¯IÖ
¦ ² ¥æ"ئ ² ¥.¢§%¥% Ô% ¯ÙÖ
§ ºA± ãLÖ
ž Ÿ ¡)¢£¢5¡¤¥¢5¦ § ± ã՞ Ÿ ¡X¦£ ± ã9¢5ž
³ Ô¢§
ž¥%¤¥% Wž¥%¤¥% )æ.Ø¢§%¥% Ô% ¯IÖ
ž §ž)¢¥¢¶% R¥%¦.¢§JækÜ\ ¶% §%¥LÖ
± ¦ º ¢£¢5 ž„¢§¦ ² ¥æÖ
¯% ¹ ² ¢¯% ž„¢§JæX뢧¦ ² ¥æÖ
§ž ² ¯% žW¦ ² ¥ækÜHŸ¦ž ¥Xß9ž¥%¤¥% )æ-¤ § º
¢§Jæ-ß"¢§¦ ² ¥ækÜHŸ¦ž5¥IÖ
§ ºA± ã՞ Ÿ ¡LÖ
?6+)*< 5& %&5 ^70D& 7,A8
%)5)5&52)
+$#5$<55& %&=?6+, 7%&57AF5)5%oBH2%/
& LBH
QFÚ¥%¦¯% 6F+^ #N 7q#N=Ls;D'(
)&3<5 & %&27V+)8'&
5)7X+)5
* 87%/
&57n=
?6+)*ž §ž)¢¥¢¶% -¥%¦0(¯% ¹ ² ¢¯% ž;5)7G §ž ² ¯% ž;& 2;5F+
B>5
7%V'&
5<, =~?6+)jž §ž)¢¥¢¶% R¥%¦
&52)$&C7%b%)7-%+F'&
‹ž §ž)¢¥¢¶% ¤2)(%+)F¯% ¹ ² ¢¯% ž
&52)-%W+-'&
a¯% ¹ ² ¢¯% ž ¤ 2, <3+)8Ÿ%¯% R(65)7
+F §ž ² ¯% ž6& 2;%*+)'&
§ž ² ¯% ž ¤ 2F5<^+;D
Ÿ%¯% $5)7Ÿ¦ž¥)=J?6+)F5)B>5
&5W5BI+)DF& 2;%<5&<
4^c&&<&& -ŒH!F
F%0W+c<55& 22%
BJ@+‡& 2;%$5)3 7-ŒH!t#%&8< 5& %&;B>)D
46&+-BH2%)&5)5<le =
?6+) ± ¦ º ¢£¢5 ž ¶% §%¥ ¤2'&
~ 7+8¢§Ÿ ² ¥ ¶% §%¥ ¤2'/
&
M5;#)5C BL+;D
%& B`
$#N %;&<5& ,5)7
7%b0-46+)9+cBH2%)D& ± ¦ º Ú ¥ ¶% §%¥-5)7¢§Ÿ ² ¥ ¶% §%¥
*2=;?6+;B> ;&F2$46+,+o& ,<%F ,5)
B^+ ± ¦ º ¢£¢5 žo<55& %&cŒH27qN+5
4;Á?" 7Xeq?LI?Cg
<5 &50&=?6+)$&F&F2$46+W+$&F5,<%F X _“s l_“6
s 4;Á;?1<55& %&=
ìMíHîïLðñnó*÷WüHñ-ô3õLöF÷;øOñ
?6+* B^ %X”$•–C—M˜ €&F7%b072-N͓ÅÄ\Ç=
?6+5R&3A&
$#0&A5)& Q5B*+)-5722%
D % %1 l+)#N 8 71<5 &50&=gT@+Ž+)D #0%)9W#Nb&5E
F2‡+5<W3W+\#
Ú¥%¦¯% 0=JŠ2%&#0&7%b%0&&5)F5BL*#;GfTdle$20&C-@+
7%b%0&&5-$
Ì ;Ç5ÄÇ5Î)Í5#(+)%
5Z)F#05B>I <
P)5+
$#5)%8-<D
3&<(T&*0&&5F
F2)kCC#)5T5B+)^L B&<L5B+ƒ#%=`?ƒ+%&
B>6&;20D7%+;b0+)5
‹Œ¢§J¢¥%ž¥%¤¥% ž ¥ å t,+)
)7A+)D =jer(^20%&(6+&$
D@+ %&
109
7)7VÛ)8%ÚW¯% Ÿ%¯% ž §%¥%¤¥)¢5¦y§„¦£9ž Ÿ ¡)¢£¢5¡¤¥¢D¦ § ± ã՞ Ÿ ¡X¦£9 §%¥¢¥¾ ± ã
± ã ՞ Ÿ ¡:9Ú¥%¦¯% LØ5.)+Û);)<IÝ ± Ÿ%¥¾IØÚ¥%¦¯% LÝ=%¦ ± Ÿ¦ § §%¥IØ/.)+Û);)<IÝ
¢§Jæ"Ø>9Ú¥%¦¯% Wê뢧%¥% Ô% ¯)?IÝ8¢§¦ ² ¥æ.Ø@9Ú¥%¦¯% Wêë.¢§%¥% Ô% ¯)?IÝ
¦ ² ¥æ.ØA9Ú¥%¦¯% Wê뢧%¥% Ô% ¯)?)?ØB.é);,()+
&);)CD%'E
7>. å 1¡¦
¡¦ ± Ÿ^Ø5%¦
± Ÿ¦ § %§ ¥X¡¦¯¯% ž Ÿ¦ § º ¢§rÔW¥%¦W¥ å ¢5ž„ §%¥¢¥¾
± Ÿ¦ § %§ ¥
%5èÛ,().D%'E)CGF¶%ž Ÿ H), § %¦
± Ÿ¦§ §¥19\Ú¥%¦ ¯% kÝ ± Ÿ%¥¾IÝ=%¦ ± Ÿ¦ § §%¥LÝ¡¦ ± Ÿ?
I)I)I
7)7>. å Až¥%¤¥% j¶%¤¯¢5¤ ³´ žA¢§9¥ å ¢5žA §%¥¢¥¾
ž¥%¤¥% )æŽØA9Ú¥%¦¯% Wê뢧%¥% Ô% )¯ ?
7)7>8%¤¯¢5¤ ³´ ž ² ž º ¢§Ž¥ å ¦¯% ± žW¤ § º ¤2¢5¦ ± ž
Ÿ%¯% LÝ$Ÿ¦ž¥IÝ8¤ §%¾IØ58)*)(VÚ¥%¦¯% 7)7VÛ%¤¯¥V¦£ º £¢§J¢¥¢5¦y§j£%¦¯1ž ± ¤ §%¥¢5¡ž-£%¦¯9 ¶% §%¥
± ¦ º ¢£¢5 žÕ 5¶% §¥%Õ¤2"Ø*)JD%3,è ± ¦ º Ú ¥%Õ ¶% §%¥Lס¦ ± ŸJÙ)פy§%¾Ù8ß
×- ¶% §%¥Iצ ² ¥)æÝ*¤ §%¾Ù!,(9 ¶% §%¥I×¢§¦ ² ¥æÝ$¤ §%¾Ù Ù
I)I)I
7)7>(% ¹
ž %´¤ ² ž º £¢§ žL%
² ¢¯% K
¯% ¹ ² ¢¯% žÕ¤'2QØB*)JD%3,è>%Jס¦ ± ŸJÙדŸ%¯% 0Ù8ß~× ¢§JæדŸ%¯% )ÙG뢧¦ ² ¥æדŸ%¯ )Ù,Ù
7>;§ž ² ¯% žW¡´¤ ² ž º £¢§ žM,
§ž ² ¯% žÕ¤ 2B
Ø *)JD%3,>
è ,Lס¦ ± ŸJÙדŸr¯% LÝOŸ¦ž¥Ù8ß
×¼¦ ² ¥æ.דŸ¦ž¥Ù¼ßŽž¥%¤¥% )æדŸ%¯% )B
Ù *)E)N.¢§JæדŸ%¯% )Ùß ¢§¦ ² ¥æ9דŸ¦ž¥Ù Ù
7ŽÚ §ž)¢¥¢¶% ¥%¦A¡´¤ ² ž ž §ž)¢¥¢¶% Õ¤ 2"
Ø *)JD%3,è ± ± ³ ¯IדŸ%¯% kÝ۞)¢×\¡¦ ± ŸJÙÙß]×3 ¶% §%¥I×¢§JæÝlŸ%¯% )ÙÙ
ìCíHîïLðñ"OnóoöðyýyíPCö;ô3õ1ý5ð)ÿkú'Q%ý5íHþÿ„þFú5üLñû%íRIû)0ý5íHþÿSMO ú5üLñûDTIüðý-òBUAôV)ð5íQDWHñú5ÿkùAkíHþ,ú
X#B>V+)%&& <5 25B*+)-<55& 2c#5 71
<55& %&(I+)'&
¢§J¢¥%ž¥%¤¥% ž ¤2F+F+o%&& c&8:2 ,Û%ž)¢=W?6+0&852)
&5&9202+
%§J¢¥%Ú¥%¤¥% ž6&;2%C BIÛ%ž)¢=
& & (C+)8
$#5)%*1+5@+%&2%5)5%/
D7„46&+A5#0#% #%&-# =W?6+#)5
$#%/
% %)D& $46&+X+FD
$#5)%(k5F46&+,+)*%/
B>;5B6+* +0&D20(J)75W+F)
BI+$# $/
5=Q?6+%&5)2)7%, . +%&2%W70D#)&5k= _H. 2%
'
$#0&(F+)-£¢§ º ¤¯%¡ å +0&D20,+)4^W
*# %
¸-+8ž¦¯¥% ¯8
$# %(L46+%&@+X&$5 5BC+8ž¦¯¥
$# %(^ 7W+)3ž ¤¯%¡ å ¯8
$# %(^4ƒ+%&+„&* A%/
* B`+);³J¢§ ž ¤¯%¡ å $#N %=
?6+)FfIdFec#0%& ,B>5;+%&F +%&2%Œ>Pk& 2%;v%( X
+(t22)5>(%+)6# ^Ú¥%¦¯% LÝ ± Ÿ%¥¾;5)5
7 %¦ ± Ÿ¦ § §%¥)=
?6+0&C %&C+; +%&2%$FM&
*# 78-+)ƒ +0/
2%=P) &546)9+%&(+),+)D S
*¯%¡ å ¢¥% ¡¥ ² ¯ c&8&
$/
#57-#05<&7%
5%&F8+)*<5 & 2F +%&2% #%/
=*?6+)F# F5B6+$+%& +/>&<C
*# %8Œ>£¢§ º (q
2%3'
*#0&55+97%&57n=Ž?ƒ+8B> °+)#5 B
+F +0&D20%()5)7#%5<&70$%#%2)c5)73 X 2/
#%2)CBH
]+F
*# %;,+$5@+%&2%=C?6+)F&5)5&(
46+0&+A#05<&7%50&5)D46A+)
$#N %A+)
+%&2%( F7%&57R'=
?6+tD
%)F+5
n#0%L+)I)5&/\
*# %L#05/
5B650&&5=8?6+)*
*#0&)F#% BC50&& V&F/
798+-+)D ¡¦ ± Ÿ´ ¥% ¥ å (6+46&cBO */
#%&* %&& 9;+ D
a¢§¡¦ ± Ÿ´ ¥% ¥ å 5)7,+)*0/
D &)D„50&&59*+c+5
¢§¡¦ §ž)¢5ž ¥ ¥ å =8?ƒ+%&
D
$#%&-+-7fIdFeA+)D „BO 3+)-#Nb&5
± 㠞 Ÿ ¡0=
C)L +%&2%6 ^70b%7$%D
6ŒH!k#DB>$
F20/
%&& 8#)+)L\46
$# %5)73ŒH!t7%b%0F&<55/
&53 7q&&5);)7&F4ƒ+3
$# %6+ 2%&7c#%
%#%2)=?ƒ+--5BF59 +%&2%&870b%79-+
2%%& , BJ&6
$# %=^h6
$#N %C
F2%0&& &I+%&<74ƒ+8+^L+ ^ %[=I&<5& &T+
”$•–C—C˜»72 J BJd;p›;†I­ I&&<&c&C5)77q&F46+)
,
$# %8+ 2%&71#0D‡&*0#%2)=V?L+5(6
F20/
%&& A5)73&<5&5A7%b0*+)F
%&F5BI +0&D20
#Nb&5)=
?6+),#b)& A B+)-+0&5+)/“&D<8D
$#5)%5)7.+)
$# %Ž+), +0&D20, &
*# 7.46&+95#0#% /
#%&WŒ>7%#7qW20#N 1+54]+)3
*# %&507
%&&5=C?6+)F5&$'&
~ BI+F+)D Œ>+5
~¤¯%¡ å
¡¦ ± Ÿž *)2¢5¦ ± G 2%C'
$#0&yM7%b0C+;¤¯%¡ å ¡¦ ± Ÿž;
D
$#7W5B6+8¡¦ ± Ÿ%C BC56+
$#5)%FX+)5/
+0&D20=^?6+0&70& &5&C%& LB>5;+F7%b0%&& X B
+; +%&2%;#0D()+M#%T#%%8+)C#)5 /
&`
$#N&& j BI+F
*# %=
?6+F”$•–C—C˜»5@+%&2%;B> ^+;£¢§ º $# %6&6+54ƒ
Vb)520,x=A?6+)G”$•n–C—C˜ +0&D20-&$&7%%&5*+
”$©Fª*« +0&D20(F'#cBO -+25B+ZV46 7
8%Ú)Û ;)F70)F”$•–C—M˜™#Nb&5)C+C+ 3”$©Fª*«
D
$#5)%$720-)5%&& J=3?ƒ+<5 &50&D$A+& /
ƒ70& &51#%%*%)5 %)D& 4^A+
D
$#5)%‡V+5@+%&2%=WP &546)A+& 7%/
110
7)7VÛ%¦žž)¢³´ 1¢§J¢¥¢5¤´-¶%¤´ ² i¢§i¤´´W¥¯%¤¡ ž„¦£Ž §%¥¢¥¾%Õ
¢§J¢¥%ž¥%¤¥% žÕ¤L2 Ø/*)JD%3, èA% §J¢¥%Ú¥%¤¥% žkס¦ ± ŸNÙcß9Û%ž)¢×¡¦ ± ŸJÙ
Ÿ¯%¦¡ žž
I
7)7>8%¤´ ² A¦£9¦ ² ¥Ÿ ² ¥%ž,¤ § º ž¥%¤¥% W¶%¤¯¢5¤ ³´ ž º ¦ ž§¦¥V¡ å ¤ §%Ô% ³ ¥·% §Ÿ¦ž¥>Y
7)Ž
7 ¤ §%¾ % §J¢¥%ž¥%¤¥% ž ±² ž¥W³ 1¤Vž ² ³ž ¥A¦£1Û%ž)¢,£%¦¯A¥ å ± ¦ º ´W¥%¦W³ „¶%¤´)¢ º[Z
¢§J¢¥%ž¥%¤I ¥% žÕ¥ å Ø/. é);,();èAž ² ³ž ¥\L×]%§¢¥%Ú5¥%¤ ¥% žJס¦ ± ŸÙÝFÛ%ž)¢×¡¦ ± ŸJÙÙ
7)7>%¦
± Ÿ´ ¥% § žž,¦ ³´)¢Ô%¤¥¢5¦ §
¡¦ ± Ÿ ´ ¥% Õ¥ å Ø^.é);,();è × ± ± ³ ¯IדŸ%¯ LÝ# Ô%¤´Ú¥%¤¥% žLס¦ ± ŸJÙÙ_*)E)N
± ± ³ ¯IדŸ%¯% LÝoÛ%ž)¢×¡¦ ± ŸJÙÙÙcß%ëA%Jס¦ ± ŸJÙדŸ¯% )Ù
7)7 á ¢¥§ žž£%¦¯.¢§¡¦ ± Ÿ´ ¥% §% žž
¢§¡¦ ± Ÿ´ ¥% Õ¥ å /
Ø .)é ;,();M
è ;)JD%Ú .%ÚQ`× 2IØ8Ú¥%¦¯% )ÙØW× ± ± ³ ¯I×`2LÝa# 5Ô%¤´Ú¥¤¥% žLס¦ ± ŸJÙÙ
*)E)N ± ± ³ ¯I`× 2IÝFÛ%ž)¢×¡¦ ± ŸJÙÙÙ8ß%L
ë E,.b%Jס¦ ± ŸJÙ`× 2)Ù
7)7b%§¡¦ §ž)¢5ž¥% y§¡5¾A¦ ³´)¢Ô%¤¥¢5¦y§
¢§¡¦ §ž)¢5ž¥% §%¥%Õ ¥ å =
Ø .)é ;,();èQ× ± ± ³ ¯I×OŸ%¯% J=
Ý # Ô%¤´Ú¥%¤¥% žJס¦ ± ŸNÙB
Ù *)E)N
ë E,.A%Jס¦ ± ŸJÙדŸ%¯% 0Ù
± ± ³ ¯IדŸ%¯% LÝoÛ%ž)¢×¡¦ ± ŸJÙÙÙcß%S
;)E)N ± ã՞ Ÿ ¡
7)7>;§
º ¦£1Û)8%ڄ¯% Ÿ%¯% ž §%¥r¤¥¢¦ §j¦£9 §%¥¢¥¾
Mì íHîïLðñ$ckó*ö;ô3õ1ý5ð)ÿkúdP%ý5íHþÿ1þú5üLñû%íRIû)0ýyíOþNÿLGO úyütñûDTIüðýU>efkñþðñú
¤¯%¡ å ¢¥% ¡¥ ² ¯% R£¢§ º Õ¤¯%¡ å ¦£1£¢§ º ¢5ž
ž)¢Ô§¤´Až)¢Ô%Õ¦ ² ¥æÝ$ž)¢Ô%Õ¦ ² ¥ gLÝ*ž)¢Ô%Õ¦ ² ¥%ãLÝ$ž)¢Ô%Õ¦ ² )¥ hIØ8¢§%¥% Ô% ¯IÖ
³ Ô¢§
ž¦¯¥% ¯I=
Ø 8%Ú)Û ;)V §%¥¢¥¾Až¦¯¥
Ÿ¦¯¥ ± ¤ Ÿ~×¢§JæÝ-¢§ gLÝ-¢§ãLÝ-¢§ hIÝcž)¢Ô%Õ¦ ² ¥æÝ*ž)¢Ô%Õ¦ ² ¥ gLÝ*ž)¢Ô%Õ¦ ² ¥%ãLÝ
ž)¢Ô%Õ¦ ² )¥ hÙÖ
ž ¤¯%¡ å ¯I=
Ø 8%Ú)Û ;)A §%¥¢¥¾W³J¢§Õž ¤¯¡ å
Ÿ¦¯¥ ± ¤ Ÿ מ)¢Ô%Õ¦ ² ¥æÝ$ž)¢Ô%Õ¦ ² ¥ gLÝ*ž)¢Ô%Õ¦ ² ¥%ãLÝ$ž)¢Ô%Õ¦ ² )¥ hIÝ;Ó ¾IÝ
¦ ² ¥Ÿ ² ¥ÙÖ
§ º ¤¯%¡ å ¢¥% ¡¥ ² ¯r £¢§ º Õ¤¯%¡ å Ö
ìCíHîïLðñ"inólôõLöF÷ø
úyütñû%íRIû)%ý5íHþÿWþF£¢§ º û þWüLþÿkñ%ÿýjú)ðû)fLíHýñûýyïLðyñ
?6+F7-+)D C#%%;+F<5 &52);#% BI50& /
&5);BO +0&D20D=;?6+;0#%2)FD &)DR#% BI50& /
&5A&7A*+),¢§Ÿ ² ¥ ¢§%¥% ¯£%¤¡ ¥ å +)D (I+
52)#%2cD &)D1#05BF %&& Q+,¦ ² ¥Ÿ ² ¥ ¢§%¥% ¯%ê
£%¤¡ ¥ å +)5
(L5)-&<)*#05B;50&&59B> ž¦¯¥
D
$#5)%TL+)^ž¥¯%¦ §%Ô ´)¢¶% ž¦¯¥ ¥ å æT+5
( 7$46D Z
&<T5)7;5)&$#% B %&& I B+t³J¢§ ž ¤¯%¡ å
D
$#5)%;C+F+)D C·% ¤ Ó ´)¢¶% ³J¢§ ž ¤¯%¡ å ¥ å g$5)7
¢§¡¦ §ž)¢5ž¥ ³J¢§ ž ¤¯%¡ å ¥ å ã0="?6+2)
F-c+,)795B
+5
E)
;277&
F%& 2\46G+)F
#% BN %&&5)C5B)+T
6
$#5)%L27$
F2%&#0&&
3+C +0&D20=I?6+;ž¦¯¥
*# %67%TL+)5<M+/
5
C5# 7)3$+;46D Z&<)D; 7c5)&
#% BN %&&5)^k+65tC+I
$# %k#%5<&7q
%#%2)C;&=LC)&T%#026 C5)5)78BH
Q+6%B>DM5B
+;5@+%&2%=ƒer&
$&5&(+M³J¢§ ž ¤¯%¡ å $#5)%C7%
L+ <C; ;&<)C+ D
’L )&I 2#%2)I 6# 5BI+)F5@+%&2%F%B>D=
L#%&=V4M2%I #%#0+c+LM#% BJ#
+M+5<*+0&5+#% %&W5BI2)DBH2%I
*#0&&5k=l?ƒ+%&
#%#%+W&;B>&D7j%-+$B>;+;N+X+)7
+ ( 7-+)F
%&;:2%7-B> +;#% BO()+)5<
A46&%2=*?6+0&* %&o2Fcb%/\208+)$#% B
#6B> C7q&<&72 ^+ =
?6+)#% Bl#)D7jBO *)7&<&7q2N *+ 87%/
#7%%20#5V+)3
$V++ 3=W?6+)8) #%/
#%+1&8G
#;è)è *-+)&<5 %8'&
5)7V+)5
(6%/
%&8+)
~46&+W5#0#% #%&3 %(J#B>5
€5#0#% /
#%&6#%&
%6 BN
( 7$b0 &()M2CfTdleN­ k%20&/
-
5
C)(D%'E)NF
$#6
$#%&& X B`+)C#05B=6fL546/
BH2%k#%5<
7%M#% <&7%7-%8fTdlec ;27,570
)5&Y-+)7W#05B=,P) '
$#0&(6+1]× %'E%Ú .\)Ù
7„#%5<&70D7„%WfIdFe
$#, 2
& &1%/
%&c2%0&< &V:2)5%b)D7„<55& %&A+)85%7%%
46&+, #%#05#0&Z5&
~< 5& %&=
?6+)8#05BF#0D8 $%W2)A+-”$•–C—M˜¨# 3
# IMD
$#5)%L#b&53 J +0&D20=T?6+t# 5­ êê Ÿ%¶%žMK*D6+)fTdle:20&<55&%;5Bk+M# D7
7/
2%&=1A+0&,))A+ D
B> +)-fIdFeW
72%&(C+)
4.
PROOF
C2)
&5-&CAUTOMATION
&& JB> +;2CMECHANISM
5BI %$4.
+705/
(%5)75#0#%&& X B+ D
’#% <$&L)T53'#& J=
SI2)F52)
&5A B^+)D ]#05<0(kX+5I(&
111
¢§Ÿ ² %¥ Õ)¢§%¥% 5¯£%¤¡ Õ¥ å Ø/.é);,();è ± ± ³ ¯IדŸ%¯% kÝ
Û%ž)¢×£¢§ º ՞yŸ ¡9Ú5¥%¦¯ LÝ* ± Ÿ%¥¾IÝ=%¦ ± Ÿ¦ § §%¥IÝ8¢§JæÝR¢§gLÝ-¢§ãLÝ-¢§hIÝ
Ó ¾IÝc¦ ² ¥Ÿ ² ¥)? I ¡¦ ± ŸJÙÙ8ß%ë
× ± ± ³ ¯IדŸ¯% JÝ$Û%ž)¢×ž¦¯¥%՞ Ÿq ¡9Ú¥¦¯% JÝ$ ± Ÿ%¥¾IÝ5%¦ ± Ÿ¦ § §%¥`Ý¢§JæÝ-¢§gLÝR¢§ãLÝ
¢§ hIÝcž)¢Ô%Õ¦ ² ¥æÝ*ž)¢Ô%Õ¦ ² ¥ gLÝ*ž)¢Ô%Õ¦ ² ¥%ãLݞ)¢Ô%Õ¦ ² ¥)h? ¡¦ ± ŸÙÙ
¦¯ ± ± ³ ¯IדŸ%¯% LÝoÛ%ž)¢×“³J¢§Õž ¤¯¡ å ՞ Ÿq ¡ 9Ú¥r¦¯% kÝ* ± Ÿ%¥¾IÝkI %¦ ± Ÿ¦ § §%¥`Ý
ž)¢Ô%Õ¦ ² ¥æÝ$ž)¢Ô%Õ¦ ² ¥ gLÝ*ž)¢Ô%Õ¦ ² ¥%ãLÝ$ž)¢Ô%Õ¦ ² )¥ hIÝFÓ ¾IÝc¦ ² ¥Ÿ ² ¥)? I ¡¦ ± ŸJÙÙÙ
I)I)I
ž¥¯%¦ §%Ô%Õ´)¢¶r ՞¦¯¥%Õ¥ å æ)Ø.é);,();è
,Lמ¦¯¥%՞ Ÿ% l
¡ 9Ú¥¦¯ LÝ* ± Ÿ%¥¾IÝ5%¦ ± Ÿ¦ § §¥IÝ8¢§JæÝ-¢§gLÝR¢§ãLÝ,¢§hIÝ8ž)¢Ô%Õ¦ ² ¥æÝ
ž)¢Ô%Õ¦ ² ¥ gLÝ$ž)¢Ô%Õ¦ ² ¥%ãLÝ*ž)¢Ô%Õ¦ ² ¥)h)? I ¡¦ ± ŸJÙ×OŸ%¯ LݓŸq¦ž ¥Ù
ß%ëQ× ± ± ³ ¯IדŸ¦ž¥LÝ*Û%ž)¢×“³J¢§Õž ¤ ¯%¡ å ՞yŸ ¡l9Ú¥¦¯ LÝ* ± Ÿ%¥¾IÝ5%¦ ± Ÿ¦ § §¥IÝ
ž)¢Ô%Õ¦ ² ¥æÝ$ž)¢Ô%Õ¦ ² ¥ gLÝ*ž)¢Ô%Õ¦ ² ¥%ãLÝ$ž)¢Ô%Õ¦ ² )¥ hIÝFÓ ¾IÝc¦ ² ¥Ÿ ² ¥)? I ¡¦ ± ŸJÙÙ,Ù
·% ¤ ÓÕ´)¢¶% Õ³J¢§%՞ ¤¯¡ å Õ¥ å gL^
Ø .)é ;,();è
× ± ± ³ ¯IדŸ¯% JÝ$Û%ž)¢×ž¦¯¥%՞ Ÿq ¡ 9Ú¥¦¯% JÝ$ ± Ÿ%¥¾I5
Ý %¦ ± Ÿ¦ § §%¥`Ý¢§JæÝ-¢§ gLÝR¢§ãLÝ
¢§ hIÝcž)¢Ô%Õ¦ ² ¥æÝ*ž)¢Ô%Õ¦ ² ¥ gLÝ*ž)¢Ô%Õ¦ ² ¥%ãLݞ)¢Ô%Õ¦ ² )¥ h? I ¡¦ ± ŸÙÙ
¤ § º ,Lמ¦¯¥%՞ Ÿ ¡ 9Ú¥%¦5¯% LÝ$ ± Ÿ%¥¾I
Ý %¦ ± Ÿ¦ § §%¥IÝc¢§JæÝ-¢§ gLÝ-¢§ãLÝ-¢§ hIÝ
ž)¢Ô%Õ¦ ² ¥æÝ$ž)¢Ô%Õ¦ ² ¥ gLÝ*ž)¢Ô%Õ¦ ² ¥%ãLÝ$ž)¢Ô%Õ¦ ² )¥ h)? I ¡¦ ± ŸJÙ×HŸ%¯% kÝ;Ÿ¦ž¥ÙÙ
ß%ë ± ± ³ ¯IדŸ¦ž¥LÝFÛ%ž)¢×“³J¢§Õž ¤ ¯%¡ å ՞Ÿ ¡ 9Ú5¥%¦¯ LÝ* ± Ÿ%¥¾I=
Ý %¦ ± Ÿ¦ § §%¥IÝ
ž)¢Ô%Õ¦ ² ¥æÝ$ž)¢Ô%Õ¦ ² ¥ gLÝ*ž)¢Ô%Õ¦ ² ¥%ãLÝ$ž)¢Ô%Õ¦ ² )¥ hIÝFÓ ¾IÝc¦ ² ¥Ÿ ² )¥ ? I ¡¦ ± ŸJÙÙ
I)I)I
;)E)NV£¢§ º Õ¤¯%¡ å
7>; § º ¦£VÛ)8%Új¯% Ÿ%¯% ž §%¥%¤5¥¢5¦y§j¦£9¤¯%¡ å ¢¥% ¡¥ ² ¯% I
ìCíHîïLðñ"mnóoöðyýyíP6ö;ô3õ9ðñ%üLðñúñ%ÿný%ý5íHþÿ1þl£¢§ º )ðû)fLíHýñûýyïLðyñDT`üðyý$
D #5)7R#% BC#)F5)7,†L_\eqf1b%&FB> 2)*46&+W+
fIdFe$#% B`@+Z &&
F2%& 2&-7n=^MB>
D
$#%&& ,5BL+M# 0(+)fTdle#% B`@+Z^&T%<5Z7
+R+"
70=…erWfIdFe„2-A†L_\eqfE%BO(l
†`_ef„b%&()D % %:2F BID
5)7%6B> ƒ'2& %8fIdFe)()5-;#7-fIdFe,+);+-
70=
£¢§ º D'
$#%&(6+*%´¤¯ ± %´¦¡yÓ3
aŒ>-%+&$+0/
5Z7%<& #78%e #&()+6ÛD%5ÛF
]Œ>;›C& & `e& /
LfL-e
]7%<& #7,%c520#5)5( 7-+)
¯ ² ¢5ž %¦ §%¥¯%¦´6
]Œ>F 7057
7%$#050&D
8T46
&85)5&Y7=
?6+)82%& B 2%85)5&5‡#%%D7„V %&Ww=,?6+)
b%6 2
$,5Bk+F %&;&C+)<5 & 2;
7q2%&C+)646
&YD7n=,?6+5)7A52)
$X)7&Dc46++-
7q2%&
&C &
$#5)% G +0&D20=6?6+)F+%7-52)
$
&L+t2
oNI B%+ D
k+J46I 2
& &$#%5<7=
?6+)*B> 2%+A52)
$X&$+2)
F B^+)D *46&+WÃÅÈ]o
ÈDÌHÑÊ&Çl#% BO$9+
7q2%&=V?ƒ+%&$&&& B> 8&& && BJ+Mp &<)D; BJ520^ #%#0+k=^9+)D Q+)
#0&#% BBM&F&$F#0D
$#7W%W
8+)+/
D
=1P 8'
$#%&(C2)DBH2%;#% Bl+,h6
$#%&
#% BI %&& A52)
&D &&
$#%&F+C+)*_H)D
$#%&/
F 7,_O &#% B^ %&& %;$#%5<7=
C8+)-
-&
(2)DBH2%;#% B B*+,_O
*#0&)
#% B^ %&&5A%< 5&70D$+8h6
$#%&;#% B^ %&5/
& J(k%2)F7%;;5&W
5W+F+8_H)5)&)
#% BL50&&5W+ 2%&7c+ &7=C_>T
55C
5$(%7%#7q
‡+)
70>=6e2@+3T56+)5)7&7c%+)C&5+%+D 2
$k(
46+);466&C+)C2)
F5B6ŒH%<5 &7%7;+ 6+)6 n#%5<5 %&oŒ>D<F%C+)5)7n^ &<8
7%>=L,T5T
50&
%D7,‡+549
%85BI+);#%5< 50&8Œ>+6&(0#/
%&F
$2)6%<5 &7%D7M+ D
6 2
& &#%5<7=
?6+)8b0BO+9+% 2 +.<%+952)
*)8&+<5 &52)3 2
Œ>D&< & V&
$#%& 7(L#b& 9\&
$#%&57(L5
#%$5B6D'&%& ^:2)5%b)MB> 46+% -#% <550&
+ MD 2%&7)ƒNo#%5<73 2
& &=?6+)F#Nb /
& ,\&$D 2
$, &2)7%FM,46+%&@+G+)F#% %&
,52)71%V70b)&)&DR+), 2%,#b& "&50/
2=I?6+)Cb0 J52)
$-&C20F02T&7%%b7-%+)
?6+&70-b%&-&)79%1+#)55(;5)71+3W/
:265B)
5)7%kB> `'2& *%F+TfIdFeM#% B@+Z5=
?6+,´¦¤ º 7%c&703b%&5&79Ÿ%¯£%¦ ³ž £§ž I ´)¢5ž Ÿ(
46+%&@+37%b%)^46F
53†L_efBH2%& T¸ ± ¾¥%¡; 7 ± ¾Ÿ%¯%¦¶% 0=
?6+ ± ¾¥%¡‡BH2%)D& A)2fIdFe--#N@+ZAcb%&=-?6+
± ¾Ÿ%¯%¦¶% BH2%)D& .b08)5&+79#% B#)(
+-2M&$#% <$#b&5k=l?ƒ+F20& * 7
‡;b0&C5&7Ÿ%¯%¦¦£ ž¥%¤¥ ² ž0(D46+0&+&L#0%7852)IL+C)7
5BI+);#% BL#%=
5.
EVALUATION
_HV+0RESULTS
&3& J(C46AND
#%%8
+)D20&8 Bl &Y1
70
D
2)9 2%, #%#%+J=‹?6+)X
Q5&
U B*#BO $/
A+0&-D< 52)& 468W&7%%B>9+B>58+)nN
+52)
50&\„5BT#% BO=?L546 7%;+%&*)7(J+)D'
$/
#%&8
; #N 346&7%c<55&-5BC&2)& =?6+
270-D % />7A5)7W7%5/>)7A&<5&595BC
*# /
% F 5(F% @+%). 79B>7/>)@ZŽ +0&D20 85)7
D
;46&+%%& I02+)ƒD20&C
$#%&
ŒHD&#05B>C <'&%&56:2 %b=
?6+ 2
7W+5
$/>#05<5)5&&+);A5#0#%&7
A2
F, B*D
=E?6+£¢§ º ‘+8.7%/
7+% 2 + 2C+0&^7q&& J=_“I46^@+8B>5T2/
& AM&;&F85)#)2 &W&
*#0&8'
$#0&8+F7%
50/
I
L5B+)6B>D2%L B520^ #%#%+J=6M# kB!
"+
112
q5rs)t)uv
‰‚Œ'x/v
”•p–'—
™nš'›œ
ž•p– ™'Ÿ 3›'¡d¢
”•p–'— 3›'¡¢
¦n§
¡nš]¨3©' 3›d 'œ3š'›
¡nšª – œ3Ÿn›
¨ª'«
¦n§ 3›'¡¢
­ž®p­
­ ª3¯'™'Ÿ°Ÿœ3Ÿ'¡œ'š'›
®]– œ3Ÿ'›'›nš±' 'œ3š›°'Ÿ'¡nš — Ÿ'›
­ ª3¯'™'Ÿ²Ÿ – Ÿ'› œ3š›
­ž®p­ 3›'¡¢
§ ›ª • ™'Ÿ § š – œ3›š'¯
´dµ ™œ3Ÿ]¨ ´ œ' 'œ3Ÿ
§ ° ´
§n¶3´
§ ›ª • ™'Ÿ § š – œ3›š'¯ ›'¡¢
wrnx/yz
{1`aŽ
wr'x/y
wr'x/y
wr'x/y
{1`aŽ
wr'x/y
wr'x/y
wr'x/y
wr'x/y
{1`aŽ
wr'x/y
wr'x/y
wr'x/y
wr'x/y
{1`aŽ
wr'x/y
wr'x/y
wr'x/y
wr'x/y
{1`aŽ
{1t)|`r}
x/Œn|ˆv]s
˜
˜
£
¤
˜
˜
˜
˜
£
˜
£
£
£
˜
˜
˜
˜
˜
¥
~rn€}
ˆ‡)uv
˜
˜
˜
¥
˜
˜
˜
˜
¬
˜
¤
˜
˜
³
˜
˜
˜
˜
³
{‚p|]ƒ
„|€uv
„yv]'ƒ
„|€3uv
£
…†‡ˆ|]ƒ
‘‚t)Œ'’|pƒ
‰1r'|
~l`r“ƒ
£
£
Št)‹
£
¥
£
¥
£
£
£
e‚DWHñAò0ó^·‡ñúyïOýDúþV)üLüQ¸Jí>ÿkî")ïkýDþK%ýñù"üLðþþþW>íHîD%ý5íHþÿkúFýþM¹)ð5íHþïkúúº¸núDýñú
»'» ­'¼3´ ›'Ÿd©3›'Ÿ'™'Ÿ – œ 'œ
'» » Ÿ – œ • œ µ”•p–'—
” •p–'—3½ 3›'¡¢S¾ ´ œ3š'›'ŸÀ¿
§ šº¨3©3š – Ÿ
É'Â ² ®pÊ
B
$46&+WB>D7qZW&+2)85B6& 5‡%,
$/
#5)%=GP) 6#%D& C#%20#(63
™46&+18& C&C&
$& lF+)6
FD
E)) 2#02C$
$# %*+);B>7%F+
< 52)DoZW8+ &5)5
$# %37q2%)V+)-'8&<5&5#N&7n=Q?6+B>5(
46&+&5I F50CF 2
& &, &YD7n=
• š – š ” 3›'¡d¢ • œ3Ÿ'¡dœ'ª3›Ÿ ”•p–n—3½ 3›'¡d¢kš ”
¶'Á'­'ÂnÃlÄ Ÿ]¨3©nœ µ ¿ ´ œ3š'›'Ÿ Ä
– œl¿ ¶'Á'­'ÂnÃ'Å ¿ n¶ Æ'Â3ÇÈ'Á
®pË'­3ÇÈn¶)®pÊ ²$ÌdÍ3™©'Î ¦ ›'¡¢ • œ3Ÿ¡œ'ª'›'Ÿ¾ ´ œdšn›'Ÿ Ä Ÿ]¨3©'œ µlÄ[§ š]¨©3š – Ÿ – œ Å
?6+),D&< & Q\&W
$#%&579#%& -A2&5$5&R+)
#% <550&\5BF+#05B>=9„+V2)A %5/“D7/
<5&5k(k&FD
F53703 ,)72)D&<#% BC5<
lD Bl+),
».5703&7%%B>9+-D‡
46+0&+MD
$#5)%L *I&<5D7n=I?6+)I<5 &7&* B+)L#%/
5)7&& W&F+@Zr7-, ^2)+,&<D/
= 4M,+$+)
+ 7n(I46+)W2),70 />)7A&<5& J(C+)$#%/\5)7&& 5W8<b7V7qD&BH
™+8&<5&595)7&& J(65)7
$& 2
%&=
'» Ï'» Ï'Ï ­ š'›œ™$š ” œn¢3Ÿ ƞ• ±'¢3Ÿ'›BÐ3ŸÍŸ'¯ § š]¨3©3š – Ÿ – œ
•p–)Ñ ¿B¾ ´ œ3šn›'Ÿ$ÒnÓ •p– œ3Ÿ±Ÿ'› Å
•p–3Ô ¿B¾ ´ œ3šn›'Ÿ$ÒnÓ •p– œ3Ÿ±Ÿ'› Å
•p–'Õ ¿B¾ ´ œ3šn›'Ÿ$ÒnÓ •p– œ3Ÿ±Ÿ'› Å
•p–'Ö ¿B¾ ´ œ3šn›'Ÿ$ÒnÓ •p– œ3Ÿ±Ÿ'› Å
× Ÿ µ ¿B¾ ´ œ3šn›'Ÿ$ÒnÓ •p– œ3Ÿ±Ÿ'› Å
šª'œ'©'ªnœl¿5¾ ´ œš'›'Ÿ_Ò'Ó •p– œ3Ÿd±3Ÿ'› Å
™ •±
™ •±
™ •±
™ •±
½ šdª'œ
½ šdª'œ
½ šdª'œ
½ šdª'œ
Ñ ¿5¾
Ô 5
¿ ¾
Õ ¿5¾
Ö ¿5¾
´ œ3š'›'ŸBÒ'Ó
´ œ3š'›'ŸBÒ'Ó
´ œ3š'›'ŸBÒ'Ó
´ œ3š'›'ŸBÒ'Ó
•p–
p• –
p• –
p• –
œ3Ÿd±3Ÿ'›
œ3Ÿd±3Ÿ'›
œ3Ÿd±3Ÿ'›
œ3Ÿd±3Ÿ'›
Å
Å
Å
?6+)F+%7cBO5;+C'C+F
$#%&'&\- Bk#% BOM&C+)
#b)& X&*
$#%&57%8+M2#BOc+;2/
7%b07, # ;XfIdFe)=e#b&5$2)XÆÅÎ%ÈÇ5ÄÏ ÉÍ>ÌHÏ5Ç
pÇ Ú͓Ç5Î0ÈDÌHÅÎ5-
,
)50&XW 2
71#% B>38+)
#% <-D  2
& &"D'#)5)79&<5 %-
(;46+
+C#Nb&5,&TD:20F'#%&&C%7q2& ,5B/
<5 %C'&
;%8+;#05BL#0D=
Å
'» Ï'» Ï'Ï ¼ 3› •  '¯ Ÿ'™kª3™'Ÿ K
— •p– 'œ ¢3Ÿnš'›'Ÿ]¨Ø™= –n— '« • š]¨)™
©3›'Ÿ Ä ©3š'™œ Ä –nµ ¿ ¼n'¦ È!´ 3œ š'›nŸ
ìCíHîïLð!
ñ Ùnó‡ö ðyýyíPCö;ô3õðñ%üLðñúñ%ÿnýº0ý5íHþÿ9þ*£¢§ º ) ðû)fLíR
ýDñûý5ïLðñDT6üðý-ò
?6+)*b0 IB>D F&F+$#0D)Dc5B6D'&%& :2 %bo
+W+)D U#% <7=‹C#0D%(*+),&R152)
7
+ %&
#%5<&70X D$)5%&&,'&%&5
:2 %b=6?6+B>5(46+%&C+)6D
%&I &54A2@+#% BO
MN6
2 &*#B>5
7(+)DF %)tN6 2
7=Tp54ƒ/
<5( C BJ+ƒ4V)5)DTo&
*#0&
%7B>5I+)CfIdFe
+ ‹#%5<F&* &
D7W;DB>),+%&$7%b&=3?ƒ+%&
(* WBH2%&i&
$#%&
%7n(*&-'#D7"Wb07.20&/
%&; %&&5)ŒH3
TDtB`+)D'&=I?6+0&C 46520&7W5&54E 2
7#% BO$3
%,
*#05BC %&5/
& ;+ ,20%&8#%&=
D
=
?6+- BO 2%
9B> 8+8nD8+)-#05<5 %&95B
73+)D =I?6+;
M&50b5%; B`+)DMB> 6&
+22%8 B+)3 +0&D20=W†n58 +0&D20Dc5
+D&8#BO »52)
D71 &&=ŽST @+%W /
+%&2%c-+)-
$#%&'&V BF79+5
5)7,:2037%7q&&5)5C#05B;#)(L2+AF#05B6%,(
3
;=L?6+M
6
$#%&82)2%M&IB>7)@Z(
46+%&@+X+);&$5;&
*#)$5%&&
F20&H51#% B>=‡eq/
D
F46&+B>D7qZ,:207q2&5„#% BO(L46+0&+k(A+
D(D %)tC52)
7=I?6+)B> (r
I4ƒ&+
BO7)@Z,50;N 2
& &X &Y7=*Q#&56
6.
_OV+%SUMMARY
&846 Z(^46#0AND
%715CONCLUSIONS
9 #%#%+9-2)A+ #% <;B>5k52)
&^ &&I B (
*# %/>)7(
113
7%&5)=_“C%<5&<7A+o2$5B6\4687qN%F& 2D(L +C&;cB>5+)F7%& F846&F#b& $k(5)7
5)+);,46+0&+,&ƒ&3$#% <$+5
=6P F5)
7%&5)(+)”$•–C—M˜°#b)& 3& 2F4^L2)7(%46+0&
+,fTdle1+)5
a#05<-46c27iBO 8#05<1#05#&
5 2;+F7%& J=
?6+4^ />& 2 #%#0+W&7A+)*46&)-5B6+
D
%&C5Bk+C#b& -& 2;3+)C+ Q#05</
$&5)52)F 75)&)8#Db)D& ;%*+)6
50/
&D=LW2)
F` B%%M#% #&DT)&6C
$#N %/
D7+)570465/>Z8
C46;&70%b7=;?6+* &Y
+$%BO 7R%D %)D& 8 Bƒ X +0&D2034ƒ&+
D##b)& J=*e)F%B>F5)7%D %)/
&5)^466&70%b)73I+)C520DT5Bk
I L3
7%&5- 7$&
$#%&
%& J(+C46C'#D78;+)5<C+
T&
$#D=6?k &&5-&C$5& +%B>546 7#%(4ƒ&+
5)8fIdFe+5R)W7,B> +V”$•–C—C˜ %&=
?6+;<5 &52)C&52)D; 76'&
C4ƒ&+%-+;+/
5=I?6+);#% BI50&& FB> C+F &&F5BL%B>;5)7
% %)D& 646&+0‡+)I
7%)5T7*L+5
46&+%W+F+ =
?6+cb%)5C#)5c5B 2%5#0#%@+V%<5&<7.+)3& 95B
#% B#3
$#* 2
7W#05B>$-+87
+5
=A?6+)#% Bl#)467V&
o2%& 52)&
46&+,+F& X BI+ =6?6+);#% B^#C
Zro2
5B)#546B!20)#% BJ
k#%5<&70D7c%*+)6fIdFeF#05Bk+@Zr
C
5Z*+);#% B>C)&=
4M2%C
D+)7% &846I<5 2D746&+3+)5 B&7%%B>
+I 7q&&5)I2070L46+0&+*&n&L J&nJ]&<=IP) 2%L
7q/
&M4^;5)5&Y72)5205#0#%@+3¸+/Û¢§ º 7%>()+
*%´¤¯ ± %´¦¡ Ó
7%>(I+)D
Û %5Ûc
70ƒ 7+5
¯ ² ¢5ž %¦ §%¥¯¦´
70>=.Š-c5BF+#05<5 %&,+)5
8463+)5469,
52)
&D &„#%5<7,2)+)7W#% BC#=-
2
F BJB>5Cn D)+F 2
%&-5BL+;#05B>
4^8 &&7%%b7n=V?6+)Dc2)7%-2203 Bl+)8 +%/
D20(&<5&5V&(J#b& V&5)7#%5B
D'&%& ^:2)5%b)=
_H95)2)&5k(* 2%3 #%#0+"X+)#% %&
&#%
$&0=
?6+M2;5BL+ E#%5<)*B>&;5#0#% #%&F+ 7q
5B65)& X720-+)*5&-70&5W(46+%&+$520/
&5,
ZrC+0& #%#0+,&-5#0#%&50&6
= 4M2%62)F5B
7%&5W5)& X 7-
I+5
;
ZDM520l #%#0+
%&=
7.
¿&wÀ^Ü 2)REFERENCES
7%-hT54F(Ü +%-m62)+ %(s;5 [{ Xe+)50Z 5(5)7
Š- 705 jer&<5=lÝßÞà%͓ÅÄÌHÉÊáÎ)Í>ÄÅ')à%Æ5͓Ì!ÅÎÍ>Åkâã=)em_
_O%&5)5>(LŠ-%&8fL Z(h6*(DÜ 2%wzzrxq=ft%7
C9_>PL?F­ zrxq=
¿ ÂyÀoh;=)$=%mF=)p5=hƒ
F20%&-:2%& L#%D=
äLÅË*=
Ë à%Î)ÌHÆÉÍ>ÌHÅÎ0ÈCaÅ åFÍ&Ð)V
Ç Ýkälæ(Âw€Œ çr] vvv ž¸ XX(Lw)z X'ç0=
¿ u Àl;
$&<Z
‹mC [\Z+)546%=)d;#N$D %;
700(
<5 2&5A 7-<b& J=kŠ-5­ C+&(ÁM%&<&
B^hT0>(Iwzzz%=
¿ | ÀlmC 8dTD
o2%>()mC
~Š- 7% (5)73dM [53Š-7q2%>=
fLB>5
*
70)82)fI›;†I[= äLÅË6là à0Í>Ç5Ä(
 z%Œ>|] || ¸qx u%(M#%6wzzv%=
114
A Component Oriented Notation for Behavioral
Specification and Validation
Isabelle Ryl and Mireille Clerbout and Arnaud Bailly
L.I.F.L. CNRS UPRESA 8022
Bât M3, Cité Scientifique
59655 Villeneuve d’Ascq cedex
France
! "#
Jp@9*K(^
RA9B
23
0_M_*sL0
23
&%'
()@%'
A9M0*
(0^()
&
GV4(%'*Fp@9*B*s[&()[B*[00
**
0bM
&B/"e%'*KQ3
$ im[n@owJ‘n~ f $ iRjc
ABSTRACT
$ %'&(
()+*"#-,./
10
23
&%'
()4*50
6(
7(8:9;9
(<0=(>9
?*"#,@
4
(;(
AB(;56
B0CED,@
2
F()
;GH
(;I%'&(
()*J,K9G9'9
L&M0
@0)
*@(F9<23
L%'&B
A
())/23
N(
*
*O9
P*QR";
(;L(
AS&
0T*"UV,@
9<2MBXWMK0
23
B&(;K%'&(
()*Y"#!
*
Z)[9G0MH\&<-
()
;G*L*KIG9<B
(;(;]G*Q'9<K(
T(^%_Q3
*
L"
9
[
9<2MB@"C9
*
L*"#-,./
T%'&(
()*Z*F&
*
_*&
H
6
0C
p@9
w,@
H\QM(,K(502()G;
*T"@_%'&(
()
()
0?&H
&G94
T9
"eB,K(;+t
( 9*]&<&
F,F
b(MM0
^c*&
6(:B(;<;
4%]H
` a
&
%'
()(;d9
()
"e
R0
6<(B(?B(;;
`VfRg!h &&*
0
)?iRj4k7l0
*AB
$ imnFo $ %'&(
(MKj^M0
Y%'&B()
%'&(
()*?p@9*d*&
6</(=B(;<;
_*I*
0c(q%]H
%I(B(r9B*sut=9
+*
v)
(
5"w*
2B
5
23
(M*_H
%'
A9M0qB*Z
(E"[%'
9M0E*F
2
()*X
S
&(*Rx
9R)
05*(
l9
l*s*s
%y9*R
(c*sG/
0C ` dB,K*
*JdG9<G
z
L9
K"e((<
92@"!%'&(
(M*Z)
,@]"Y(M2B()*.tX(lB()
"e
L(M2/U()J*&
6<
*J(MG
AV,@
(]%'&(
()N9X&/2MB0
*PZ(<0I
G9l"*ZB
()*
,K9
*d{%'&(
()(M2/B()T(*sGB()*9
w,K9
]%]H
%I(B(c
V,F
(q(
'%'&(
(MR(<0cF*d
()*w(<0
*
A23
*}|q
5&&*
E=&)
0
c*
0r(~9*^(G(
"#.;
(
AG(;w*&
6<(H-*
0'
*sF*
*@0&
0ld(
*sB(;4(0E0B***d9,^*
]9*R(G(E"#w2B0(
&&*
*
’~“ †A”Mˆ•–—Œ —e‡˜ $ %'&(
()*T/
lAQM*_9<T
l/2B
"#0
*;(
*
ƒ]•—e…‡\•—e…•–—Œ —e‡˜_.€((<
*(4
w00
0^T%'M0H
6
0w™V*sL){B(*B(;l
*&(*
d%'&(
()*
’
—#…‡-† “ ‚G„† “ •3–—Œ ‡˜ $ %'&(
()*J%'&B
%'
()B(;RR;23
(_*&
AH
6(>(q
_*
G9
0=%'(;*sw
S*s(;4%'&(
(M*
šY
0^){2*L&/2B0
*.(^9
$ iTpKWY›%_Q
pNd
G9_9
*
L;*9
[*&
6</B(^"N%'&(
()*F9<*J
K&
B*
K
(;9ldB,~*
G9(;)
*s(;d(0l%'&*(;
%'&(
(M*],K9A9r/
4&
()B:0
*;(
0C@B%'&
%'
()
0C
()
;G/
0CL(<01*
0:)a0šY
(M{&
&
œp@9
4%'
A
b
S*sH
(
["Od%_Q
F*
"O0
&
(0*J('9
L(60
(
L&/2MB0
*
(0q(*%'
*w%_q&w(>9
'"e((@
(
**]"[
&M0
` (w $ %'&(
()JW"UV,@
] žž/Ÿ $ %'
(*ZWz&
*Q)d&&*
*
9
@"#,KB(;]0
6<((]"Y%'&(
()*tO3o¡WM"UV,./
K%'&H
(
(MX*JT(Z"Y%'&*(l,K9'()GA<]*&
6<
0l(H
"e
*(0^
S&L()
SM[0
&
(<0
(
*K()Foœ*"#-,./
%'&(
(MJ({
[0
&)
0](<0
&
(<0
()](<0'*F*M™s
F
%'&*(r)>9G0:&</
* 1p@9*^0
6<((~
%'&9*z
*
9
'*
'".,F
F*&
6
0q(M
A"
*w+0
*
'%'&(
(M*
*
_9
{(M
A"
*]9<23
'+
_9
_(qB(QE
-,@
(a
%'&(
(MT(0+*R
H ,@B05 w*T
()*d(<04
(M2M(H
%'
()
1.
INTRODUCTION
p@9
L0
23
B&%'
()X"Y%'&(
()X<*
0'&&(*F*Z
5(
**V="e_*"UV,./
4(<0*s=(:4,@B01"B;
4*
0*sB
0l&&B(*F€9
A%'
9
.;,.9'"NT%_/H
Q
P"
*
@%'&(
(M*9
Z"%'*TZ‚ƒ„‚…†A…‡ˆL‚s‰KŠ\‡#‹†Š
ˆs‹†Œ 'x $ iTpKWlxI*
%'*Jd
L9
K(],@]R
0
[&M0H
(a*s*](a+0%_(>,K9
{(*sG()=
23B2M(;4
G9(H
;?A9
GQ*.&M02-)PŽ
2
9
**9*L&&G9b%_Q3
*
*
(*
+"R%'&(
()*_/
49;9HVv)V1(0a
B:%'&*sH
i(
T,@?'
?*&
"#^B()
"e
**Ll*
R*&
6w(H
"e
J0
*AB&(dB(;<;
*BQ
X9
JiRj4k[H `-fRg "# $ im[n@o
M™s
*{(<0=9
?(
,¢iRj4k[H `-fRgNh "e $ imnFo $ %'&(
(M
j^M0
%'&B(){%'&(
()* `VfTg V&B~0
6<(
*_(H
GA*l
-,@
(>%'&(
()*w*(;+%'
9M0q*;(<
*c£(H
"e(
`VfRg ()G*d
'%'*s+*s()GAB](<0c0?(
&
R9
R*
%_()d*&
A*["Z9
R()GKp@9*L
0*L
(0
H\*&
6
0c%'&(
()*w(<0c
Q*R9
'B(U@()
&H
G-:;3 œoL*?(:
S%'&
F,F
4(:%'
()B(a9
^,@Q
"Ti*%_(
?WM: žM¤ŸK,K95*9,@
0=9</l6<2
?0šY
()]%'&
H
%'
()G(*Z"Y9
$ iRWl
23
(MZ*
2M
L) $ im[n@o:"#G%'
,@Q
¤
115
’
&/2B0
*T,@
'(
9
d()
H\&
AG
'(d**sG
]
H
*
I"F023
;(;{B()
&
G(*T"J9
]iRj4k[H `VfTg *&
6H
(C
Ž
T9</KB()
(C%'
9M0_B*
R(K(*B0
0?9
p@9
?G
b"R+(((;+%'&(
()J*s*s
%®]*H\*s*s
%
*R9
]*
v)
(
l"KBX9
I
23
()*R(M232M(;?R9d)
0
*(
+*^A
(C}p@9
+&&*
+"R9
+*&
6</(¡*{
&
b9
4*
?"w[&**
5%'%I(/(1G
*{"w
;23
(b*s*s
%bZŽ
T9L]L"P,@QM*L0
*L,K9^9
TG
((¡(œ0šY
()^()
SM*E§e"#b
AS%'&
$ W¯y¤°/Ÿ TG
9
5 ±Ÿ N¨A
(;59
^B*s{"#
,¥)
/*@9
?(M
A
*s_(1"e%_K*"UV,@
f 0
23
&%'
()[9<*[;,K(5*s
0B)o[&&3A9
**
04(+"#H
%_P%'
9M0*T&/2MB0
d9
l02()G;
*R".?&
*
'(<0+((H
%lB;*'*&
6(rB(;;
+,K9:c"e%_L*
%_()
oL(<0Y.
23
(1"T"e%_L&)"#*^/
4?"T9
{*&
."e%_
2
6</B(b*[&**
d(0^;
(
G?*&&
0?)_)*
oL"U
l*9()M0(^]9
$.$ j²*sG[%'M0
N(<0
V` fTgNh XW
(>žb0
*AB
*Iw*&
6<(=B(;;
5W
AH
( h M;23
*Z*%'
KB0
*F"Y2BB0({AB2M
*@(<0]&&*
*
?,@+^
*sd%'&(
()*_oK"#
w^*9R
2M
,}"F
B
0
,@QM*,@
R(B0
,K9b*%'
R&**
R"e9
.,FQ
W "U,.
+v)V>*9B0>
(
6]"#%¦"e%_K%'
9M0>*
0
M
%'&(
()L0
2
&%'
(M.l2/*K*sG;
*t
¤Kw"#%_C*&
6(^U(;<;
R9<*@l
[G9^
(;9?
S&
**.9
"eB!*
%_()*."X%'&(
()*
ž).&,@
"#M)*X9<23
J[
.
FG9
GQT9
J(**s
(w"
*&
6<(*P*(;{"eI
AS%'&
dV&
H\A9
GQ(;ID;9
23
X&&
*d%l*sT
l2
6<
0YtTd%_4
]&**B
]
()Y9@w%'&(
()F
*&
A@9
L()G*@"N*F
H
v)
0^
(M2M(%'
())]()C9K9
T%'&B
%'
()G(
"dc%'&(
()]("#%'*'E*'*&
6(r(0a9</
((
A
0^%'&(
(M*K/
R%'&
2.
HOW TO SPECIFY COMPONENTS?
o[*?
0r*B0CL,@
+BB0~&(~9
$ im[n@o $ %'&(
(M
%'M0
.|E
dB(**s
04(b9
R"e[9<L9
d*&
6(5B0
(
*
^9
{
BB-1"[9
^%'&(
()]/'*
23
G.*sG;
*
(E*R"e
_p@9
"#
!9
l*&
6</B(q;9)R{
]&
*
(M
23
A^%'
d%';9)
w(
0
04(<0b9*[
S&B(*[TG9
" `-fRgNh *KL;(<0{U(;<;
` KšY
A*L-,@'02()G;
*t
¤ `-fRgNh 0M^
AS*s*B*K*
0^){*
23
GC)B*(<0{*[
%]H
00
0?(^9
%'&(
().&GQ;
p ["e6<9*O
v)
%'
()*/,@
@&&*
F(A
*
@9
@*&
H
!
6({&,F
F"NiRj4k[H `-fRgNh "U%9
LiRj4k $ imn@o $ %]H
&(
()]j^M0
[§ $.$ j4¨d,K9="e%_F*&
6</B(*cp@9*w(H
A
*
05*&
6<(5,KBP"eB,9
w%'&(
(M[9;9+*
"e
AH-AB
I(0?,KO*
23
d*IŒ —e…)©”•[ “ •…ª•'"eRC9
dA*.x
0
*;(
**
*Kx__0
*
R9
R
92"P9
d%'&H
(
()+|q
{(c"e)*](a0
*(;4"e((<K*&
*l(<0
0+(l00
**I((H "e((Z
v)
%'
()*wBQ3
{v)<-q"
*
A2
d[/23
AGC
BB-)
žM@9
`VfRg!h U(;<;
?()G(*IF9
_(
**=*s()G
0
6<(B(*@"P%'&(
(M*F(0{()
"
*.9</.(?
[
SMH
&
0?"#L"e%_!*&
6</B(4&&*
*
` (aG0
_c
*&
'9
`-fRgNh *s()GSYF,F
l™s*s?(*
_*%'
"e%_X&&
*T"@%'&(
(M** `-fRgNh %'%'
()*dp@9</
,.)<9
d*&
6</(5B*[
%l
00
0^(+9
d&<GQ;
0b%'&H
(
(MT(050_(TB()
"#
I,K9+
S*s(;_)*IpN?
(;9)
(
w%'
9M0;)O,@
',K@0
23
&q(q9
]
%_(<0
d".9*
wl*%_BC
S%'&
tZ(?
(w[*s*s
%b
p!b*O?%'&(
(MTB*w^BGQ5S+9</dšY
*R*
A2
*O
H
v)
*P[*&
6
0d
(M2(%'
()(0w(w
%'OP
23
@*s(H
G9(*l
23
()* ` (M
A"
*]/
^*
(a*]()G*]
-,@
(
-,@=%'&(
()*{(rq%'
+&GABT&B(){"w2M
,«*
%'%l(/B(EG9<((
B*_§Q3
]9
l
23
()dG9<((
*G¨T
-,@
(
%'&(
()*bo¬*s*s
%­B*d9
(qb*
w"K%'&(
()*R,K9A9
/
?((
0E4
G9=9
Al)cB()
"e
*](0q
23
()wG9<(H
(
*M(0I,@
."#)*Z('%'%l((*P
-,@
(l%'&(
()*
i@*&
6(?B(;;
T/,K*.*Jd
S&
**FV,FwQM(<0*F"
&&
-)[p@9
d6*sT(
w*[9
d((+"J&)Y9</*
*q9
_&<B.G0
A](q,K9G9>9
_B(&](<0q&l%]H
%I(B(*T9<23
w^)
0C]p@9
]*
(05(
]*T9
]0G
2
O l9
l&**BV5^*&
"#5&&
*R(59
l2
"Z(?B(&KL&K&G%'
³[´Cµ¶5·P¸#¹ºe»N¼\½<¾¶cµ¸4¿·Z¹À3ºBÁXÀµÂº#½»JÃ¦Ä •3ªG‹¡Å‚‡-† “ ”ˆ†Aˆc•…
†ŒB†ª‡ “ ‚…— ª?—e…<Ɨeŗ Ɣ•ŒC„‚Œ#Œ —e…M©+Æ)†Aŗ ªG†_‡#‹•‡dª‚ƒlƒI”M…— ª•‡-†Aˆ]ÇX—e‡#‹
•>ªG†A…‡ “ •ŒT‚sÈ1ªA†bÇO‹M— ªG‹ “ † ©—eˆ‡-† “ ˆ4‡#‹†+ł‡-†AˆÉ¥Ê‚qˆ—eƒ„<Œ — A˜E‡#‹†
Ç “ —#‡—e…M©ËXÇF†Z̔Mˆ‡.ª‚…ˆ— Æ)† “ • “ †e† “ †A…<ƔMƒÍ•…Æ'ˆA‚ƒ_† “ ”ŒB†AˆÎ
ł‡-† “ I
ˆ • “ †I•ŒeŒ‚Ç@†Æ]‡\‚{ł‡-†I•‡Jƒ'‚ˆ‡K‚…<ªG†AË
’
ł‡-† “ ˆ_• “ †?•ŒeŒ‚ÇF†Æ^‡\‚
‚ņ “ Ë
’
‡#‹†5ªG†A…‡ “ •ŒT•ªGªG†-„<‡ˆ^ł‡-†Aˆb”M…‡—Œ.‡#‹†+ªŒ‚ˆ” “ †AË]‡#‹†A…
‡#‹†AƒlË
’
‡#‹†EªG†A…‡ “ •Œ “ †eA”Mˆ†Aˆ4‡\‚4„ “ ‚Å—Æ)†{„• “ ‡— •Œ “ †Aˆ”Œ ‡ˆ5–A†e‚ “ †5‡#‹†
ªŒ‚ˆG” “ †AË
’
‡#‹†lªG†A…‡ “ • ŒNƒl”Mˆ‡.•……‚”M…<ªA†d‡#‹†Iª‚ “G“ †ª‡ “ †Aˆ”Œ ‡ˆIÏeÏeÏ
p l%'
J9
*
[
v)
%'
()*3,F
T&&*
Rd*&
6<(bB(H
!
;<;
d<*
0^(?%'%I(B({G
*
’
p 9
K<*L
23
()*X"Y9
.*s*s
%,F
[(*B0
@/
.9
K%'
**;
*
@
%'&(
()*d
SA9(;
P,K9G9>
_*&&*
0E4
_(*sG()GH
(
*L(<0?*s(G9(*t
’
%'
9M0{*L
V,F
(b()
"
*L"P%'&(
()*
’
(?"X%'
9M0{*
’
S
&B(*K
-,@
(^%'&(
()*
’
23
()K*
(0(;
’
23
().
2(;
“ †•3Æb‡#‹† “ †Aˆ”Œ ‡ˆlÇP‹†A…=‡#‹†{–•Œ#Œ‚‡[—#ˆ
“ †#Ì/†ª‡ˆ
p@9
'6*sI**
AB(q&
*
()*w9
];
(
G $.$ jÐ%'M0
O9
*
(<0](
L
I()M0
*Z9
`VfRg!h *s()G/SCOp@9
LB*sJ(
&
*
()*L."#%_*%¢(^9
T
S%'&
2.1
Model
pN4"e%_>*&
"#q*"#-,./
b%'&(
()*P,F
{6*s]9<23
'
;
d({9
R0
6<((b"XI%'&(
()O|E
{B(?9*.*H
* (^]&
*
().9
R*sGA[%'M0
,@
R*
9</KB*K&L"
9
$.$ jÑ%'M0
E|q
?
d™s*s_4
?]%'
{
*s23
ž
116
('()
"e
Ä ŒB†ª‡ “ ‚…— ª ł‡-†X9J,K*F9
.23
ZR*
(<0l9*
23
b_;
_9
?
** ³¸#¹À¾½<»OºeÀ áX½´ %'&(
()*'
0*s
0a(<0>((
0=59
œþ‚‡-† J†A…‡-† “ ()
"
4"
Ýw¹»Y¹M¾ %'&(
()]9_
()GBz
*?("#%_/B(! Ýw¹»!ÿ
¹M¾ › *R%_(4
]*{(M23
*!d*^šY
A*d(5B()
"e
þ‚‡-† Kƃl—e…E*
0aE*
49
b<B7|~9
(a9
b{*
*
0C9
Ýw¹»Y¹M¾ *
(<0*X(l
23
()O("e% ((
0w%]H
&(
()*!"9
X*
F(0G(*%'*Y9
%r
**Xp@9
Z
23
()
*(QM*" ³[¸#¹À¾/½»Oº#À áX½´ %'&(
()*/
l((
0b'9
23
(M@*
R" Ýd¹»Y¹M¾ tP9
T
23
()*@*
().2MBI9*.*
,K
T
B2
0?)?N((
0{%'&(
()*
9(+9
$.$ jÓÒ $.$ j®%'&(
(M*[%_4*&&R()
"
*
(<04%'&(
(M*L%_b%'%l(
T,K959
T%'&(
()*
*B0
?9
{*&
b"T()
"
*t?9*]*'(',@
01B(a
%'M0
N,K9
lX9
d%'&(
()*L%l*s0
B
l&*l§()
H
"e
*G¨L(<0^%'%l(
L9;9{9
*
R&*K()
ÔA»C¹¾/¼\µ<À¹¿ /
]*
05)+0
23
&
A*R*T%'&B
%'
()G(+(H
G*"#d%'&(
(M*[(05)^B
(M*[?()
GAT,K9c%]H
&(
()*LL()%'
` (M
A"
I0
6<(B(b(MG(*[
*
(<0E%'
A9M0+*B;(</
*w(0E%_+
'0
A6<(
0c*(;b%l&B
(9
G(
Eo[(=()
"
{;&*lbxc9&
"#=9
()dx
*
A_"R%'
9M0*]&/2B0B(;E*%'
b*
2M
*_(0CKG0(;E
9
((
({%'
G9<(*%¬"N9
$.$ jy%'M0
M.
%'
*F
%'%l(/B(4A9((
N"#d0G'
SG9<(;
w
V,F
(5%'&H
(
()*
o À½¶c·X½»N¹»C 0
6((+;&*T
*R(04&*wo@H
*5
=&&
*5"_%'&(
()*4*
cc0
&%'
(M
%'
@"#@(6;G('&&*
Zo.
*X%'**
.%_wG*
AS
&(*J¯O*K%'
R({"eK23*t
Electronic_Vote
Electronic_box
Closure
Center
•3ªG†A‡ˆ./
@()
"
*X&/2MB0
0d)T9
J%'&(
()X(<0d*s(H
A9(*?*
0{){9
T
()*
’
Vote_Center
Vote_Admin
’1“ †ªG†-„<‡\•3ªŒB†AˆE
+()
"
*{*
0:)a9
4%'&(
()_B(~
*s(G9(*L%'M0
’
†AņA…‡_ˆ—e…Õˆ5/
c()
"e
*4&/2B0
0~)19
c%'&(
()
(0b*s(G9(*{*
0^)'9
RB
(M*
’
†AņA…‡PˆA‚” “ ªG†AˆL/
.B()
"e
*J*
0I)d9
@%'&(
()P('(
*s(G9(*K%'M0
CÜN¹^¹´Cµ¶5·P¸#¹5¶c½N¹¸-Ã
ØKº#ÙÚ!¾¹
2.2
IDL3 short presentation
p@9
liRj4k `-fRgNh B(;;
l
SM
(0* `VfRg
žI,K9+*%'
w*s()GAH
(*s*FdGQ3
L(MI(MF9
$ imn@o $ %'&(
(M
*sGL%'M0
Zp@9*K*
(b*9CB()M0
`-fRgNh (
&*
2()ZRJ
S%'&
K(<0]*JMI(R%'
('"#0
*&(
"J9
$ imn@o $ %'&(
()Rj^M0
l|E
I
"#
R9
w
0
T
¤/ןN"e%'
R0
AG*[L9
$.$ jc
¯O*T/
l*
040
&B%'
()K%'
I(<0^(M%'
T_((
%'&(
()*I;
9
=oLG0(;++9*l%'M0
J+%'&H
(
()l%_c
?*
(a*](=
%'
()I"[4*s*s
%Ö9IšY
*l
(_"<*
2MB
*X(<0
P9
@**%'&(I9J(9
XH
AB(_"C*
2M
*ZB*F2BB
Zp@9*F&&3A9'%_Q3
*X%'&H
(
()X
SA9(;
@
*
ZŽ
J9<X%'&(
()*P%_d
K0
6(
0
*(;T*(;
.B(9
G(
T§(lT‘32L*sV
/¨AX€O;
T¤@*9/,K*P9
0B;G%ѧ 0MG,K(c"#%Н¤×/Ÿ#¨w*
05b
&
*
()I^%'&(
()
(<0^*K&*
Facets
..
.
..
.
Receptacles
..
.
Event
Source
o¬&d"F9
l*s()G/S+B*d(9
05"U% `-fRg ž) f U/G(*
_;9
A
0q(q%'M0B
*d9I0
B%'I40%_(q(<%'
` (H
"e
*T0
B/
l/B
*[(0b%'
9M0* ` ()
"e
*[%_^
0
A6<(
0:*(;=%I&
4(9
G(
f U/G(*b/
c(r
(0
I&G%]H
$ ‘/2R*sV
)%'
9M0*X%_l923
<
*{"d*%'&B
4-&
*5§
<!G¨A%'&
S'-&
*T§
Y
!A¨w
M™s
^-&
*}j^
9M0*^%_:*=9,«
AS
&(*?,K9BG9
%__
d0
6(
0{)'9
R*
A
' (()"
Component
Event
Sink
..
.
!" $#" %&
+*, -((/. 10!"2
€O;
h *9,K*L9
`VfRg!h 0
6((*L"X[
AS%'&
› *K(M
AH
"
*?p@9
l%'M0
b*sG*d)50
A6<((;?"ed
S
&(*
§ ({
S
&({%_]()G({6<
B0*G¨X"e,@
0?M]B()
"e
d0
6H
((*
*N9
JB()
"e
J*
0d)T9
Z23
*
wšY
*RV,F^%'
9M0*N(
Ib23
](<05(
]?
0c9
l
AH
**Ep@9
_6*sI(
?9*I(>(H\&</G%'
w,K9G9q
&
*
()*
9
'2
'"K9
'23
4§
b"#])
*+(<0
4"eI(3¨
(0:^%_>9, V,F=
S
&(*t
="d*%'
M0M
*d423
{"U
w9
'*
^(<0
c"K*%'
AH
M0d
*XT23
FV,K
Zp@9
.%'
9M0
9<*X-,@
H\&<G%'
*
*&
23
+
((;_9
l(M%l
"@)
*
(04(_23
*["Z9
d<BRp@9B*%'
9M0b%_^*{9,
(c
S
&B(c,K9
(c*
0c
A"e
]9
l*
4§e9
I
**d
([/2B
/¨A.p@9
RB()
"e
*
?(<0
I"
*d"F9
!9
4
l
*&
23
5*
0+)b9
'%'&(
()*.(0?){(40%'(*sG/Zp@9
c%'
9M0qB*I*
0q4G(*%'l9
_
A› *'23
_49
43!)
5*().!. 3)
ØKº#ÙÚ!¾¹=Û<ÜwÝw½Y¶c·X½»N¹»YÂÃ
6(!)
o ¿Þ!¿Â¹¶ *d_*
R"F%'&(
()*wp@9
l
()R*
R"@(H
( (*I
AV,@
(q%'&(
(M*T
&
*
()*R9
'*s*s
%b› *d(H
6;G(C¡€O;
5ž+&
*
(M*'_&&*
01%'M0
@"e_9
B
(B=2
q
S%'&
ÍpF,@:-&
*ß4"l%'&(
()*4/
*
0C(
K"#Z9
.23
*X
(;w
()Gà'
Ýw¹»C¹¾ 3(<0
(
L"eF9
LB(02MB0<<&(;I0
2M
* ³[¸#¹À¾/½»OºeÀ áX½´ Zo[(
³[¸#¹À¾/½»Oº#À áX½´ %'&(
()L*[*
0^)^
G9b23
A<šY
*
*().!. ' @
<!)
ßâãäYå æAçVè.ãGéê ëæçìAí/îYìPïã@ðãAñCæïïä\ìê êñ\òìNëä ãóå ìôqãGéõ ïìðñ\õ öçæAñ\õ ãAð.ãAé
÷ Aã ñ\ìä êNî!òõ ç-òRçæðTóìJê ãå ÷ ìïTøê õ ðùKæKçå æAê\ê õ çæAåMúå ãAùõ ðûAëæê êîYãä ïú[ëä ãAñ\ãAü
çãAåBý
h
117
?#))(
87!"(9)
! (")
:"()";(2 <!);
=)"; )!9!9
3) #))(
>3) 0;,-&
GB
E(0¡(
5
23
()^*B(Q¥ZG97&M0(;>4(*%'(;
23
(M&R*&
6<
*d_V&
I"@
2
()t
2
()*T
l*B%'&42H
AV&
*'§e9</R*R^*5M™s
*w)+2
/¨[9d(9
R"#%
9
1()
"
` (:_
S%'&B
@
*
T
23
(MJ9<*FV,F]/B
*J
(M0(;w
**@"!9
<H
'"eL()K"X)
*'(<0
'"eL(M
t
"d(œp@9M*K(~
23
()_9*{E%'
((;c"d*_/,K(8§9
(<0B(;{<B› **
¨[%_4*^/42
*I§9
**K"P9
T23
/¨A
()
C
(*T_)
(c(<0/(;{"Z9
I23
w9<*T
(
GQ3
(cB()^()dd(_§(E*
'"@*
]"#d
S%'&
/¨A
p@9
%'
9M0
l,K*K({0%'(*sGFw*
[9
[H
_(0E9,K*'(>
S
&(>"[
0M>*
0Y $ %'%'
()*
/
d
V,F
(
l(0
l ](<0{
(<0{"X(
.(9)
BACC DC(A $AA
q#n,G!)9Xvv*<) ' "9)
w2)!9 ,P)(
,E;(()F3)¡
)(@.)G(H!( ")MJI
)(@.)G(K")";2 <!)(;MI
)(@.)G(K")";2 .(9);7JI
)(@.)G(L .(9)(;œJI
)((7!".)F*)!.!/. 3)¡
<!;L<!)NMOQP(()"R..)/S
"9)!9TMU! ")5VD"()";(2 <!)(;1SJI
<!;L)"; )!9!9NMWHF2)!9XV
LF!S
"9)!9TMY .(9);1SJI
ACC
<!"("
MYZI [(\(/9X]Y<!)^M S`_\ba1S
cd M!e [\(/(9^]Y<!)5M SfFES
gg
MYZI [(\(/9X]Y<!)[")";2 <!)(; d _\faES
cd M [(\(/9X]Y<!)^M SfQ1S
gg
MM [\(/9^]<!)[! ") d _
[\/9^]Y)"; )!9&9NM V SS-IYKQa1S cd
!A[\h_\TM [\(/9^]<!)[! ") d _
[\(9^]Y)"; )!9!9iM V SS(SC
C(A
I
)((7!".)F3) #))(œ
P(()"H<)`MO&QP)"j..)/SJI
I
)((7!".)F3) 0;&,-8
<!;K.(9)5MkS:!"9)!9NMW"()";(2 .(9)(;1SJI
AC(C
<!"("
MYZI [(\(/9X]W.(9)5MkSl_\faES cd
Me [\(/9^]m.(9)^MkSH&FES
C(A
I
]]]mAAQ/9)((Q!)()H.n,G)L;)!."!"!(/9
JI
ØKº#ÙÚN¾/¹C
o ÜdÔA»C¹M¾/¼\µ<À¹8Cp ·X¹À3ºUÁXÀµÂº#½<»O¿Ã
i(
^(~(
^9?L&*_"RE%'&(
()_/
4(<%'
0
(059d^%'&(
()R%_4šY
Ad*
23
GJ&*R"@9
]*%'
V&
?p@9
4§ 0
HV¨V((
(E&
G(*I
'
2()d"A*I(
9
Z%'&(
(M!"e
9
T(*B*sOB(R9
F**B;(%'
()N"
3
"UH
(
*'
&G
*d(0+*
*T"Z9
d%'&(
(M $ (H
(
(1(<0=0
((
(a&
G/B(*'/
^%'&]%'
A9M0*
"Z()?%'&(
()
2.3
Specification language presentation
|q
_9/2
'&
2M*E
S&
**
0qI;*F(<0q*B0E9<w,@
*
`-fRgNh *LK%'&(
()*›0
6((bB(;;
` K*L(,
%'
I40
*
l9
l"e%_X*&
6<(qB(;;
'B(*
0
*F%'%'
()*XoL*F*U0_
/B
,@
[('"#)*§ .
*sLF9*
*sG;
I"ZL,@Q¨K(b9
T"e((<O*&
["Z%'&(
()*
%'(;I'(*s,@
Kl9
*
dv)
*s(*Rt
$x
’
D[,7]0
*
dl%'&(
()› *.
9<2M
’
D[,œ_*
G(49</[-,@'%'&(
()*[/
I()
G9<(;
AH
]—\Ée†J9
{šY
K9
T*%'
R*
2M
*
’
D[,«a
5*
59^*
23
GR%'&(
()*{(¡
5(H
(
0
yx
1x
o~*s*s
%}
2323
*J"#% *FA
(_d*@0
*s(_)l,@
"@%'&(
()*T()
GAB(*]p@9*!9
]*sG/
b".?*s*s
%
§%'&(
()A¨.%_b
d*
(c*L9
d
*T"F*[&<*s(M
AH
AB(*F,K9{*@
(M2M(%'
()PW)9
[*&
6</B(?B(;;
,@
[*
[B*F<*
0_({9
[(
&."N%'%l(/B('9B*s
p@9*{B0
=%'
*'"#%Ñ(:M™s
^
()
0:"#%_[(G(
0
23
&
0^i*]£(B2
*VYtFi£Ž}§\i*B'£[(23
*-?Ž[G/H
(<¨¤ /Ÿ &z
p@9
[%'%I(B(_9*s'"Ow*s*s
%¬B*@w*
v)
(
L"NH
* 2B
J
23
()*J§ .G
/¨C9!
G0*PM%'%l((*!
AH
V,F
(b%'&(
()*.9<K)
0b*(
T9
R*s*s
%¥9*L
(
*sG
0C^p@9
'((q"K*
2
4
23
()I0
&
(0*R(E9
2M
,K&()K,@
R(*B0
t
’
*
2
@
23
()*P"*s*s
% /
.M9
@%'%l(/B(*
AV,@
(>%'&(
()*^§%'
A9M0EB*J
(*l"%'
9M0
*
23
()*
S
&(*G¨A
’
*
2
]
23
()*T"K?%'&(
()R/
l9
]
23
()*"@9
*s*s
%Ð9</^(r
+*
(="#% 9
52M
,K&B()^"d9
%'&(
())9</@*Fw*{Y9
[%'%l(/B(*Z,K9*
*
(<0
A[K
23
L*.9
T%'&(
()
’
*
2
23
(M*J"O({B()
"e
["Ow%'&(
().
L9
%'%l(/B(*IB(M232(;59
?%'&(
()l9;9>9*
()
"e
B.(n,!G!)
@oL*
$ %'&(
()*K
R()M0
0?)'9
Q3
M,@G0
0Mb*B0Y<%'&(
(M*K%_{()GB(b
*(<0{&*
0
6<(B(*W
23
G!Q3
M,@G0*[, *K{0*s(;*9+0šY
H
(M]Q(0*'"&*t
E(0
+"e{"e
A*?(<0=
H
&G
*
d"#@
23
()F*(Q*F(0
d
*&
23
{"e Š ‡\‚Š …_ Š ‡\‚Š R
23
(M@*
*
E.(/9,1)!9
?s
?t
#))(
qG!<;)!9 f/9)9
rG(P9&!)!9 )&,-9
4s ms
€O;
* c(0a×4%'&
{]
S%'&
› *]0
6<((! $ %]H
& (
()
+9<*d-,@^"e
A*](0c(
Š ‡\‚Š …c
23
()d*
,K9B
w%'&(
(M
_9*L(
R"e
Y(
R
&H
*)!.!/. P@
> ,P!)(
us
{
³ ¹»Y¿ "w9
+*s*s
% 5*&&*
0~=
5B(*sG()G(
*
9
A?%_'"eN()l"eL/
;B
*t
t
118
.(n,G!)H#))(œ
G!<;)!9f3!) #())(F<|I
G!<;)!9f3!) 0(;,-R"XI
GP!9!)9F#9)R.XI
ACC
<"("
MYZI [\"5]m.(9)^MkSl_\baES cd M!e [\"5]m.(9)^MkSQQES
gg MYZI [\"5]m.(9)[")";2 .(9)(; d _\fa1S cd M [\"^]W.(9)5MkSQQES
gg MYZI [\<Z]<!)5M vY(!)S}_\faES cd M!e/9(\ d .5~@|VU2(€&QES
gg MYZI [\<Z]<!)5M vY7!"9)/S}_\faES cd MU/9(\ d .5~@|VU2(€&QES
gg MYZI [\"5]m.(9)^MkSl_\baES cd MY-EIU(/9\ d .5~@5VU2‚_\b g(g @ c )!95MY--VU((!)/S gg 2 c )!9|MY--VY7!"9)SS
7(.(9
)!9hv„ƒ!".)5V…P(()"K\ d |I
)!9|Mm)&,G2|V Sb\ V
)!9|MYZI [\<Z]Y<!)5d‡MU@1† SJVY@1SF\ d )!9&|MY|VU@1Sfˆ1-V
)!9|MYZI V@1Sf\ d )!9|MYES]
C(A
I
u‰!ÜIÝw½Y¶c·X½»!¹»Y #())( Ã
ØKº#Ù<ÚN¾/¹
Šr‹ 6§ ŠŒKtŽV¨k c§k’ ‘ ¨T0
(
*w^F".%'
9M0u²,K9E9
&B
K"N&G%'
A
F2
*’ ‘ (B
0_)I%'&(
()“
Š 
*@T%'
9M0l""e
”N
Ž "!%'&(
()wŠ Œ XZ2
()*J
(;(;
¤
o ¾/µ<À¹ "I=%'&(
()5§e
*&C =*s*s
%{¨]*b=*
v)
(
"d
23
()*'"R9B*'%'&(
()› *5§e
*&!7*s*s
%{¨]&9
{(
,K9G9E_
%'(</B(cd
S
&B(c
23
()
*&(<0*b_&<*s
(B(>
2
()^Ž[
_9<I*s(A9(*d
2
()*w923
_(
*&(0(;'
%'(</(*Ki(
R%_?9(Q{"ZlG
l*
*
v)
(
T"P
23
(M*F"XI((B(;I*s*s
% ;*s
0^({9
TH
0
AO9
w&&
/
0I*(
J9
@*sGP"<9
J*s*s
%8(MM(]H
GI*
2('(*sG() $ )39
.*s*s
%}%_d(]"#
A
9
I*
2/(5xb{G
]0)
*R(T
&
*
()R%'&
l
AS
AH
B(?x{(<0^*
2(^%_{)[[(){%'
[x{IG
› *
&
A6S{*[*_IG
l9*K/
;4
T
A%'
0{(B/B(4
23
()*
Š–•Ñ§6ŠŒ!tŽ-¨k E§k— ‘ t ˜)¨@0
(
*K(%_]
(^"P]&
2MH
*N
23
(M9
X&<G%'
!2
*
— ‘ %_T
Z0šY
A
()!"U%`’ ‘
*(
]d(<04(R&G%'
A
T%'M0
*R
l,@
0Y]p@9
&B(<dt“+
˜ 2
?0
(
*]&**
^
(a2
?"[9
ž)
%'
9M0Y?Z23
(M*d
(;(;bb9*d
;q
'
%'
0
%'(</B(b
23
(M*
h
Šr• 6§ ŠŒKtŽ-¨k š™œ›ž}0
(
*d
A%'B((c"K?%'
9M0
X)4(5
AS
&(u3
› p@9*
I
23
()*[
w
%'
0b
S
&H
oÍ*s*s
% B
%'
()› *'*&
6</B(¡0
*AB
*{*_
9/2M{(
%'*b"'&**B
=%'%l(/B(rG
*­oÖ%'&(
()› *
*&
6(c*T
S&
**
0c*d(+(2B(MT(+G
*l§B(+6*s
G0
JB;/¨AJp@9*Z(2B(MZG9</G
z
*.T**
Z"!<&*sH
*
RG
*[/23
.9
R%'&(
()› *L&9
L9
(
&(;
9*K%'&(
(M› *.*
%_()B
(b
2
()*
t
Š–‹®)§6Š ß t Ÿ ß ¨k nnn §6Šn¡{t!Ÿ&¡¨)¢’ ‘ Ÿ0
(
*@(_*s(G9(*
%'
**;
(d
23
(MC*
()!)%'&(
()XP
Š .*(QM*5Ÿ ß nnnn kŸ&¡
"%'&(
()*Š &nn WŠ ¡ *&
23
T,K9R&
Z"2
*
’ ‘ Zp@9*
d
23
()*Kß T
A%'
0^*s(A9(*.
23
()*
J{
o[( ºe» µ¾º#µ<»Y %_q
400
0>E
A9~()
"e
4_%'&H
(
(M ` ("#%_B)!I*w{6*swG0
AR"e%IB?,K9E2B
*
(*sG()*3"#((*3&
0B
*J(0l(*sG()*Z,K9*
K%'M0H
*L
R9
2BB0?G
*K"N9
R%'&(
(M
Ž Z9<!,@
J0L(OG9<G
z
./
*O(0'§ 0
HV¨V((
H
[
(?
2
()*tN,@
[(*B0
@
*@*@&<*F"C*
;
K%'
9H
M0*L(<0c§ 0
HV¨V((
(^
23
()*K*K%'
9M0?B*
|
id&&*
'B*db(M2(
]9
l
0
Al".
S&
**23
(
**w"
*G9w.(G/(I(<0R(NL0
G39
X*s()GJ*;3/OPšY
*
*l,F
R;23
d(^U0
l"P9
T(G(b(^9
T
S%'&
p@9
[*
A@"C&**B
23
(M*Z"Y9
L*s*s
%}*FB
0'9
µ¸#· Nµÿ
§I0
&
(0*T(q()
"
*w(0E%'&H
áX¹MÂ4½<¼w N¹a¿Þ!¿Â¹¶
(
()*I%'&*(;b9
_*s*s
%{¨A^|q
_(>0
6(
'(q9
_*%'
,@_&9
*Z"e.2/*J
%'
()*Z"Y9
L*s*s
%}0
&
(0(;
(^,K9</K9
{(b*
23
&
J{
Ô»Y¹M¾/¼-µÀ¹>ºe» µ¾º#µ<»Y¿ (5T
S%'&
I
I*9,K(c(c€O;
h ` (^K%'M0
(M
A"
RB(M2B()*L
R*
(b* Š\‡\‚Š R(H
GA*@*c9
=*&
"U>%'%I(B(*l
-,@
(1+%'&H
(
(M?%'&
%'
()(;c9
5B()
"e
&
*
()
0r)19
cQ3
AH
,@G0
M(<0](
["C*J
()*)
&
*
(M
0_)w9
K*s%l
,K9A9I0
(
*X()R2
@(d9
F
*&(<0(;T0%_({§9
9
d*
"J%'&(
()*G¨ALp@9B*0)
*([(9B(
H H\%_(M
%'%l((?*A9
%'
*tF]%'&(
()K%__
23
d%'
9M0
B*"U%Í0šY
()[
()*9;94(
d"J*()
"
*[
|
p 9
µ¸#· NµáX¹Â{½<¼Tµ>À½Y¶c·X½»N¹»Y *[9
d**
AT"Z
2
()*["
@
9
R*s*s
% ,K9*
R
23
L[*
(<0
A[*.9*K%'&(
(M
5
n
r(/9
-
p 9
µ<¸#· NµáX¹MÂ>½<¼^µ8À½Y¶c·X½»N¹»YÂa¿¹¹»  N¾/½ÚNÙ ¥µ<»¥º#»!ÿ
@
¹¾/¼\µ<À¹ *w9
{**
A]"L9
{%'&(
(Ml&9<
A](MG(H
(;c
2
()*I9</'/
^(B(CF
%'((a'
AS
&(>"
%'
A9M0?*0
6<(
0{(^9*L()
"e
×
119
4s Us
.(n,G!!)Q*!()!./. ' @
G<;)9f*()!.(!/. 3)Q)^I
/9)!9b3) .))(L<|I
.(/9,1)9F#9)R.XI
AC(C
<!"("
MY|I [\()5]Y<!)^MU@1Sl_\ba1S MU/9(\ <Z]Y<!)5MU@1SJIY(/9([(\<Z]Y<!)5Mm@ZvY(!)/SR\w_4€S
gg MY|I [\()5]Y<!)[! ") d cd_\baES cd d M \ d .^~ V LQES
gg MY|I [\()5]Y)"; )!99XMU@|VY21Sl_\fajS cd M \ d .5~@5VU2KQ1S
gg MY|I [\()5]Y)"; )!99([ .(9); d _\ba1S cd M!e \ d .^~ V HFES(S
C(A
I
£CÜIÝw½¶c·X½»N¹»C *()!.(!/. ' @ Ã
ØKº#ÙÚN¾/¹
9
b(M2/U()_"T9
b(M
A"
4*&
6<
*'9
b%'%I(B(
&
(',K9{
G9?B
() $ ()*.
[(<0
&
(<0
()J"U% A9
9
*@9M*F9
[()GAL0
B/
0?({
G9^()
"
T%I*s@
(H
*
J9P
()*O(I*
F*%'
F*
2M
*N,K9
2
P9
P
()*
%_50_€d
S%'&B
!"K{6<
]%l*sT
]&
(
0c)5?
()
A"e
{
(;?
0YZ^
()I"#/,K(;59B*RB
_%I*sd(w
/šY
01Ma(9
_
()_B(;c5
019*]6<
b,K9
&
((;]
*()!.!/(. 3)
0
B0
({9
[()
"e
tZd
().((.&
0@"N(9
A
()L9<*K*
0^9
T2
T
"#
d9%b
` (=9B*l
S%'&
X,F
b0+('*&
Q>](B/B(:
2
()*t
9
F%'&(
()O%'&B
%'
()B(;L9
F()
"
.*X(P
*&(*B
"e@(&J
23
()*F%_l(]
(*
L*J,K(_&* ` (&*
23
(M*!
J"U
(d*
0TK*&
"#T*
23
G)*(*O"9
XQM(<0Yt
"NRB
(MF*
(<0*F%'
.9*J
23
()J
"e
L9B*J(
L9
(]9*J,K
9<&&
(5
l()
"e
Jp@9
*s%]H
g .*@6*sK0
G9
q0
(
*I9
_9*s)X9</]*I+*>4*B(a49
"#%IBFp@9*K(2B(ML*Ll(™s((=§ 0
(
0{M
¨@"
9
d%'&(*Lp@9
R6*s[(
d**K9</]2
d
(<0*[H
c"FTB*T9
I6*sR(
tR"._*
v)
(
b§ 0
(
04M ¨T"
dG
_(0_9
[
%'(</({"X
l*Kw&
6S4§ 0
(
0
)
3¨L"Z9
d9*sb9
( ?0)
*([(MG(c()^
%'(</H
(E"
E§ E0
(
*9
l(
;3(=(0
40
(
*T*d
"ew"e3¨A]p@9
l*
(<05&</R"J9
wB(M2B()d0
*
*T9
(M23
*
L*<(!tZR23
L
(0*ZMl
S
&B(
".w*R(R9
l6*sd(
_p@9
]9G0+&</I00M
**
*w(9
&B
%btT23
*d
'
&
0c
A"e
I9
lB*
_(<04
**
/
K2BB
K"U
X9
FB*
Zp@9
@*
.%_d)Z/Z()
%'
)9
[B
()."N9
[()
"
T((.0
@@
S
&F"N9
23
*l
+
S
&(=w9
'
**5p@9B*I&</l"
9
.(2B(MZ**P9<Z()l& d"9
@9*sw"eB,K(;I(
AS
&(
'(^
*&(*
R_l23
Rl§ 0
(
0?) \¨
{
%'(<(c"
MP(5()G(*d
*&(*
*d
%'
A9M0+*R9<R
'
S
&(*
bR
A%'B((*
"
'§
d0
(
*X9
.&/™s
( K()T
%'(</H
(4(0?
S
&(b
2
()*.(¨A
¤a
€_¥\
%<!) e
q
=<!)
¦
…")";2 <!)(;
q! (")
Z
ž! (" )
§)"; )!99
$! (")
”)"; )!9!9 A[(\
-¨
3!) #())(
J{
Ýw½Y¶5·Z½<»N¹»CÂLºe» µ¾º#µ<»Y¿ "eB,K*X*%'
Z*s()GST9(wB()
"e
(M2/U()*K?E%'&(
(){B(M2B(){*&
6
*{9
b,K9B
%'%l((&<
A(R
V,F
(T9*C%'&(
()!(0R39
%'&(
(M*MB
()*@.*
23
A*tZ@9B*F*sG;
@B*F&**
*&
"U59
]()
2(;^"F*R%'%I(/(*[,K9c*
23
G
9
O%'&(
()*Op@9
ZG
Z*
O"<.%'&(
(MC*O0
*
0
)5*d,K(q(M2/B()w(059
lB(M2B()*d"F9
'()
"
*d
&/2MB0
*
g g
KI
­?¹)ÁX»Nº#º#½»ZÃB®m@¾/µ<À¹E¿¹M¯%° †A‡.”MˆdÆ3†A…‚‡-†]–˜4±”²'‡#‹†l•Œ „‹•3–G†A‡
‚s_•+ª‚ƒ„‚…†A…‡”+
Š •…Æ…³ ß nnn y³ ¡ —e‡ˆ@•3ªG†A‡ˆÉaÊ!‹†]—e…Å• “ — •…‡ˆ
‚s[‡#‹†wª‚ƒ[„‚…Y†A…‡@•…<Æl‡#‹†—e…‡-† “ •3ªG†AˆT• “ † “ †Aˆ „†ª‡—eņŒ ˜{Æ)†A…<‚‡-†Æ
–˜?´“ k´ &nnn O´ ¡ É^Ê!‹†A…Ë.‡#‹†l‡ “ •3ªG†lˆ†A‡‚Vw‡#‹†'ª‚ƒ„‚…Y†A…‡“?
Š —#ˆ
Æ)†+X
µ …Y†Æ^ß –˜3Î
n¶¤·D±²4¸ ¹ F´ §+¶ ¨Xº?»-Žw+· 3¤( &nn& mO¼ U»-Š Œ ’ ´5G½ §+¶W¾(³½¾Š Œ ¨
ÇO‹† “ †–ŠK
Œ Æ)†A…<‚‡-†Aˆw•…‚‡#‹† “ ª‚ƒ[„‚…Y†A…‡K•…<Ƨ¶W¾(³½U¾Š.Œ ‡#‹†K„ “ ‚VÌ/†ªŠ
‡— ‚…:‚s§b
¶ ‚ņ “ ‡#‹†4†AņA…‡ˆ{‡#‹•‡I• “ †bª‚ƒIƒl”M…— ª•‡—‚…ˆ_‡#‹ “ ‚”©/‹
‡#‹†F•3ªG†A‡Z³[
½ ÇX—e‡#‹rŠksŒ É
Š *K9
*
K"N,FG0*L0
6<(
0
` ({9
.,@G0*9
LG
T*
AK"|L
(Q±”{
² 9'*/*s"#a9
b(M2/B()'"%bŠ (0>9
^(M2/B()_"
A9]"e
J"@
Š ,K9l
*&
JdT&™V
(_/23
Z%'%l(H
(*!,K9d(9
AO%'&(
(MY9;9T9*Y"
k
¨ OŽ
P9<
K_
ž3) ";,E
{(<0
{9<23
R*%'&
[*&
H
` ()
"
*
6(*_p@9
'*R(^(M2B()R(c9
l6*sT(
'*(
l9
A
*K(_(
%'
9M0],K9*
R*
0)
*K(K0
&
(<0_(?()M9(;
*
2
.B(I9*P(M
A"
P|q
@B0l923
@*B0I9J*X*)(
*T9
d
(+2
w9<*T
(
!T
%_(*
^()
9
'
(<01§e9
'23
{*w*
0¨dR9
{*
w*w"U
'4*&
"#
&&
*[[(["X9
A?*
%Í(K'
R*
A"eKp@9
dB(M2H
()]"
^™V*s]**I9l4*
{&
AG(a
(<0*
(%_B^"Z[B*L9
R6*s[(
t@[*(&**
w_*
w9
dV,K
]p@9
](2B(MR0)
*R(R*&
"Uq/T,K9</d&()
9
l
S
&(
b%_4)d
*
]d*R(
D7!"(9)
$7!"9)
9
A
L*JR*
L0šY
(
K
-,@
(I9
L&9
› *F0
6((
(0{9
T(G(?*
0YtZ*K*)(4*.V,@l%'&(
()*./
R(H
(
0C9
.
&G
[()G(*J9
.
"#
(
["Y9
LB()
"e
"J9
]9
T%'&(
()C*^d%_4
l*
0E0
)Ip@9*
,@
I*
w9
w(G/(
](*s
0+"
,K9
(a9
?
&GB
c" +B*l((
0a+9
?"e
A 5"
A]W%'B)Y,@
l0^(d0
(
I9
l
()T%'&(
(MTM
w@)'9
L(<%'
"!9
[&.(M2323
0_(_9
[%'%I(H
/B(!!9*d,K*w*T^
*c0B*s(;*9q%'%l(/B(*
(b0šY
()K&*
=3) 0;,E
.XÀ
(/(9
¦")";2 .(9)(;
¨©!òìPëä ãyª ìçsñ-õ ãð@ãGéæZñ\ä\æAçì|«ãðñ\ãFæFê\ìsñCãGéMì ÷ ìðñ\ê¬5çæAð[ó3ìNê\ììðKæAêCñ\òì
ãAë3ìä æAñ\õ ãAð[ñ\òæGñOïìå ìsñ\ìê!õ ð%«!æAå å)ñ\òìZì ÷ ìðñ\êYñ-òæAñNïãKðãAñNó3ìå ãðùFñ\ã¬Fý
Á
120
¦.(\ d Z]¢,”MO@-¿ S
B ….
=.\ d MO.XÀvW!S]+,“MO@¿ S
ž
t
#))(
%l*s.
R%lH 9
0
0CMKL%'M0
Y*&&*K
€O;
l;23
*.9
T*&
6</B(b"N9
'%'&(
()
(™V((>"K6<2
{%'&B/(*cp@9
_6*s'(<0E9
_*
(<0
(
*K*_9</.9
TL%_?
*
0b/K%'*sK(
9
H
,K*
L(
d
S
&B(]*Z9,K(!Xp@9B*X(M2/B()
0šY
*["U%
?()
"
*›Y(M2/U()
*
w"X9
&**
I(*sG()B(*["X%l
*s%I tJ(^9
R%'&(
()
(M2B()[%_?
&
*
()T(M?9
T%'&(
()L
G9b%'
&&
*Kp@9M*K,F
d(4*{9<]
()L(;_9
%'
A9M0l
B2
*.(_
S
&(_"!9
L
A%'B(('"NB*
9*
0ME)
0YO,K9G9
23
AIB
()d9*R
23
0c9*R
%'H
((Ccp@9
_V,@b"#,KB(;E%'&/B(*I*E9<I23
*l/
&
0I,K9B
.9
.B*
K9<*X(Z
('(((
0l(0I9</
9
l
.
V™s
0b§e
(]2
)¨J*J*)(_*Z9
.*
*l(((
0Ycp@9
{U*s]%'&/B(>B*l4B
{]0šY
()
*(
.*
*.R"e((CZp@9
L
I&<w"C9
[*&
H
6({*F(_SBBl&</J9F/,K*@9
.*
Jd0
6(
.*
,K(w"e((*O"eZ*&
6(l&&*
*P()Pp@9
.0
A6<((
"L?"e((q%l*sR*sGw)+9
](%'
]"@9
]"#(AB(!O(<0
9
[&G%'
.(<0]
({2
L-&
*Xp@9
L"e((_*
"O*
0
6<(
0?(4'¯P;{*s-B
R){*
23
AGNU*
*tZ9
RU*
R9</
,KC
T*
0_*.A9*
({)_(6(?(?9
[9
0*@"PB*
*
(+9
wG0
T9
A+
l0
B/
0CdŽ[
d9<["e((*R0{(
923
_*U0
?
AšY
*w(=G
*ll2
*w&<**
0qb9
%b5p@9
_"e((4U/
*9
T
*["X9
R23
R(+lG
"K9
'%'&(
(MtIIGQ3
*dV,F4&<G%'
*Z^G
{(<0E
)
(=(<04R
(*T(M%I
"@23
*9d&&
/R(59
G
',K9E9
')B
(>*w&</G%'
Ad2B
` "@9
]G
'*
%'&V)!9
'
*l*]°^,K9G9
2
l)
(a2
_*l;23
(>*
(& ` "P9
RG
w
(0*)^'23
R
%'(</(4
23
(ML,K9*
&G%'
@*Z9
K)
({,K9BG9'*F
()]()
0C9
.
H
*XB*P9
J"e((]&&
0wL9
@
;((B(;"<9
ZG
.&B*
(
` "F9
lG
'
(<0*dMc(M59
w
23
(MC9*d
23
(Mw0)
*
(IšY
d9
l
* g d*R
(c^9
]B*sw&</w"@9
(M2B() ` "K?*
_
23
()d*
0*O9
(q(q*s(G9(*
23
()@9*F
(_*
()F,K9?2
* I(0 w9</@/
[9
L
**@"!9
L23
Xp@9*.
S%'&
L*9,K*.9,r&,@
"#*F9
*&
6</B(EB(;;
tR*T&**B
I?0
*
w,K9
(+B*
]
S
&(=)Il*44&
*
=B
^&G%'
H
A*›<2
*
r")";2 .(9)(;
l3) 0;,-
3.
V&V ACTIVITIES
o[*d*U0q(59
'()M0AB(!Pw&/™s
]%'*I/w&/2MU0(;
)*]5
S&I9
^*&
6</B(:/_0šY
(Ml*sG;
*'"L9
%'&(
(M› *d"e
5o¬"#%_F*&
6(>&2MB0
*Ib*s(;
*((;c**I50
F,K9=9
_*s*s
%b› *I&&
*Ep@9
*&
6(>*]@9
'%'
_*
"e.*l%_
05)*'
&/2MB0
0Y |q
+&&*
+>*
49
+*&
6(¡"e40šY
AH
()I&&*
*t'+2U0
{9
_*&
6<(CJ+
(*
_9<
9
R%'&(
()K*L("#%'(;]I9
R*&
6(4)_,.?"
*s(;5%'
9M0*XcG9
AQ59
{%'&*Va(<0q9
{*H
*sG-E".%'&(
(M*I|q
]
AS&*
'(c9*d*
(E9
0šY
(MXB0
*
%'&9*z(;L9
F
*sZ&9<*
J,K9A9I*X9
@%'*s
02(
0?&</L"O9
,@QY
.(9)
7!"9)
(7(.(9
3.1
pC·X¹À3ºUÁXValidation
ÀµÂº#½<»QÂRµ<¸eº+!µÂº#½<»JÃ
p@9
L6*s.*s
&{*@l
(*
L9<
9
[*&
6<(?**s6<
*@9
*
› *F
v)
%'
()*Xo¡*&
6H
/B({,.
(_)ld*
@*J(F*s*s
%_B'2B0'(0'%_
(MG(*.V,F]QMB(0*."X
*t
)!9
’
0
*;(b
A*K9<K%_{
0{](0
.*&
6</B(!
?Ã
pNI00
**@9B*F&
%b),@
[
(
6F"U% 9
[,@Q'(B
0
(ai*b"eI9
{i£[Ž (G(r¤ Ÿ 5Z23
(=".9
'V,@4(G/H
(*]
{(]
SE9
_*%'
5§e9
?
{M™s
*I(:i£[Ž
(0]%'&(
()*Z('F(G(_(<0'F*F*s()GAB'%'
*s23
/¨K9
l*l(
&*R/
l23
A4*
]*_,@
l(5*
9
*%'
R&&G9!Jp@9
*(b0&
0{(4i£Ž7*.]*
9
w)*dšY
0c)b9
]¯ TW4)BQM_¤±M Ÿ td¯ RW4&/2MB0
*
§ %'(;I9
A.9(;*G¨Kw%'M0
H\G9
GQ3
K(<0?l&,@
"#Y9
H
%Í&/23
dp@9
l&B/-+"J9
w&/23
B*T{B,9
*
AP(0
@&)"*sG/
;
*Z0&
0w[*X,K(l&B
%'*t
9*T(
*
*T9
I%_(+"J9
I&)"e*Ip@9
IB0
{*
0
A6<(
?9
^*
%_()*_"wi£[ŽÍ(~¯ RW>(:G0
'=0
*
R9
I¯ RW?)*9
R,@Q^"L¤ h ŸX%_^
w0&
0^_
(G(C
z
¤*()!.!/(. ' @
wÄ
p@9
."e%"C9
.*&
6<('"C9
w%'&H
( ()*T2
b*%'BT'9
d&
2MB*[(
,@
l(+0
GN9
6*sL&<K"P9
T(™V((b(^,K9BG9^9
T%'&(
(M*K/
(M23B2
0C ` @**F9</@23
*›MG9
*K
'G(*%'H
0'd9
L
()
tO
G9'
%'(<({
23
()@"N23
[*@%'%'
0H
/
_&
0
04§ N*F
0{*F*KR*à]S'"e3¨FB(_9
KG
)
()
› *l%'
9M0
5(B(>
23
(M?§s—\Ée†É423
/¨R,K9q9
*%'
2
["!9
L23
](0{%_/A9(;R
%'(</B({,K9_
H
(b2
Lp@9M*<9
R23
d9<*[
(bG(*%'
0b(0C
*(
l9
I9
I
23
()*R/
](*
B2
!,F
](q0
0
I9</
9
R*K(
TG(*%'**(^"#L
A9b2
§()
A**(;]9
dB(;;
w(
&*[9[%_{
04'(H
(**s
(
†É ©)ÉX({
%'&-lG
*
KKdG
T*
@(
B*
0b(0
K&
6SY
( G0
.I0
.*G9{
*2B0(?)*.%I*s@
[&H
` _
2MB0
0b_A9
GQ^9
w*&
6<(C $ )Y9
w;
(
GP&H
%¥"P9
R2U0(^"X*&
6(*[*L(0
B0
R*'()
)C,@
R&2MB0
[,KB!(L
T%'&
?%_/
”@ >2
\w_
8<!)
’
ZÄ
@
@¹¿Âºe»NÙ!Ã
Á ZÄ
ZÄ
oL*{*)(¡*{9
4*&
6(¡*/B*s6
*{*
› *?
AH
v %'
()*<9
d&
%«*[{G(5(+%'&
%'
()G/B(4"
)
9
%'&(
()F9K("#%'*@I9*.*&
6</(!@i(
&H
&G9b*.];
(
G
RM0
T"#%¢*&
6</(!9*.&M0
*
q*"#
+M0
+_,@
b
V™V
0~{"e?*
23
AG[
*(*€O*s
9
w;Z"Z9
I%'&(
(MT&&3A9?*_"#
l9
I0
2
H
&
A"#% A9(!*sš5'%_Q3
R9% (
()G
w(4*H
(
**T;tT*&
B*s*w
I
;(z
0+{,.
]
à]
()RM0
0&
0+{9
d0%_B(*lW
(<0YNd&&G9E(*B0
A*
%'&(
(M*K*KB()
G9<(;
B
RBGQ_S
*'(0?&
U/H
*T"Z9
wM0
]
wT"FR*&
doL*%'*s["Z9
w*"UH
,./
[&M0('(
*F0,@
L&&*
LR*
.
*s(;RRA9
GQ
_%'&(
()› *[
(
**T,K94
*&
T_*T*&
6(!
p@9
T
*s[&)
**K*0
G
0^({9
R(
ASK**
AB(!
p!'(<0
d(b9*[
AS%'&
9
RB(;<;
I,K*T*K'
SMH
&
**R&&
*TQ3
l&)*w
AV,@
(c*
23
GX%'&(
()*
*L,F
O*[&
*
d0
*AB&(*L"X&G%'
K2
*L(<0^*
,K9
(E
AS
&(*d
]9/,K(C_p@9
l
S%'&
I"@9
l"e((
4*9,K*9</RR*T&**
l?B
!*(;?'"e(H
(!(4*sG[*sG
d"Z]%'&(
()."#%¥9
TG
.i
%'M0
<*&&*F*s(A9(*L§%'
9M0]*G¨@*F,F
Y*.*s(H
G9(*§
23
()*G¨X%'%l(/B(! $ %'&(
()*J%_]
L%]H
&
%'
()
0*B(;K%lH 9
0(;
H\
()
(;.M0
J(<0T*.(!
oL()9(;T(
A((;T9
.B%'&
%'
()G(lB*ZF"YF*&
*R"#@
AS%'&
.,@
L((F
S&
**Z9
."AF9</@R%'&(
()
)!9
z
121
x
(I,@
F*d9PV,F%'&(
()*P
.()
G9<(;
bWM(
l%'M0
F&*w4B;
^/
()B(q4(M
A"
*X,@
_(>*sH
*
J9<ZV,Fd%'&(
()*Z9<2MB(;T9
K*%'
K&*@
L*s
¹ !ÚNº µ¸#¹»C §e,@
I*sBX*&
Q+"#((<
*G¨Alp@9*
AH
B('%_w
@)d*s(;"#%¬T&G<&()Z"Y2M
,RtPZ*
()
*s(;RR
&B
R%'&(
()J)](9
J(
0šY
(M
X&/2MB0(;Z
*sX9
F*%'
.*
2M
*X(I9
.*%'
@()
SM
,@
R*{9</.9
{%__
R**s
0Ct
oL(9
.&B
% * À½Y¶c·X½¿ºUº#½» tF9,~I
*
L9</@V,F
%'&(
()*T/
l%'&<B
:i(
w%'&(
()*T/
l*9/,K(
{("e%«_9
R*&
6(*N9
I%'&</-+"ZV,F
%'&(
()*'0
&
(<0*l(a9
?%'&V>"[9
'*&
6H
(*8p@9
b
šY
AB2
b((
AB(*_"T%'&(
()*'/
+0MH
(%'NL&KV&
*K%_^
R*
0^]*sG/B4A9
GQ{9
(
**F"9
.&**B
L((
(*F0(;[9
.2B0(
&9<*
R"O9
T%'&(
()d§"O9
T*K(
¨.LU/
[0B(;I9
**
%l=&9*
` l*à'
*I+A9
GQc9</]
A9>%'&(
()
*&
*X9
K()GZ"C(M
A"
*FZ*
*J(0I9</Z
G9'*
0
()
"e
R&2MB0
*F9
[
S&
0'*
2M
* 3Z€@9</,F
9/2
wG9
GQI9
[%'&</BB-'"CG
L*
*Zor%'&(
(M .,KB
9<23
4
:,K9
(r**
%l
01"_§s¤¨]*_G
*{
U/23
59
b2M
,K&B()',F
b(*B0
+§9
b)q9
?,.a"T&™V
H
(¨F**s"U?9
T(2B(M@"O9
()
"
*KK*
*L(05§\ž¨F"
9
.*
0w(M
A"
*F0T(X&/2MB0
@(
S&
0I&*.§((H
0
%'(*sd%'&(
()*.%_?9<23
R*
23
AGN&*."e[9
*%'
R(&*G¨A ` (?9
A.,@G0*t
4x
OÅ
­
>®
qÆ!²
Ù ¢{
­?¹)ÁX»Nº#º#½»ZÃÚ®Op!Ú!áP¿Âº#ÂÚ!µáPº#¸eº#ÂGÞ|¯ ­ªG‚ƒ„‚…†A…‡ŠŒdƒ'•˜E–G†
ˆ”–ˆG‡—#‡”‡-†ÆT‚ “ •?ª‚ƒ[„‚…Y†A…‡|'
Š — Î
Š ƒ'•˜^–G†[„ ‚Å—Æ)†Æb–˜4Š Œ K‚
’ ‡#‹†]ˆ† “ ŗ ªG†Aˆ[„ “ ‚Å— Æ3†Æ4–˜={
†•3ªG‹K•3ªG†A‡X‚sZ
Š ËP†A—e‡#‹† “ ŠŒ „ “ ‚Å— Æ)†AˆL•J“•3ªG†A‡X‚s.‡#‹†LˆA•ƒ'†K‡˜G„†“
“Š
‚ “ —e‡N„ “ ‚Å— Æ)†Aˆw•K•ªA†A‡.‚sd•{–G†‹•Å— ‚ “ •ŒNˆ”–‡˜G„†AË
¯
° EŠ
Š uÇ
Ç
È
Š
–È
”Š Œ
–¶ –Æ!²&¾È¾Š Œ
´ §+¶¨k F
»Jɞ·qÆ ²UÊ ¾È¾Š ’ §¥É-¾‹fËF¶O¾%‹a¨ZÌѧ¥Éž·BÆ!²¾È¾Š Œ ¨k
Š{•…<Æ=ŠkŒJ‹•Å†R‡#‹†wˆA•ƒ_†RˆA‚” “ ªG†Aˆw•…Æ'ˆ—e…Õ3É
§s¤¨
§\ž¨
3.2
Component testing
|q
59<23
E
0¡
S&BB(
0~9
5
*(*b,K9G9¡B
0œ*?
G9*
[T
*s(;w%'
9M0ww2
"#'
(
**@"NR%'&(
()
,./G0*w*d*&
6(! ` (c9B*d**
(!O,F
{;23
'*%'
%'
_0
G*]w9
]
*s(;4&)
** f A6<((;4^
*s(;
&)
0
T
v)
*.t
È
­ ¹)ÁX»Oº#ºU½»JÃÎÍÏ®mÐw¹/!µ{!º#½<¾/µ¸'Ô»Y¹M¾¼\µ<À¹œÔA»5N¹M¾º#µ»OÀ¹1¯q° †A‡
{
ÈE–G†l•…5—e…‡-† “ •3ªG†I‡#‹•‡.—#…‹† “ —e‡ˆZ “ ‚ƒ`Ñ ß n&n kÑ¡OÉ ° †A‡.‡#‹†F‚ “ Š
ƒI”Œ•ˆw´ n&n y´ ¡ –G†K‡#‹†.—e…Å• “ — •…‡ˆK‚s“Ñ nn&n yÑ ¡ “ †Aˆ\„†ª‡—eņŒ ˜3É
ß
Ê!‹†d—e…M‹† “ —#‡\•…ªG† “ †Œ•‡— ‚…c‚s
+
È —eˆRª‚ “G“ †ª‡@ß — R•…Æ{‚…<Œ ˜l— P‚ “ •Œ#Œ
ª‚ƒ[„‚…Y†A…‡ZT
Š „ “ ‚Å— Ɨe…)©=cÈ •…ÆL‚ “ •Œ#ŒNª‚ƒ[„‚…Y†A…‡|ŠVŒ Î
»1¶¤·žÆ ² ¾È¾Š Œ Y»-Ž“4· )¤ &nnn ON¼ )B§+¶W¾‹‡ËF¶W¾Ñ ½ ¾%a
‹ ¨ZÌÒ´ ½ §+¶ ¨-Ÿ¥
’
*
B
d]
&
*
()G23
w*
T"Z
*sT*
*T*(
w
S9<*s23
*sB(;]*[(.GGB
’
923
{(=G
Z9<I*I4*=*%'
9(;=§ (9
I&H
;G%bF59M%_(!Z+*&
6(C[G¨}
^50
B0
^"
9
R&;G% ;23
*K9
RB;9)(*s,F
[,K9
(4
S
0{,K9
w
*sL*
’
L
Ld
S
.9
.
*s*39J*Jd*l(]9
.
*s
0
&;G%­,K9q9
'G9*
(q
*sw*
*?§(&*G¨T(0EA9
GQ
§*(;l9
TG
/¨.9
R&;G%b› *K&*.
A
(
**
i!&&*(dGQ3
*N&B
F(T"e((<(G/)(0T*&
H
6<(H-*
0+BAQ)H\S^
*s(;dp@9
w*
I"Z"e%_P*&
6H
/B(*d"ew
*sB(;b9<*d*
23
GJ,@
BH\QM(,K(q02()G;
*X(<0
*
T"N*@"#%b)9
[(G(_,@
[&&*
T9<*F9
L"eB,.H
(;](
*t
’
p@9
K*&
6</('%_I*R
.*
"#Z9
Z*sG;
*F('*s*sH
%b› *NB"#
O|q
J(d"eX
S%'&B
Z
23Q3
J9
J%_(M
(<(
tC,K9
(
’
,F
[*
KZR;
(
G/
K
*s@*
*J,K9BG9_
.G
*)9M*P,@
*sLl%'&
92[(M23B2M(;w*
23
AGC9
AK%'&H
(
()*Y*
23
GX%'
9M0*YB
(MR(<04*
2
d*&
*T"J9
%'&(
()X(0E(Ib*B%'&
{*s%I* *&(*
{&H
p 9
4
A(
**?"T9
4B(9
G(
b
B/B(*?"R()
"
*
@
*9U0b
d&2
0b0(;l9
w2B0/(4"X9
R*&
6</(!
Ž[
R9</L%'&(
()K(9
G(
I0)
*K(T/šY
L23
A6H
(*[*]L*K(L(*sGB(
0C
6Ô
ÅnÓ
nÍ Õ
ª
mÖ
kØ
êFæRô.æGñ\ñ\ìäZãAé!éUæAçsñJñ\òìKê\æAô.ìKçVòìçVèêZæä ì[ðìçìê ê æä RéBãäFìæAçVòIãó ìçsñ
ëæä æAô.ìsñ-ìäVíñ\òìZëä ãçìê êNõ ê!õ ïìðñ\õ çæAåBý
ê õ ðùTñ\òõ ê@ïìsö3ðõ ñ\õ ãð3íê ë3ìçõ öçæAñ\õ ãðêXæä ìðãAñFõ ðòìä õ ñ\ìï3ý Còõ ê@çVòãõ çì
ùAõ ÷ ìêê ãAô.ì!éBä ììïãAôcõ ð@ñ\òìNê øóüBñ /ëõ ðùXä ìå æGñ-õ ãðê<óø/ñô.æ .å ìæAï@ñ\ãJì /çìêü
ê õ ÷ ìNî!ä\õ ñ-õ ðùZîYãä èý IìOçãAøå ï.æAïïKæZêñ-ä ãAðùAìäõ ðòìä õ ñ\æðçì!ä ìå æGñ\õ ãð.øê õ ðù
ëä ã ìçsñ\õ ãAð[ñ\òæGñOîYãøå ïdæïïTô.ãAä\ìJçãðêñ-ä æAõ ðñ\êOãðRê øóüBñ /ëõ ðùKóøñOã )ìä ê
ê ë3ìçõ ö3çæAñ\õ ãAð[õ ðòìä õ ñ\æðçìAý
kª
E×
+Ô
WÔ ©
+Ô
Š Œ
p@9*0
6((^,FQM*
*
d"Z9
R
9<2MGO(9
AG(
B(a,F
b0
A6<(
0q
_(>()
"
* ` (>*%'
{*
(*
{
0
A6<(
*KlQMB(0?"X
9<2MGC*H V&(;d"e%'&(
()*
p 9*K0
6(({B*.*&&*
0_I
(*
%'&</BB-_"P%]H
@
&(
()*[p@9*[B*L9
d*
I,K9
(b
&G
*R(<0b&G%'
A
*
*
0^)?l%'&(
(ML/
R
S?"P9
d0
B/
0?V&
Jp@9
"#,KB(;_v)
*s({(
(*@*H V&(;tO,K9</.9<&&
(*@"!,F
((
{4
&G
4"V&
Eq4"
_,K9*
^V&
?B*]
*H V&
w" 1|q
l
AS&
RBX*sG/Bl23
6</(*T_
%_B(
2B0],K9</
23
@0(<%'B.((
(*@/
%_0
P€F93,F
*
[
9<2MBG*H V&(;tNd*-&
.,K
9<23
KQ3
[()]"
*L*&
H -&
*.B(?9
R*%'
R()
SM@p@9M*9
d0
6((b"
((
G
d%'&(
()*@,@
R;23
dB*K2B0^
23
(b"P*H\-&(;
*[*
0b(<0^,F
w923
w]*s(;_(9
G(
R
B(CK3nF
923
Q3
]*&
H V&
{%'
(*"ew*9d"F,F
';23
I9
](&*T"
9
J*&
H V&
XK9
J*-&
9
F*-&
X&M0
*N&*
9LB0?9/2
R
(^&M0
0?)_9
*&
H V&
t
”Èx
§ŠkŒ
’
†A‡ I–G†•wª‚ƒ]Š
{¹)ÁX»Oº#ºU½»Jà Ýd½»O»N¹ÀµáP¸#¹{À½Y¶5·Z½<»N¹»C¿
„‚…Y†A…‡I•…<Æ
E–G†?—e‡ˆ'‡ “ •3ªG†4ˆ†A‡-É8Ê!‹†bª‚ƒ[„‚…Y†A…‡ 5—eˆ ª‚…Š
…†ª‡\•3–ŒB† I— d•…<Æ?‚…Œ ˜'— X‚ “ †•3ªG‹^‡˜A„† q‚s “ †ªG†-„<‡\•3ªŒB†Aˆl‚ “ ‚3–Š
̆ª‡X„• “ •ƒ_†A‡-† “ ˆ_‚s ËC‚ “ •ŒeŒPª‚ƒ[„‚…Y†A…‡
„ “ ‚Å— Ɨ#…M©4•R•3ªG†A‡
‚VR‡˜G„† <ËJ•…<Æ[‚ “ •ŒeŒY‡ “ •3ªG† w‚V
Î
WÛ
Š
‡#‹†?ˆ† “ ŗ ªG†Aˆ “ † ”M— “ †Æ=–˜
• “ b
† •Å•—Œ•3–ŒB†I “ † ªG†-„<‡\•3ªŒB†Aˆ
‚V R• “ †?‚sl‡#‹†'ˆA•ƒ_†]‡˜A„†Aˆ'‚ “ G– †‹•Å— ‚ “ •ŒJˆ”/„† “ \Š ‡˜G„†Aˆ?•ˆ
“ †ªA†-„‡\•3ªŒB†Aˆ]‚V Ë
’
9
R*&
6<(+*L9
RG
w
*
dG
*L()GB(4(H
&*+*5,F
]*+&* Ž
q9<49
q*&
6(
B(;;
{"#% *I23
Aq0šY
A
()w"U% &;G%'%'B(;bB(H
;<;
*9*K23B0(;l
0(<0(A?
A*
@¹¿ÂÿÀµ¿¹]Ù<¹»N¹M¾/µÂºU½»JÃ
oL*X6*sZ*s
&!,@
.9/2
@T;
(
G
&
*
()G23
R**
K"Zl%'&(
(MFG
R*
Jp@9
T"e%
I
"F9
l*&
6</B(q()M0
*V,F^QM(<0*T".&B
%'*t6*s
±
122
&(
()Z(<0
P
*sZ*J&B
0](l9
@
*sZ()GB(
Z,K9A9l%'(H
*.9
[
*sK
S
B(*tZ9
K%'&(
(M*@
T
&
*
()
0
){*s*@9KG(*%'K%'
**;
*.l9
T()G(
A
,F
49<23
{q;
(
G
4*
vM
(
*'"R
23
()*'(01*
(<0a,F
923
l6(<0?&G%'
K2
*.9K**s"U^9
(*sG()*
p@9
_B(M2B()I*lb"e%lUMtl
%'*w(<0E;.((
23
*
€O*sM,@
(*U0
@9
["e%lUR"#% 9
L2M
,K&()."N&&H
*(YB*Z,K9
KG
[&
0
*F
L9
L%'*F"Y9
"#%IBZnJ'6(<0B(;lC%l(<(*@"O&
0
*@9<@*H
*s"U19B*'"#%lB5,@
+/
+0
6((;c[&**
4
9/2M*_"
9*J%'&(
(),K9BG9'*JB*
L[9
.B**0*e™s(23
.(H
%_"#% &((;T
A9(Bv)
*O"U%u9
F
*sZ
AG
R Ÿ\
ZG94*B(b;23
*[*K"#%IB*.]G(4*
*K"P
*sL*
*
p@9
[&B
%}*Z9
(lR;
(
AG
K9
*
.
*sF*
*Zp@9
.
%'*
;
(
AG
=B(;<;
*+9</+()GB(82/U
*+(*sG(
08)
&
0/
*c€I
S%'&
O9
_(M2/B()l"
*.d(™s((?"N%'&/B(*Zp@9
[
*B({;23
*@*J9
0*e™s(23
w(%_N"e%Í,F
lB049<23
wG(
04)b
&UH
(;^
A9
¥)=§
I¨ q§
I¨ E§
l¨[(<0
0*sB(;KWM"e
S%'&B
(
T
A% "P9
d0B*e™V((b*
;23
(b)?€O;
4.
RELATED WORKS
p@9
A
^*](,¬,KU0
*&
0:
&G(
^/23
I9
{(
**Vq
*&
"UE*"#V,@
_*s*s
%­(<0c(
'AQM(/,K
0;
*d9</d9<2M(;
'&
B*
I(0b(%l;*K"e%_O*&
6(c2BB
I*
l&
v)*
R(bG0
.'%_/
RBGQ)H-S'
*s(;
z
pNM0w9
A
.
SB*sZ*%'
.&&**X"eJ*&
6('B(;;
*
0
*B;(
0r"e ` ()
"e
* f 6<(B( g (;<;
*qt>"#+
S%]H
&
g /A9 $ <> ž°Ÿ@,K9A9=*IG/9
l0/GH\
()
0=0
]
*)*B(co[*sG f G{pZ&
wdnJ(
c¤ /ŸX,K9
I(H
*sG()*J0T(X(*B0
F0/GPŽ[
@9X9
*
@-,@T&&**
(?GQ3
T()'()K*
2
[*&
*L"O%'&(
()*
*!()!./. ' @
ܜÌÞÝ
¥ÜFºBÝ 5ß à|ÜFºBÝ 5ß à|ÜFºDà|Ý
t
Á
MYZI [(\()|]Y<!)5MU@1Sl_\baES
ºáMU(/(9(\ d <Z]<!)5MY@1SJIU(9([\<|]Y<!)^MU@wvY()SR\w_?KS
ºlàâMYZI [\()|]Y<)[ ") d _\faES
ºlàâM \ d .5~ V R‡ES
ºlàâMYZI [\()|]Y)"; )99MU@|VU21Sl_\bajS
ºlàâM \ d .5~@|VY2jFES
ºlàâMYZI [\()|]Y)"; )99[ .((9)(; d _¥\baES
ºáM!e \ d .5~ V H&QESS
ØKº#Ù<ÚN¾/¹8Y
ã Ü§ä ¿µ¶c·P¸U¹cÀ½»å ÚO»OÀºU½»r½<¼LÔ»J{ µ¾ºUµ<»YÂ'¹M¾¶c¿Ã
(  ×) Ÿ9
.9*Z
SM
(<0w;
(
G `VfRg *J(<0I9
( $ im[n@oKH
` ^
`VfTg ,K9¡&)RB("e%_(¡(
((;>*&&
0r(<0
v)
0>*
2M
*'*B(;qj^(
A› *_&)0 CH\B*],K9BG9
*
%'*Zd
R%'
L,r
23
<*s()GSlB(;<;
[9(_*@(<0
 ž/ŸP*
*[l"e%_B*% <*
0b(+¯O
ANŽ
AL'*&
"# $ im[n@o
%'&(
(Mbp@9
_*&
6(>("#%_(
',K9>
*sB(;4*
([00M
**
0^({9
*
T,FQM*
t
ì Á
$æ¤ç1èJé
”æ¤ç/è ê èXë
…í
p@9
K;
(
GBz
0'*
K"C£Rj g (G/({(0l*J2*F
92MH
G"e%_*%'*c§*sG/
H\A9*LBG(œ(0:*
v)
(
0B;G%'*G¨OB(;*PX*
23
AG&&3A9
*K§ (<0R)*G¨O"eZ
*sH
*
.;
(
G(I(I™V
H\
()
0l*"#-,.
Zp@9
*
F,FQM*X
<*
0?(^
G9(Uv)
*@*
0?I6(
T*sG
R%_A9(
*@K6<(
B
0^G(*(b*s*s
%'*R MN¤ !¤žM!¤¤Ÿ o[(9
{B**^"w&&3A9
*_"e{
*s?;
(
G(r*
*{&</H
(+
*s(;?
A9(Bv)
*I h )X¤Ÿ IZ23
(c"Z9
*
w
A9(Bv)
*
;
(
GBI
(I(w%'M0
H\<*
0wZ;
GK*&
6(*X
&/™s
[,KN
(
6."#% 9
*
T,@QM*
|z
p@9
*B(',@
0&
0]dG('9
KG
*@*Jd*
*^()M0
0~(}¤ Ÿ t>&
G/*b(~G
5B(;<;
*
&
0/
*"#((*L0
6<(
0{){*
A*w§e,K9A94/
d
0?B(
CH\BQ
K"#%{¨A%_d
K0
A6<(
0I*
bU*
*
p@9
b;L"[9
^&;G%®9*'(
?"U
b2BB
?,K9A91*
9M*XI
(M%'
AG
*R9
'G
*cpN4G(>bGG
_
*s
*
l*
A<,@
w9<23
T{0
A6<(
T,K9
(4'*s&CL|E
d*
R9
R
;H
B/-b9)&9
**L()M0
0^(= h Ÿ!,K9G9b"e%_Bz
*[9
T"eH
,K(;{B0
Mt@"Z,@
R
*sN9
d
*s*
*[,K9*
w%'&
S-
*',@
'9(>9
?%'&B
AS-q"[9
{"e%IBJ9
(=,F
b(
(*B0
d9<R9
I"#%lB?*d2BB0'p@9
'&
%y*Tb0
H
6(
@9
.%'&B
AS-wR*
X€J9
.%'%'
()/,@
K(*B0
AJ9
(M%l
".&
G*IB,K(;b^;
(
G
l9
lG
*R,K9A9
*](]"#=**s"U(;>|r9
(q9
{*
v)
(
*'/
^X9
B*s&
G(^(*B*s*L(^(*sG()U/(;'&</G%'
AK2/U
*
$ (*sGB()*w(q&G%'
*d
_;B2
(E)5&
0
*w(<05,F
*
@("e%'-d9M&9
**O()M0
0I({ h Ÿ*
Z(
J
&H
*
()G23
R2
T"#L
G940%_(C
ê Xè ë
%æ¤ç1è ê èë
&ì
?a
5.
CONCLUSIONS
|q
d9/2
R&
*
()
0b(b9B*L&<&
_%'&(
()L
()
0^"eH
%_(G(](<0I*%'
@"9
@;
(
G<0
6<((*P9</J(]
S&
0{l2B0/
T*&
6(*(<0'l&2
T%'&(
()
&&
*Ep@9*I,FQEGQ3
*w*
(*
{"[)B*]
{&/2MU0
0c
*&
"Ub(<0?2B0/
T%'&
%'
()
0'%'&(
()*Xp@9
T,FQ_*
(I&;
**3
*&
BI9
J
*sX&U/"e%8"eZJ‘3nL)WMB(
@X(</
nJ)G9>‘9(*
(q
()c6(*9
059
{0
6((q"[i£Ž *
AH
%_()*K(4¯ RWc¤ h Ÿ <,@
d/
w(,œ
0_'
S&LL'0
,K9=2U0(a*&
*cW%'
'9
]*&
*wB0qB%'&
[,FQ{(b9
T"e
@p@9
R6*sL(
d*L_00
**L9
R;
(H
GP%'&*(c&
%btK9,8_BB0+_%'&(
()L"#%
%'&(
(M*
` (?[(M
AS9
R&
%¢*K]6<(<0?lG
*
w"eI9
?**
%lc"U%­9
'%'&(
()wG
_*
*XI
AH
B
*ZT9
K&
%"Y"#%_B(;<;
K
(*s(!Zp@9
*
(<0:(
b*'=0
*
+E%'&(
(Ml,K9A9~(~&&B/H
(q(
0*d(<0+6<(05_p@9B*R
v)
*I{*&
6<(="@9
&&(=(0+?
'B
I^
SMGAT"#%­w{%'&(
()
*&
6(>§e,K9BG9b*L(K9
R%'*s[0à'[&A¨A $ )
9
K%_™s@&
%,@B0'
LR*
/A9{R%'&(
(MF(0l9
%_/B(+"F9
I*
G9c*
%'*({
wGG
l"eT9
%'%'
(MwoL(),@)Y"@?(<0U0
I%'&(
()R*T"e(05)+
*
A)F*F&**
LR%'&</
K*Z*&
6(]xw"CF9*Z(
x4{9
]*&
6(=0
0
05"#%y9
'&&B/(!› *wR
*sKFx]"NK9<*F(l*&
6</B(!(?G0
.w
T*
L9</.
*K(M23
(
()."eL9
T&&B(C
ZÄ
yx
@¹¿ÂÿÀµ<¿¹+¹M´!¹À3Ú!º#½»JÃ
|E
RG(4]*
L"P
*s[*
*L,K9A9
/
'G
*N9
'&
%­*w(,4
S
I9
]G
*4p@9
*sG(=
23
Z"@w%'M0
X;23
*d*TG
*d9</w
'(
0
R
S
GB
f B(;.9
X&)
**P0
2
&%'
(MC"%]H
&(
()*9
`VfTgNh 0
*&('B*X&™V
0]( `-fRg ž[(<0d9
(
*%'
5
*40
A6<(
+&™V
(*4()a0šY
()b&;G%'%'(;
B(;;
*lW_,@
l923
w?&&b9
I*%'
I&™V
(*T
*
wFG
*FwG('9
K
G
*F9</@%_]
L*
23
0
0(;I9
T%'&(
().
S
B(!
p@9
=0
23
&%'
()b"'a
*s+&U/"e%
%'
075Z‘3ny*4B(
&;
**Tp@9
d<*wB0
'*L_*
Il
*sT(MG(
Lou%]H
ì
123
nt
g
%bd(u&</B5m[&9< ]jb/2
>(<08¯X9&&
aj^
‘
(Hsjb/]k
B+9*L&/2MU0
0^2<
w0
GB
0402M
d(H
((;I9*K%_(M*&
î
+ñ
…ð
žó
J
ô
Á Á z t
t
ð
ú
nì(ì
Ä
¤õ%õ ° ð
”ð
þ
|ó
þ
/Ä
õ%õ ô>ö ÷(÷:ÿ
ô
Á &ìì(ì
Á
ÿ
ô
ö û!üüüký Ë
þ
qù
¥Û
z
¥ð
õ%õ rô ö ÷÷
zt 5° ø |ð
qó
&ì(ì
ZÄ
ð
µ
Ä
ô
þ
Jó þ >ö ÷ ù
Á z 5° ø |ð
Á
¥ð
ô
$ñ
t nì(ì
 ±/Ÿ I f Q3
AL(<0^kImLz
(M
;
0*@Ê!‹† [‚‚/Õ{‚V
Ê “ •3ªG†AˆG|qB0^W
()6<<W(;3&
N¤ ×M
nì(ì
ì
 /Ÿd‘DT%_((C $ ` %'
G0"V(0bjcj^
*B(;
£Rj g H\<*
0?()
;G/B(b
*s(; ` (
OÊ
“ ‚ª/É
&&C °/x °MY¯OB(0Ci[
;(!<ž°°°
ô
Á !z
^ùyð/ð ûüüü >ð OÛ
¤°Ÿ $ odmwD
JZ‚ƒlƒI”M…— ª•‡—e…)© † ”†A…‡— •Œ
¯P
()B
RDTN¤ ±×M
nì
ô
“ ‚ªG†Aˆˆ†Aˆ
¤¤Ÿwp‘ (C<‘ HVjc‘ z v)
(0bow g wk
((
JB0(4(0?
*sK;
(
G/B(b"e™V
H\
()
0
0*s
0_*"#-,./
` (
Ë d˜3‚‡\‚Ë M•A„•…
Ä
“ ‚ª/É
¤ ±M
Ä
&ìì
ô ð rö ÷ ô
wú
¤ž/Ÿw‘ HVjc‘ z v)
ow g <k
((
(<0b€F¯O
((<(
› 9C
JB0(;'0*s
0?*"#V,@
w%'M0
0_,K9^9
£(6<
0^j^M0
(; g (;<;
` (
Š
“ ‚ª/É
†A˜‚…Æ_‡#‹†
‚‡\•‡—‚…Ë
”Œ ‹‚”Mˆ†AË “ •…<ªA†É<23 C¤ ¤±]"
 &&C h ×x h MP¤ ±
Ä
ñ
5° ø |ð
ø
Á
ô þž°=ö ÷
|ó
Á
þ
z(z nì(ì
ZÄ
¤ h Ÿw.<n[<‘9(*
(b(<0^iIi[,F
o8¯ RW{&)"X
(M2M(%'
()
"eRi£[ŽIMmL
*
/A9bmL
&Tž 3×) f &%'
()."
` ("e%_*£(23
A*-{"Zi*™s(
wž°°¤
ì
&ìì
&ì(ì Á
ô ^ þ $ð ö ÷
°5ø |ð
Á
jì (z
&ì(ì
 žM¤AŸIiIW))-ð„† ª— J
µ ª•‡— ‚…Eª‚ƒ„‚ “ ‡-†Aƒ_†A…‡\•ŒB†]Æ)†wªG‚ƒ„‚ˆA•…‡ˆ

õñ¤T¯X9 f 9
**£[(23
*
d
0
TpNB*
` ž°°¤
 žžŸ $ WMz&
*QM ZZ‚ƒ[„‚…Y†A…‡”
ð ‚VA‡ÇJ• †?ñ †A˜‚…M©BKõ –eÌ/†ª‡
õ “ — †A…‡-†Æ ô “ ‚© “ •ƒlƒI—e…M©o00*(H\“ |E
*
)Y¤&ìì ±
 Ÿd‘ f AQ{(0^od€2)
oL%_/(;d9
R;
(
G/B(4(0
*
v)
((;l"O
*sL*
*K"#%¥%'M0
H\<*
0
*&
6(* ` (
Î G…<ƔMˆG‡ “ — •ŒŠ ‡ “ †A…M©‡#‹
“ ‚ª/É ^Ä
N‚ “ ƒ'•Œ
†A‡#‹‚ƈG23 °]"
 &&Cž ±xž± P¤
h
ó
 ž°/ŸIkIWMB2&G*0C g G9 $ imnFowt<W&
"U(;l9
9<2ML" $ im[n@oKH `-fRg B()
"e
*Yp@m ×/HVž f &</%'
()." $ %'&
[WB
(
` ,@_WMG
£(23
A*-)Y¤ ×M
 Ÿd‘ $ /,RWYi[,.
<‘mL*9M))MŽIWM9<(Q/(<0
jc<WM2*<o7B!()M0(^'¯ RW ` (
“ ‚ª/É
‚ “ Ոs‹‚G„=‚… G…Æ”ˆ‡ “ — •ŒŠ ‡ “ †A…M©‡#‹ N‚ “ ƒ'•Œ „†ª— Fª•‡— ‚…
ÊY†ªG‹M…— ”†AˆGnF)]m[(C<€OU0!¤ ×M
ÿ
ZÄ 1ù
z
Dð
&ì
 ן $
$ (< g €
(M
*(<0?ow FB
BXSM
(0(;
`VfTg *@,K9b&H\B*."e&)N%'&</BB-) ` (
‚ “ Ոs‹‚A„ K†•3Æ)† “ Ë Ä 
“ ‚ª/É Ä 
‚ “ Ոs‹‚G„<ˆË
•…Y†Œ ˆËJ•…Æ
‚ˆ‡-† “ ˆ23N¤
 h "
&&C×x O¤
M
ô
µ
¤ /ŸIWY<W(Q/ ` ()M0(;I"#%_!%'
9M0{]*"#-,.
(;B(
*.9;9+iRj4kI› * $ im[n@o8
(2M(%'
().(<0
B()
"e
w0
6<((^B(;<;
` (
OÊ
“ ‚ª/É
”M…— ªG‹MË L† “ ƒ'•…˜<23 C¤¤°¤d"
 &&!מx ¤
¤
 Ÿ $
$ (< g €
(M
*‘<p!MM<(<0bod FB
B
PS
(<0(; $ im[n@o8()
"
*K,K9?&H\*K"e
&)C%'&<BV) ` (
Ä ” “ ‚A„†
“ ‚ª/É@Ê
‚…‡ <•—e…‡ Š — ªG‹†Œ Ë “ •…ªG†A&&!ž°±/xMžž×M ` ZZ
$ %'&
[WM)
V^¯P
**Yž°°°M
ô
ö
¤±/ŸIWY<i[,.
<‘mL*9M))MŽIW9(Q/(<0b€F23(^D
(Q3
€%_C2
6</B(^"e["eH B
AG()[G9
*t
¯XB
;%'
(<wd9
0
*;(?"P¯ RWY ÄZÄZÄ Ê “ •…ˆA•3ª‡—‚…ˆ
‚… ‚sA‡ÇJ• “ † Ä …M©—e…†† “ —e…)©Yž)¤3§\ž¨At¤° x¤/ž×MX¤ 3×M
 h ŸwkInF
(Yjc H $ kT<0
(0^n[jb
<W"#-,.
*s(;l<*
0^(^"#%_!*&
6(*tFI9
?(<0?
) ÄJÄZÄ ‚VA‡ÇJ• “ † Ä …M©—#…Y†† “ —#…M© M‚” “ …•Œ § ¨At h ± x °3×MX¤ ¤
Jù
nì(ì
Á Ÿwow‘Yi[šYK(0bowoLY0GzQ<k
(
G/B(;]
*s*."#%
£Rj g *&
6</B(* ` ( ô “ ‚ª/É þ…°“÷÷ Ë^N
ó ‚ ‡TZ‚ŒeŒ —e…ˆË

@
õ M&&Ct¤ Á x3t žMì ` ZZ $ %'&
AKW)B
AV{“ ¯P
**!¤nì(ìì
¤
z ŸIiIi[,F
R(0 ` mKoœ(G(^"e%lB((;I"#%_
*((;<M™s
()G(4(<0^&
((
**m[m8ž(
z ±
ì
f &</%'
()." ` ("#%_/B*<£(23
*V_"Ji*B!¤nì(ì
°5ø |ð
Á
¤
î
 žŸRmd<n@*sB0
iI<W))(<0?¯O<¯PU(<v)
<€%_
*&
6(+(<0{&V&(;l" $ im[n@o7*s*s
%'* ` (
Ë —#ˆ–‚…
‚ “ ‡”©3•Œ 2Y¤ ž±l"
 “ ‚ª/É Ä 
&&C
/x
P¤
õ$õ >ô ö ÷÷ °
tzt t(ìt nì(ìì
6Û
(ò
Jù
Z‚ƒ[„<”M‡-† “ Š [•ˆ†Æ ˜ˆ‡-†AƒlˆR‡#‹ “ ‚”©/‹ N‚ “ ƒ'•Œ –ˆ‡ “ •3ª‡—‚…
ÊY†ªG‹M…— ”†AˆG<¯Z9 f 9
**<pN
A9(*A9
(^£[(23
* /[k[Gz
k
%_(M)ž°°¤
ô
¤/ןdmwjb2M
w(0^¯Oj^
AB
$ $ %'&(
()[j^M0
t
f ***(+(<0{*
T,K9+i&
( $.$ jc G…‚ “ ƒ'•‡— ª•
*%'
0Y
7.¤AŸdn[REFERENCES
/ï]<oLA9
(;𘈇-†Aƒ'•‡—ª§ñLŒ•3ªGՊ+ñ[‚&òcʆAˆG‡—#…M©^‚s
¥Û
¤ Ÿwn[jb/
C…Y†Rƒ †A‡#‹‚Æ3†]†A‡F”M…c‚”M‡—Œ!Æ •ˆˆ—eˆ‡\•…ªG† •'Œ•
ˆ †ŒB†ª‡— ‚…qÆ)†XÌ/†A” {Æ3†d‡-†Aˆ‡ˆ •R„• “ ‡— “ Æ)†Rˆ „ †ª— Fª•‡—‚…ˆ
•Œ © †– “ — ”<†Aˆ<¯Z9 f 9
**£(23
A* d0
R¯P*sHVW0_x
i[*)Y¤ ¤
6.
ACKNOWLEDGMENTS
|E
Z
Z;G
A"e"e!"e
0<AQL"#%80B***(*N,K9T9
JkRi[o
¤°
124
A COEL on C ORAL
A COmponent Requirement and Abstraction Language
An Extended Abstract
Vugranam C. Sreedhar
IBM TJ Watson Research Center
Hawthorne, NY 10532
[email protected]
ABSTRACT
In this paper we will mostly focus on C ORAL.
There are two aspects to C ORAL: abstraction and requirements. Abstraction essentially suppresses the irrelevant details of a component so that one can focus
just on those properties that we wish to verify. There
is definitely a compromise between abstraction and the
level of details that one is interested in verifying. Requirements are constraints that are necessary for proper
functioning of components. There are many different
kinds of requirements that a component will want to enforce. For instance, a square root function sqrt(x) will
require that x is not a negative number. For proper
functioning of a FTP component, it is required that a
client first connects to a file server before getting files
from the server. Some of the popular modeling and
specification languages and tools in the literature include UML/OCL (Unified Modeling Language/Object
Constraint Language) [10], JML (Java Modeling Language) [15], Larch [12], SMV [17], etc. Once the requirements of a component are specified using one of
these languages, the underlying system will then encode
the specification into a mathematical structure and then
prove the required properties.
To ensure usability of an abstraction and specification language, it is important to maintain a close
correspondence between the component concrete language and the language used for specifying abstraction/requirement of components. JML, for instance, is
tailored to Java [15]. C ORAL is a requirement and an
abstraction language for expressing and proving properties of A COEL components. A component in A COEL consists of a set of typed input ports and output ports. The
input ports of a component consists of all the services
that the component will provide, while the output ports
are all the services that the component require for correct functioning. A port type can be either an interface
type or a delegate type. An interface type consists of a
set of methods and named constants, whereas a delegate
type is an encapsulated signature of a method. The internal implementation of a component in A COEL is completely hidden from the clients (i.e., a black-box component). In C ORAL, the set of input ports of a component
are abstracted as a set of input actions, the set of output
ports of a component are abstracted as a set of output actions and the internal implementations of a component
C ORAL is a language for specifying properties of A COEL,
a component-oriented extensional language. The design
of C ORAL is based on input/output automata and type
state. The properties of A COEL components that need to
be verified are specified using C ORAL. A verification engine will then crawl through C ORAL and verify whether
A COEL can be safely executed or not. In this paper we
focus on C ORAL, and show how to specify properties of
A COEL. We will also briefly discuss the concurrent modification problem that is commonly encountered in the
iterator design pattern.
1. INTRODUCTION
The Internet has revolutionized the kinds of software
applications that are currently being developed. These
days people are talking about applications as services
just as electricity and telephone services. When software
are treated as services, it is important to ensure that they
are properly packaged as components that can be easily connected to other software components, and it is
even more important that (1) software components be
certified that it will not do any harm to other components or the environment in which it is deployed, and (2)
the clients will properly use the components. A COEL is
a component-oriented extensional language for creating
and plugging components together [22, 23].1 In A COEL,
a component developer can specify and abstract properties and requirements of components using C ORAL (a
COmponent Requirement and Abstraction Language).
Depending on the context in which a component is used,
a certification tool will try to certify that the component
is well-behaved and is safe for plugging into the system.
1
A COEL was initially called as York.
Copyright 2000 ACM 0-89791-88-6/97/05 ..$5.00
125
are abstracted as a set of internal actions. The states of a
component, and of the environment are encoded using
state variables and data types. The above actions when
performed on a state will transform the state to another
state. In C ORAL such state transitions are expressed using a state transition relations. The C ORAL model of an
A COEL component is very to close to an input/output automaton (IOA) [13].
The rest of the paper is organized as follows: Section 2
gives a brief introduction to A COEL. Section 3 discusses
IOA modeling of C ORAL. Section 4 introduces C ORAL
using a simple example called the concurrent modification problem. Section 5 discusses some of the related
work. Finally, Section 6 gives our conclusion and also
projects some of the future research direction.
interface CLIntf {
void add(int index, Elem e) ;
void remove(int index, Elem e) ;
Elem get(int index) ;
ListIter iterator() ;
}
An iterator component interacts with the List component using the following interface.
interface ILIntf {
void remove(int index, Elem e) ;
Elem get(int index) ;
void start() ; // start of the iterator
void end() ; // end of the iterator.
}
A COEL
2.
The start() method and end() are basically used to
start and end an iteration, and iterator() is a factory
method that returns an iterator component.
Next we define the List component.
The design of A COEL was motivated by the following
component design principles.
Pluggable Units A component is a unit of abstraction with clearly defined external contracts and the
internal implementation should be encapsulated.
The external contract should consist of both the
services it provides and the requirements it needs
when it is plugged or (re-)used in a system.
component List {
in CLIntf clin ;
in ILIntf ilin ;
ListNode head = null ;
int count = 0 ;
List(){head = null ; count =0 ;}
class ListNode {
Elem e ;
ListNode n ;
ListNode(){} ;
Late and Explicit Composition. For a component to
be composable by a third-party with other components, it must support late or dynamic composition.
During the development phase, requirements of a
component should only be constrained by some
external contract. Then, at runtime, an explicit connection is made with other “compatible” components (i.e., one that satisfy the constraints) to effect
late composition.
}
class CLCls implements CLIntf, ILIntf {
void add(int index, Elem e) { ...};
void remove(int index, Elem e) {...};
Elem get(int index) {...} ;
int count(){return count ;}
ListIter iterator() {
return new ListIter(This) ;
}
void start() { ...}
void end() { ...}
Types for Composition. Typing essentially restricts
the kinds of services (i.e., operations or messages)
that can be requested from a component.
Restricted Inheritance. In OO programming, it is
well-known that one cannot achieve both true encapsulation and unrestricted class inheritance with
overriding capabilities [21]. In A COEL, classes
(which support inheritance) are second-class citizens, and are not visible to the external clients.
}
attach clin to CLCls ;
attach ilin to CLCls ;
No Global State. In A COEL, there are no global variables and public methods that are visible to the entire system.
}
The attach statement essentially attaches an input port
to a particular implementation class inside the component. Any messages that arrive at an input port is forwarded to the instance of the class that is attached to
the input port. The class instance will either process the
message or it will delegate to another class instance inside the component.
Next we define the ListIter component. It consists
of one input port and one output port. The output port
ilout is used to connect to the input port ilin of List.
A client component uses the input port clin for accessing services of the ListIter. First let us define the type
CIIntf of input port clin.
Let us briefly illustrate A COEL by implementing the
Iterator design pattern [11]. An Iterator pattern consists
of an aggregate (e.g., set, list, array, etc.) and an iterator that traverses the aggregate. The main construct in
A COEL is component. A component consists of a set of
typed input ports and output ports. A List component,
defined below, consists of two input ports: one port is
used by the client code to add/get/remove list elements
and for creating an iterator, and the other port is used by
the iterator to add/remove/get list elements. A client
uses the following type to access services from the List
component.
126
Client
clout
clin
via its own output port ilout, and this output port is
connected to input port ilin of List component instance.
Finally, here is a client code that wants to access the
List component and the ListIterator component.
List
ciout
ilin
component Client {
out CIIntf ciout ;
out CLIntf clout ;
main() {
List l = new List() ;
connect clout to l.clin ;
// add a bunch of elements ...
ListIterator li = l.iterator() ;
connect ciout to li.ciin ;
ciout.start() ;
while(ciout.hasNext() {
Elem e = ciout.next() ;
}
}
ciin
ilout
Iterator
Figure 1: Various components in Iterator pattern
Figure 2 shows the overall structure of the iterator pattern. There can be more than one iterator that is simultaneously active. A client will typically use the iterator created by the list component (through the factory
method iterator()). The list component can ensure
that it will only interact with iterators that it created for
a client. Whenever there are multiple simultaneous iterators, there is a potential for concurrent modification of
the list by multiple iterators (which will lead to inconsistent states). We will discuss this problem later in the
paper.
interface CIIntf {
Elem next() ;
Elem start() ;
boolean hasNext() ;
void remove() ;
}
A client component uses the start() method to start
a new iteration. Here is the ListIter component for
iterating over the elements of a list.
component ListIter {
in CIIntf clin ;
out ILIntf ilout ;
ListIter(List l ) {
connect ilout to l.ilin ;
pos = 0 ;
}
int pos = 0 ;
class ILCls implements ILIntf {
Elem next() {
Elem e = ilout.get(pos) ;
pos++ ;
return e ;
} ;
Elem start(){
ilout.start() ;
pos = 0 ;
}
boolean hasNext() {
if (pos < ilout.count())
return true ;
ilout.end() ;
return false ;
} ;
void remove() {...} ;
}
attach clin to ILCls ;
3. MODELING COMPONENTS
A component in A COEL consists of (1) an external contract made of typed input and output ports, and (2) an
internal implementation consisting of classes, methods,
and data fields. A client can only see the external contract and the internal implementation is completely encapsulated. A component provides services via its input
ports, and specifies the services its requires via its output ports. In A COEL, a connect statement makes an explicit connection between an output port of a component
to a “compatible” input port of another component. Let
connect c1 po to c2 qi be a connect statement. For this
connection to be compatible, it is necessary that qi <: po .
The sub-type relation ensures that any message sent over
the connection by c1 can be processed by c2 . But the subtype relation is not sufficient to ensure port compatibility. In A COEL, we enforce other kinds of constraints using C ORAL.
We use a framework that is similar to input/output
automaton (IOA) to model A COEL components. Abstractly, a component automaton (CA) consists of a set
of actions, a set of state, and a set of transitions. The
set of actions are classified as either input actions in(A)
(corresponding to messages arriving at input ports), output actions out(A) (corresponding to the requirements at
output ports), and internal actions int(A) (corresponding
to internal calls). Let acts(A) = in(A) out(A) int(A).
Similar to IOA, a CA A consists of the following four
components:
h i
h i
[
A client component has to first explicitly connect to
a component before obtaining the services. Notice that
ListIterator can invoke services of List component
127
[
sig (A), a signature
coral ListAutomaton {
types:
Iter {
int id ;
enum st = {active, passive} ;
}
states:
int srcId ;
List l ; // list type
Iter iter[] ; // a hash of iterators.
transitions:
input void CLIntf.add (int index, Elem e) {
pre:
(forall i iter[i].st==passive) &&
(l.length < index)
eff:
l.insert(index, e) ;
error:
throw AddException ;
}
input void CLIntf.remove(int index, Elem e) {
pre:
(forall i iter[i].st==passive) &&
(l.length < index)
eff:
l.remove(index, e) ;
error:
throw RemoveException ;
}
states(A), a set of states (not necessarily finite)
start(A) states(A), a set of start or initial states
trans(A) states(A) acts(sig (A)) states(A),
a state-transition relation, such that for every state
s and every input action , (s; ; s0 ) 2 trans(A).
An action is enabled in a state s if (s; ; s0 ) 2
trans(A). Input actions are enabled in every state (i.e.,
a component cannot block messages arriving at its input ports). This is not a big restriction, since almost always we can throw an error condition for messages that
a component cannot handle (also, we can use the type
system to ensure that no arbitrary message arrives at input ports of a component).
There are few differences between a regular IOA and
the kinds of programs that we are dealing with in
A COEL. First, components in A COEL can be dynamically created and destroyed. Also, each component has
its own state. In A COEL there are no global variables
and methods. Since component instances are dynamically created and destroyed, an IOA model should include actions for creation and destruction of automaton
and for modeling system of automaton. To model dynamic creation of components, we introduce a create action crt(A) that corresponds to creation of an automaton
A. The crt(A) will also invoke the constructor function
that modifies the state of A. The create action crt(A)
can be thought of as an input action to the newly created automaton A, and the input action will invoke the
constructor methods of the corresponding component.
The create action will be executed by another automaton
for creating a new automaton. At any instance, only a
finite set of automaton exists. We can think of a configuration as a finite set A1 ; s1 ; : : : An ; sn , where Ai ,
for 1 i n, is automaton identifier and si is the state
of Ai . An action essentially changes a configuration
to a new configuration 0 , a create action will add a new
automaton to , and all other action will simply change
the states of existing automaton.
C
fh
C
i
h
C
input Elem CLIntf.get (int index) {
pre:
(l.length < index)
eff:
error:
throw GetException ;
}
input CLIntf.iterator () {
pre:
eff:
// add a new iterator to iter
int newsrcId = create ListIterator
iter.add(newsrcId) ;
return newsrcId ;
}
input ILIntf.start() {
pre:
eff:
iter[srcId].st = active ;
}
input ILIntf.end() {
pre:
eff:
iter[srcId].st = passive ;
}
input Elem ILIntf.get (int index) {
pre:
(iter[srcId] == active)
(l.length < index)
eff:
error:
throw GetException ;
ig
C
4. THE C ORAL LANGUAGE
In this section we will briefly introduce C ORAL using
the iterator pattern example. Our intention is only to expose the core ideas behind C ORAL. A component automaton (CA) consists of two main parts: (1) states
and (2) transitions. The states part consists of a
set of state variables, whose types can be either primitive or composite data types. Primitive data types include char, string, int, float, and reference type.
Composite data types can be either in-built types or userdefined types. In a types part one can define new data
types (see Figure 2). The transitions part consists
of a set of state transition written in the style of precondition-effect-error for each action. This is illustrated
in ListAutomaton, a C ORAL automaton for the List
component (see Figure 2). For each action, we list the
pre-condition part, the effect part, and the error part.
Whenever the pre-condition part is satisfied, the eff
part is executed otherwise the error part (if defined) is
}
input ILIntf.remove() {
pre:
(iter[srcId] == active) &&
(forall i and i!=srcId
{iter[i].st==passive} ) &&
(l.length < index)
eff:
l.remove(index, e) ;
error:
throw RemoveException ;
}
}
Figure 2: C ORAL for List component.
128
executed. The eff part essentially performs state transformations.
For the example in Figure 2, the states part consists
of three states: srcId is the identity of the source component that is invoking the input action. l is a list with
operations such insert, remove, etc. An insert operation will add an element to l and changes the state
of l to a new l. The iter state keeps track of all iterators that a client created. A create operation will essentially create a new iterator identity and saves it in iter.
Consider the input action CLIntf.add(), the eff part
will be executed only if all the iterators in iter[] are
passive and the index is less than the length of the list.
Otherwise the error part is executed.
We essentially translate a CA to an IOA, and then verify properties in IOA. An input action in CA also returns
a value (which can either a normal value or an error condition). So an input action in CA is translated into a input action followed by an output action in IOA. The purpose of the output action is to return a value or an error
condition back to source component. We do the same
for an output action in CA (i.e., it is also broken into an
output action followed by an input action).
Unlike in IOA, in CA we typically do not perform
composition operation explicitly—we typically verify
whether a composition is a valid composition, and the
actual composition is effected by subtype relation between ports via connect statement. There are two
kinds of verification we are interested: invariance and
reaching an error state. An invariance is a property that
is true in all reachable states. Reaching an error state
means that a pre-condition fails and an “error” state is
reached. An execution of an automaton is a finite sequence of so ; 1 ; : : : ; n ; sn , with s0 being a start state of
the automaton. A state is reachable if it occurs in some
execution. Our main goal is verification of safety properties (rather than liveness or fairness properties).
Let us briefly illustrate one kind of verification problem, called concurrent modification problem (CMP).
This problem was motivated from Ramalingam et
al. [18]. We have simplified the problem from what is
described in Ramalingam et al. [18]. The main problem
with CMP is that when an iterator is active a modification to the underlying aggregate structure can cause an
inconsistency between the iterator and aggregate structure. Most implementation of an iterator pattern will allow modification to an aggregate structure only through
the iterator (especially when an iterator is active). Let
us slightly modify the client code given in Section 2 and
include the statement l.add(0,e) in the while-loop.
l.add(0,e) ;
}
}
In the ListAutomaton the precondition for l.add
will fail since an iterator in iter state may still be active. Although the above example looks trivial there are
many non-trivial phases that one has to go through before coming to the conclusion. For instance, we need
alias analysis information to disambiguate different iterators. We need to use theorem proving techniques
to verify invariants defined in the pre-conditions. We
have used end() method to explicitly terminate an iterator. Compared to Ramalingam et al., our approach
gives very conservative result. It is to be noted that our
intention in using CMP is only to illustrate the use of
IOA for verifying this, albeit simplified, problem.
5. DISCUSSION AND RELATED WORK
Verifying software system is an age-old, but certainly
not a solved problem. Many specification and verification techniques have been proposed in the literature
for ensuring that software systems are safe and wellbehaved [2, 14, 24, 3, 12, 7, 20]. With the advent of the
Internet-based applications it is even more important to
ensure safety and security of software system. In this
paper we presented C ORAL for abstracting and specifying requirements of A COEL components. We used
IOA for modeling A COEL components. Typically in the
past, IOA has been used to model distributed system.
In C ORAL we use IOA to verify whether a component
when plugged into a system will behave correctly, and
also whether a client of the component will use the component correctly or not. C ORAL can be used to verify other kinds of constraints such a protocol verification [25]. We can simply encode the correct sequences
of method calls using an automaton.
This paper presents a preliminary experience of using IOA for software verification. There are many openended problems that needs to be resolved. Handling
aliasing, sub-type polymorphism, etc. presents some interesting challenges. Recently Attie and Lynch proposed
dynamic IOA that can handle dynamic creation and destruction of automaton. Rather than thinking in terms
of single automaton, dynamic IOA goes one step further
and defines a configuration of interacting automata [4].
We are currently exploring on how to use the full potential of dynamic IOA in C ORAL. For verification purposes we have to deal with practical programming languages which typically include aliasing and polymorphism. Unlike IOA, our main goal is verification of components. One component can be connected to another
component through their ports if the corresponding port
types have a sub-type relation (i.e., the input port should
be a subtype of the output port). We use C ORAL to go
beyond subtype relation and verify other kinds of constraints [16].
Model checking is a classical approach to verification
of software systems [8]. Bandera is a collection of tools
for model-checking concurrent Java programs [9]. It
takes Java source code, compiles them, and generates
code for verification tools like SMV and SPIN. SLAM
component Client {
out CIIntf ciout ;
out CLIntf clout ;
main() {
List l = new List() ;
connect clout to l.clin ;
// add a bunch of elements ...
ListIterator li = l.iterator() ;
connect ciout to li.ciin ;
while(ciout.hasNext() {
Elem e = ciout.next() ;
129
project is very similar to Bandera project, except that
SLAM also uses predicate abstraction and discovery to
point errors in C code [5]. Strix is specification language for expressing business process and a Strix compiler once generates code for SMV model checker [6].
CANVAS uses EASL specification and translate them to
a 3-valued logic for verifying program properties [18].
JML is a Java Modeling Language and it uses designby-contract and Larch theorem prover to verify program
properties [15]. There are several other projects related
to software verification.
Another important, but related, area is the Architecture Description Language (ADL) [19]. A software system is typically starts off with a requirement and a design phase. During this phase, the implementation details are typically ignored and the focus is on understanding and developing software architecture. ADLs
are typically used at this phase to specify the structure
and the requirements of a software system. ArchJava is
an example of integrating ADL with Java [1]. C ORAL
can be used as a ADL. One can express the requirements
of A COEL components, even before implementing them
using C ORAL. To use as an ADL, we need a way to compose component automaton. For this we rely on IOA
theory of composing automaton.
[4] Paul C. Attie and Nancy A. Lynch. Dynamic
input/output automata: a formal model for
dynamic systems. In CONCUR’01: 12th
International Conference on Concurrency Theory,
LNCS. Springler-Verlag, 2001.
[5] T. Ball and S. Rajamani. Checking temporal
properties of software with boolean programs. In
Proceedings of the Workshop on Advances in
Verification, 2000.
[6] B. Bloom. Seeing by owl-light:Symbolic model
checking of business application requirements.
Technical Report ????, IBM T.J. Watson Research
Center, 2001.
[7] William Chan, Richard J. Anderson, Paul Beame,
Steve Burns, Francesmary Modugno, David
Notkin, and Jon D. Reese. Model checking large
software specifications. IEEE Transactions on
Software Engineering, 24(7):498–520, July 1998.
[8] Edmund M. Clarke, Orna Grumberg, and David E.
Long. Model checking and abstraction. ACM
Transactions on Programming Languages and Systems,
16(5):1512–1542, September 1994.
[9] James C. Corbett, Matthew B. Dwyer, John Hatcliff,
Shawn Laubach, Corina S. Pasareanu, Robby, and
Hongjun Zheng. Bandera: extracting finite-state
models from java source code. In International
Conference on Software Engineering, pages 439–448,
2000.
[10] Martin Fowler and Kendall Scot. UML Distilled:
Applying the Standard Object Modeling Language.
Addison-Wesley, 1997.
[11] Erich Gamma, Richard Helm, Ralph Johnson, and
John Vlissides. Design Patterns: Elements od Reusable
Object-Oriented Software. Addison-Wesley
Publishing Company, New York, NY, 1995.
[12] S. Garland, J. Guttag, and J. Horning. An overview
of Larch. In Functional Programming, Concurrency,
Simulation and Automated Reasoning, pages 329–348.
Springer-Verlag Lecture Notes in Computer
Science 693, 1993.
[13] S. Garland and N. Lynch. Using i/o automata for
developing distributed systems. In Gary T.
Leavens and Murali Sitaraman, editors,
Foundations of Component-Based Systems, pages
285–312. Cambridge University Press, 2000.
[14] M. Goedicke, H. Schumann, and J. Cramer. On the
specification of software components. In
Jean-Pierre Finance, editor, Proceedings of the 6th
International Workshop on Software Specification and
Design, pages 166–174, Como, Italy, October 1991.
IEEE Computer Society Press.
[15] Gary T. Leavens, Albert L. Baker, and Clyde Ruby.
JML: a java modeling language. In Formal
Underpinnings of Java Workshop (at OOPSLA ’98),
1998.
[16] B. H. Liskov and J. M. Wing. A behavioral notion
of subtyping. ACM Trans. Prog. Lang. and Sys.,
16(1):1811–1841, November 1994.
[17] K. L. McMillan. Symbolic Model Checking. Kluwer
Academic Publishers, Norwell Massachusetts,
6. CONCLUSION
In this paper we briefly introduced C ORAL as a language for abstracting and specifying A COEL components. C ORAL is based on IOA. Unlike classical IOA, our
intention in using the theory of IOA is for verification
of software components. We are currently working on
three aspects of C ORAL. First we are refining on the syntax and semantics of C ORAL. Second, we are focusing
on the dynamic IOA model for C ORAL. Finally, we are
looking at ways to model aliasing, sub-typing, classes,
and other states within IOA. Both A COEL and C ORAL
are at design stages, and we are at initial stages of implementation. We expect to publish more details of C ORAL
in the near future.
Acknowledgement
I thank Deepak Goyal for valuable discussions and comments on an earlier draft of the paper.
7. REFERENCES
[1] Jonathan Aldrich and Craig Chambers. ArchJava:
connecting software architecture to implmentation.
Technical Report UW-CSE-01-08-01, Univ. of
Washington, August 2001.
[2] Dean Allemang. Extending the applicability of
formal verification techniques. In Gary T. Leavens
and Murali Sitaraman, editors, Proceedings of the
First Workshop on the Foundations of
Component-Based Systems, Zurich, Switzerland,
September 26 1997, pages 1–10, September 1997.
[3] R. Allen and D. Garlan. A Formal Basis for
Architectural Connection. ACM Transactions on
Software Engineering and Methodology, 6(3):213–249,
June 1997.
130
1993.
[18] G. Ramalingam, A. Warshavsky, J. Field, and
M. Sagiv. Deriving specialized heap analyses for
verifying component-client conformance.
Technical Report RC22145, IBM T.J. Watson
Research Center, August 2001.
[19] Mary Shaw and David Garlan. Software
Architecture: Perspectives on an Emerging Discipline.
Prentice-Hall, 1996.
[20] Murali Sitaraman, Lonnie R. Welch, and
Douglas E. Harms. On specification of reusable
software components. International Journal of
Software Engineering and Knowledege Engineering,
3(2):207–229, 1993.
[21] Alan Snyder. Inheritance and the development of
encapsulated software components. In Bruce
Shriver and Peter Wegner, editors, Workshop on
Object-Oriented Programming, pages 165–188,
Camebridge, MA, 1987. MIT Press.
[22] Vugranam C. Sreedhar. A COEL: A
component-oriented extensional language.
Technical report, IBM T.J. Watson Research Center,
2001.
[23] Vugranam C. Sreedhar. York: Programming
software components. In Joint 8th European Software
Engineering Conference and 9th ACM SIGSOFT
Symposium on the Foundations of Software
Engineering, 2001. Poster session.
[24] D. Yellin and R. Strom. Protocol specifications and
component adaptors. ACM Transactions on
Programming Languages and Systems, 19(2):292–333,
1997.
[25] Daniel M. Yellin and Robert E. Strom. Protocol
specifications and component adaptors.
Transactions on Programming Languages and Systems,
19(2):292–333, March 1997.
131
Non-Functional Requirements in a Component Model for
Embedded Systems
Position Paper
Roel Wuyts
Stéphane Ducasse
Software Composition Group
Institut für Informatik
Universität Bern, Switzerland
Software Composition Group
Institut für Informatik
Universität Bern, Switzerland
[email protected]
[email protected]
ABSTRACT
In this paper we describe an interesting context to study
formal methods for component systems: embedded devices.
The context of embedded devices is highly constrained by
the physical requirements the devices have to adhere to.
As a result, component models for embedded devices are
not general purpose but geared towards these constrained
contexts. In this paper we give the concrete setting of the
Pecos project (a project with as goal component engineering
for embedded devices). We describe the Pecos component
model, and show possibilities where we think formal verification could be useful. We would like to use this as a very
concrete example to discuss formal verification techniques.
1.
INTRODUCTION
Software for embedded systems is typically monolithic and
platform-dependent. These systems are hard to maintain,
upgrade and customise, and they are almost impossible to
port to other platforms. Component-based software engineering would bring a number of advantages to the embedded systems world such as fast development times, the ability to secure investments through re-use of existing components, and the ability for domain experts to interactively
compose sophisticated embedded systems software [7].
The goal of the PECOS (PErvasive COmponent Systems)
project (a European Esprit project) is to find solutions for
component oriented development (COD) for embedded systems . In this context we are developping Comes (a general
Component Meta-Model) and the Pecos Model (a specialization of Comes targeted towards embedded systems in the
context of the project).
In Comes, components are black-box encapsulations of behavior. They have interfaces that consist of properties and
ports, can contain subcomponents, and have consistency
rules that express structural integration internal to the component (for example, to check dependencies between properties). The ports of components are connected by explicit
connectors. Consistency rules of the composite component
can reason about the properties of the composite, but also
on the connectors and the properties of the sub components.
The Pecos Model is a specialization of Comes to explicitly
support components for embedded devices in the context of
the Pecos project. Interesting is that this puts a lot of extra constraints on the component model. We firmly believe
that this will allow us to use formal (mathematical) techniques to verify non-functional requirements of the modeled
components. More specifically, we want support regarding
timing and scheduling and memory consumption.
For this workshop we see ourselves as the providers of an interesting problem and problem context. We believe that the
extra constraints imposed by the context of our component
model make it a good example to use and assess the functionality of formal techniques. Coming from a practical, less
formal discipline of software engineering and programming
language design, we want to discuss with the more mathematically enclined researchers on how to come to formal
support for specifying and checking components.
In the rest of the paper we introduce the specific problem
context of embedded systems in more detail. Then we show
the current version of the component model. Finally we
enumerate the places where we think that formal techniques
could help us, and discuss techniques we think are of interest
to us.
2.
THE EMBEDDED SYSTEMS CONTEXT
A massive shift is going from desktop applications to embedded systems, where intelligent devices taking over roles
that are currently done in desktop applications. Moreover,
the capabilities of embedded devices augment rapidly, and
their responsibilities increase likewise. Distributed embedded devices (intelligent field devices, smart sensors) not only
acquire but also pre-process data and run more and more
sophisticated application programs (control functions, selfdiagnostics, etc.).
The drawback of this evolution is that the software needs
132
to follow. Here the story is less positive: the software engineering techniques that are typically employed are lacking
far behind software engineering techniques for mainstream
applications. Currently software for embedded devices is
written in assembly or C, in a monolithic fashion, with a
typical development time of two to three years. The reasons
for this are two-fold. The first reason is the specific context of embedded devices (with all the constraints of power
comsumption and simple hardware as a result of this). The
second reason is that, up until a couple of years ago, the market for embedded devices was relatively small, and was thus
neglected by the big players from desktop applications. For
example, operating systems or development environments
are hard to find for embedded systems.
The goal of the PECOS (PErvasive COmponent Systems)
project is to apply solutions for component oriented development (COD) in the context of embedded systems. As in
desktop applications, the overall goal is to have more reuse,
higher quality and reduced development time. Key factor
in the project is the component model to support components for embedded systems. Before we have a look at this
model, we first introduce the Pecos component development
process, and field devices, the embedded systems the Pecos
model should support.
2.1
Pecos Process
Part of the solution of the Pecos project is a component development process. In this section we give a quick overview
of this process, as this will help to introduce some choices
made in the Pecos Component Model. The process consists
of two main phases: the component construction phase and
the field device assembly phase.
The component construction phase defines what is needed
to develop a single component (that possibly contains subcomponents), instrument it (to provide information about
runtime aspects of the component), and put it in the component repository. It specifies the following workflow:
• the component is created. This means defining the
basic properties and the interface of the component.
• the subcomponents are filled in. If the component has
subcomponents, then these subcomponents need to be
selected from the repository and added to the componenent. They also need to be connected with each
other.
• the component is checked. In this phase, a structural
check is performed to make sure that everything is
specified according to the model, and that the given
information follows the rules in the model. For example, when the model specifies that a component should
have a name, then this is checked at this moment.
Also, when type information needs to be given it is
checked that the given types exist. Or, if there are
subcomponents, their connections are checked.
• generating skeleton code. When the check succeeds,
meaning that the component’s structure is verified,
skeleton code can be generated.
133
• filling in the skeleton: the skeleton code has to be extended into a full working implementation.
• instrumenting the component: the component is then
ready to be instrumented. In this phase it is deployed
in a standard environment so that certain runtime information can be gathered. What information depends
on the model. Since in the Pecos model we want to
check scheduling information and memory consumption, basic figures need to be extracted. Note that we
need the instrumentation because we see components
as black-box abstractions where we have no idea about
their internals. If this constraint is lifted, the instrumentation phase could be made simpler or even omitted. We discuss this in more detail when we discuss
the non-functional checks.
• the instrumented component is then added to the component repository.
A second activity is to assemble components into field devices (the actual embedded systems that need to be modeled
in the context of Pecos). This activity consists of the following steps:
• select a template for the field device that needs to be
created
• select the components that need to be filled in to instantiate the field device
• connect the components
• perform structural checks on the instantiated field device
• perform non-functional checks using the information
provided by the components. For example, make sure
that the total power consumption of the chosen components does not exceed the limit of the Field Device,
or that a schedule can be found to schedule the components.
• generate the code for the field device
• deploy the component on the actual hardware
In the next section we have a look at Field Devices, the
actuall embedded systems used in the project. Then we introduce the model to support the specification and checking
of these devices.
2.2
Field Devices
Field devices are embedded reactive systems. A field device
can analyze temperature, pressure, and flow, and control
some actuators, positioners of valves or other motors. Field
devices impose certain specific physical constraints For example a TZID (a pneumatic positioner) works under the
following very hard constraint: the available power is only
100 mW for the whole device. This limits severely the available CPU and memory resources. The TZID uses a 16 bit
micro-controller with 256k ROM and 20k RAM (on-chip),
and communicates using fieldbus communication stacks (an
interoperability standard for communication between field
devices). The device has a static software configuration,
i.e., the firmware is updated/replaced completely, and there
is no dynamic loadable functionality.
As a result from the physical constraints (especially the very
harsh power consumption requirements), the runtime environment and the software are subject to the following constraints:
3.1
Requirements
The goal of the Pecos Component Model is to be able to
model and check a field device. More specifically, it has to
allow:
• to specify individual components (that can contain
subcomponents);
• to connect components;
• One processor: all the components composing a field
device are running on a single processor, that is very
slow when compared to mainstream processors.
• One monolithic piece of code: after assembling the
different components that compose a field device, the
software for the field device forms one single piece that
is deployed.
• No dynamic change: At run-time (after the field device is initialized) there is no memory allocation, nor
dynamic reconfiguration.
• Single language per application: a component is created in a single language like C or C++.
• Multi-threading: field device components can be running on different threads. The scheduling is carried out
by either the OS or by an explicit scheduler. However,
most of the components are passive and scheduled by
a central scheduler. Components that are active (that
have their own thread) are typically the ones close to
the hardware. They are responsible for regularly reading values from this hardware, such as the current motor position or speed.
• Components communicate by sharing data contained
in a blackboard-like structure. Components read and
write data they want to communicate to this central
memory location.
• Some components are described by state automata.
Some components have state, others are stateless because they are only representing algorithms.
• Components only offer interfaces in terms of in/out
ports. The component state automata definition, or
other behavorial descriptions, are not available. This
is a very hard requirement, as this means that a lot of
existing formal verification techniques are not usable.
• A field device architecture is fixed. It is composed by
an Analog component controlling the overall workings
of the device, a Transducer component that interfaces
to the hardware, a HMI component for the HumanMachine interaction and an EEPROM component to
store data in non-volatile memory.
3.
THE PECOS COMPONENT MODEL
The Pecos Component Model is the foundation of the Pecos
project. Its goal is to allow to specify and check components
and Field Devices, given the constraints given above. In
this section we iterate over the requirements for the model,
introduce its main aspects. In the next section we then look
at how formal techniques could be applied in this context.
134
• to assemble components into Field Devices;
• to check the structure and well-formedness of component compositions and Field Devices;
• to check non-functional requirements of Field Devices.
More specifically, timing and scheduling of components,
and their memory consumption;
3.2
Model Overview
In the constraints imposed by the context of embedded systems on field devices we already saw that Field Devices follow a blackboard-like achitecture. Hence, there is a central
block of memory (called the Object Manager, or OM for
short) that holds all the values that need to be passed between components in a field device. The OM is filled when
the field device is initializad. At runtime, its structure does
not change (as there is no allocation at runtime after the
initialization). Components that need to share data to do
by writing and reading from the OM.
Normally, when components would all be running in their
own thread and hence in parallel, locking and synchronization of the OM would certainly be needed. However, in the
specific context of a field device such a solution,(typical solution for desktop applications), is not possible. The reason is
that it’s too expensive in both processing power and memory
consumption, and that OS facilities to support locking and
synchronization are not always available or very costly. Field
devices solve the problem by providing one central scheduler
that sequentially schedules all components. Hence, at any
moment in time, only one component has access to the OM
and thus no locking is needed. Of course, this introduces
other problems as well, that we will discuss in detail later
on when we talk about supporting (checking) non-functional
requirements.
The Pecos model builds on our experiences with supporting Software Architectures using logic programming languages [6]. The main constituents are components, ports
and connectors:
• component: a Pecos component has a name, contains
information regarding scheduling and memory consumption (see further), has a list of data ports and possibly
has a list of subcomponents and connectors for these
subcomponents;
• data ports: a data port indicates that the component
provides or needs data for other components. It contains a type (of the data that will be passed, such as
Float), a direction (in, out or inout),
• connectors connect data ports of components, and hence
model a data dependency between two ports. Connectors contain the names of the component and the ports
they connect
Besides this structural information, we also check some Pecos
specific constraints, such as type and range information on
ports. Table 1 lists all the structural checks that can be
performed.
Besides the components and connectors, the Pecos model
also offers a Field Device template. This is a template component that has to be instantiated with 4 concrete components. The Field Device component specifies the structure
and the behaviour of a field device in such a way that its
structure and semantics can be checked, and that code can
be generated from it. To instantiate the field devoce, four
components and their connections that have to be specified:
• Human Machine Interface Component: a field-device
can be equipped with displays and other devices so
that users can inspect or modify the behaviour from
the device itself
• Non-volatile memory Component: the state of the component needs to be written to certain kinds of memory
• Input-Output-Controller Component: the data from
the device component typically consist of raw values
that are immediately related to the hardware contained.
The function of this component is to provide an interface to the other non-hardware related components
that is not hardware specific. For example, it can scale
raw data from the hardware so that the display can
show the value of a temperature controller in degrees
Celsius.
• Device Component: all components that deal with the
hardware are encapsulated by this component.
The result is a Field Device that can be checked for wellformedness (making sure that everytthing conforms to the
structural rules) and for non-functional requirements. These
last checks are the topic of the following section.
4.
CHECKING OF NON-FUNCTIONAL REQUIREMENTS
The previous sections described the context of field devices
and the Pecos component model to model components for
field devices. However, it didn’t give much information
about the checking of non-functional requirements. In this
section we describe what we would like to support, and what
we are currently doing. We also give information about related formal work that we think could be useful (but that
we not use at the moment of writing).
In the Pecos project we want to support two issues, that we
have already touched upon throughout the paper: scheduling of components and memory consumption. We explain
these two issues in more detail, and then have a look at
opportunities we see for formal verification.
135
4.1
Component Scheduling
We already explained that in field devices we do not want
to use regular locking of data, but instead want to schedule
the components sequentially such that this is not needed.
Hence, a very important aspect that needs to be checked
when a field device component is instantiated is the scheduler.
More specifically, we currently instrument every individual
component with information regarding its execution time
(the time it takes to execute its behaviour once) and with information about its cycletime(the number of times it needs
to be executed in one scheduler cycle). Using this information (combined with the information of the data dependency provided by the connectors) we are now investigating whether it is possible to derive or check a scheduler.
The hardest thing to solve is that we currently identified
three kinds of components: passive components, active components and event components. Passive components are
straightforward to handle: they just need to be scheduled
by the scheduler such that their execution and cycling information is met. Active components are more difficult. The
reason is that they have their own thread that is running
inside of the component. This thread is typically used to
read-out values directly from hardware, such as the current
speed of a motor. In the current implementation used in
field devices, these values write to internal fields in the component, and when the component is scheduled the values
in the internal fields are copied to the OM. Hence, active
components are scheduled and handled exactly as passive
components, even though they have their own thread. We
are currently debating whether this is a good solution, and
what would be alternatives. Event components pose the
same problems as active components. They do not have
their own thread, but act as event sinks that have to capture and react to events sent by certain pieces of hardware.
Just as with active components, they capture an event, wait
until they are scheduled by the scheduler and then handle
the event.
At the moment of writing we are still investigating possible
solutions to check and generate the scheduler, with probably the most interesting option to express all the scheduler
constraints using Constraint Logic Programming over Real
Numbers (CLP(R)), and calculate possible schedules. By
the time of the workshop we will have a concrete solution
for this problem, as this is currently under full development.
4.2
Memory consumption
Due to the minimal memory available in field devices, the
memory occupied by a component is a crucial information.
The model should support the computation of the component size and checks for component substituability.
To perform the checks, every component is instrumented
with the size it needs for its code and for its data. This
should then be summed and combined with the information
from the blackboard.
4.3
Possibilities for Formal Verification
We are thinking to lift the constraint that components are
completely black-box, and adding and using state charts as
a way to describe the behavior of components. When we
Port
Component
Connector
Table 1: Structural Checks in the Pecos Component Model
The type of the property can only be one in a fixed set (Float, Tfloat, Tscale, . . . );
The direction should be in, out or inout;
The location of a port has to be ’static’, ’dynamic’, or ’nv’;
The minimum in the range is smaller than the maximum.
The State can only be active, passive or ’event’;
All the numbers regarding timing and code sizes should be positive or 0..
Connectors can only connect out and in; ports;
The types of the ports should be compatible;
The ranges of ports should be compatible;
do this, we can think of using synchronous languages such
as Esterel [1], Argo/Argonaute [5], Lustre [3], CRP [2] and
combined approaches [4].
Especially Esterel seems a natural candidate to use in the
context of embedded systems. It is a synchronous and imperative concurrent language dedicated to control-dominated
reactive programs which are found in real-time process control, embedded systems, supervision of complex systems,
communication protocols and HMI. In Esterel, programs
are abstractions that manipulate input signals and generate output signals. Once programs are expressed in Esterel
they can be formally proved (i.e., non-reachability of state,
timing constraints), compiled to C in a compact form, and
simulated. In the context of Pecos, Esterel seems particularly interesting because the size generated is suitable for
field devices and, more important, timing issues and memory consumption can be verified:
• it allows the verification that given an input, the output of a program is comprised in a certain amount of
cycles of the input. This means that component substitution could be verified.
• it allows different code generation schemas. The first
one is boolean generation. By counting the number
of instructions the exact size of a component and its
exact execution time can be counted. The second is
condition-based and can provide maximum execution
time for a component.
Another possibility would be to look at the formalism of
timed state automata, to take timing information into account.
5.
CONCLUSION
In this paper we describe the context of embedded systems,
for which we made a component model to specify and check
Field Devices (a particular kind of embedded system). Due
to the physical constraints imposed on embedded systems,
a component model for embedded devices has very specific
constraints: no runtime allocation, no locking or synchronization, and a simple scheduler. We describe the Pecos
Component Model that we are developing, and that allows
to specify and check Field Devices and their components.
The most interesting aspect of the model is that we want to
check certain non-functional requirements before the software for the field device is deployed in the hardware. This
is still under ful development. We showed the current status
136
of the checks, and where we suspect that formal techniques
could be welcomed. In the workshop we want to discuss
with people from the formal community, using our context
as a test case.
6.
REFERENCES
[1] G. Berry. The foundations of Esterel. MIT Press, 2000.
Editors: G. Plotkin, C. Stirling and M. Tofte.
[2] G. Berry, S. Ramesh, and R. K. Shyamasundar.
Communicating reactive processes. In ACM, editor,
Conference Record of the Twentieth Annual ACM
SIGPLAN-SIGACT Symposium on Principles of
Programming Languages: papers presented at the
symposium, Charleston, South Carolina, January
10–13, 1993, pages 85–98. ACM Press, 1993.
[3] N. Halbwachs, P. Caspi, P. Raymond, and D. Pilaud.
The synchronous data flow programming language
lustre. In Proceedings of the IEEE, September 1991.
[4] F. M. M. Jourdan, F. Lagnier and P. Raymond. A
multiparadigm language for reactive systems. In
Proceedings of the IEEE Internal Conference on
Computer Languages, 1994.
[5] F. Maraninchi. The argos language: Graphical
representation of automata and description of reactive
systems. In Proceedings of the IEEE Internal
Conference on Visual Languages, 1991.
[6] K. Mens, R. Wuyts, and T. D’Hondt. Declaratively
codifying software architectures using virtual software
classifications. In Proceedings of TOOLS-Europe 99,
pages 33–45, June 1999.
[7] C. A. Szyperski. Component Software. Addison-Wesley,
1998.