HOSPITAL INTERDISTRITAL “EVITA” Ciudad de Formosa

With the classes verified, we have the basis to verify if the whole system imple- mentation satisfies its specification. The verification technique developed by Din et al. can be used to verify a system implementation by inferring the system spec- ification from the invariants of each actor of the system. When these actors are fixed and the creation of actors does not depend on the system’s interaction with its environment, this compositional approach is appropriate for proving that the system specification is fulfilled by the implementation. However, as seen in the server example, the creation of the worker actors depends on the query sent by the clients of the server. Therefore, the verification process must deal with an unbounded number of actors. To work around this issue, we introduce a static component notion.

The main idea is to designate a specific activator class and form a component in-

stancebased on the actors transitively created by an actor of that activator class. We call the initial actor of the component instance as the head actor. To illus- trate this idea using the server system example: consider a server actor s that has received 2 queries. The first query consists of two subqueries while the second query consists of three subqueries. To process each query, s creates a worker actor that performs the computation. After completing the computation of all queries, the creation relation between the actors in the server system is captured by the

2.4. Verification s w1 w3 w2 w4 w5 s w1 w3 w2 w4 w5 [w1] [w2] s w1 w3 w2 w4 w5 [s]

Figure 2.3.: Server system’s actor creation structure after processing 2 queries and hierarchical componentization

left part of Figure2.3. Because each worker actor has exactly the same behavior, we can represent the behavior of a chain of worker actors (e.g., the w1, w3 and w₂, w₄, w₅ chains) as a single instance. Taking theWorkerclass to be an activator class, these chains become component instances with w₁ and w₂as the heads of these instances (middle part of Figure2.3). With the same principle, we can also compose together these component instances with s and produce a component instance headed by s (right part of Figure2.3).

What is common about these component instances is that each is derived from a specific class. The behavior of an instance of a class is predetermined by the class implementation. Consequently, the behavior of the component instance is also predetermined. The behavior of the server system can be represented by a component with the Serverclass as an activator class of that component. We have an entity, denoted by [Server], to refer to this component. This generic

representation of such component instances allows a specification to target a part of the implementation, instead of some specific actor name of class Server. For example, the specification of the server system (Equation (2.2)) can be designated to[Server] instead of a server actor named s and the worker actors transitively

created by s.

The verification on this tier is done by constructing a possibility map [LT87;

NS94] from the composed states of the subcomponent specifications to the states

of the component specification. Essentially, a possibility map requires the automa- ton representations of both subcomponents and the component to synchronize on external events, while allowing the subcomponents to progress when executing internal events. In its implementation, a component may dynamically create sub- component instances. Therefore, a state of a component implementation may consist of several substates of the subcomponent instances. In the automaton model, this state is a Cartesian product of the substates of the subcomponent

specifications enriched with information on the created instances. If a possibility map can be constructed, the trace of an execution of the component implemen- tation is a trace of the component specification. That is, the implementation does not produce some non-specified behavior.

For the implementation of the[Server] component, the external events are the

servecalls and the returns, while the events between the server actors and the worker component instances are internal. A possibility map p for the[Server]

component is roughly constructed as follows, where the states of the [Server]

implementation impl([Server]) is a tuple 〈ss, wn, m〉 consisting of

• the server actor’s state ss,

• a set of names of the [Worker] instance’s head actors, and

• a map from the head actors to a [Worker] state.

∀〈ss, wn, m〉 ∈ states(impl([Server])), y ∈ states([Server]) :

(First(ss) = First(y)) =⇒ p(〈ss, wn, m〉) = y The formula above maps a state of the[Server] component implementation to

a state of the [Server] component specification when the set of futures stored

in the server actor’s specification state and the server component specification state is the same. The function First collects the first elements of all tuples in a set of tuples, which in the case of the server actor and the server component are the futures attached to theservecalls. It can be checked that theservecalls and returns are indeed simulated correctly when the component’s implementation and specification are in the states where the mapping condition is fulfilled. The actual possibility map for the[Server] component and its implementation is more

involved because the actor characteristics and the automaton representation must be taken into consideration. A more precise discussion on this possibility map is deferred to Chapter12.

The rest of this thesis provides the details of this automaton-based verification framework, starting by providing a sound basis for the implementation language

C

HAPTER

3

α

ABS

: Syntax and Semantics

A sound basis for a system’s implementation is crucial to perform formal verifica- tion. We base the implementation on the languageα

ABS

, a kernel object-oriented language that combines actor model with non-shared futures. This language can be seen as an intersection between the modeling languages

Creol

[JOY06] and

ABS

[JHSSS11] and an enrichment of Rebeca [SJ11].

Chapter outline. This chapter formally describes α

ABS

and starts by explaining the features of α

ABS

more thoroughly. Then, Section3.2 describes the formal syntax ofα

ABS

and Section3.3presents its operational semantics. Apart from an operational semantics, we also describe a denotational semantics for theα

ABS

, but this description is postponed to the next chapter where we have a better toolkit to express the denotational semantics. Finally, Section3.4discusses the features ofα

ABS

in the context of related work.

3.1

Features

α

ABS

is a subset of

ABS

, a language developed for “design, analysis, and im- plementation of highly adaptable software systems”1, where distributed, object- oriented systems are identified as the highly adaptable software systems[IT95].

To achieve this goal,

ABS

locates itself between design-oriented and architec- tural languages such as UML[RJB04], minimalistic and foundational languages

such as π-calculus [Mil99], and object-oriented specification languages such as

JML[LBR06]. This allows

ABS

programs (or more precisely, models) to be ex- ecutable, while being more readily verifiable.

ABS

adopts the structures of full- scale programming languages such as Java and Scala, that permits a reliable trans- lation of

ABS

programs to these languages[AØVWW13]. A generic algorithm, for

example, can be written in

ABS

and verified, before translated to the full-scale languages for optimizations and actual usage. In fact, these aspects are exactly the advantages of using an abstract language[Pla13].

Following the actor model, communication between actors inα

ABS

are per- formed only via asynchronous method calls. This means that a method call is

non-blocking, allowing the code execution on an actor to directly proceed with the next statement. Any incoming call is transformed into a task whose duty is to execute the method body. An actor stores these tasks in its buffer.

Futures. A common pattern that appears in the actor model is the request/reply

pattern[HO09]. The interaction documented in this pattern consists of two parts:

• an actor sends a request along with its name to another actor, and

• receives a reply message from that other actor when the request computation result is ready.

One approach to tackle this pattern without having to expose the actor’s name is by using futures [BH77; Hal85; LS88]. Futures are proxies for values which

are to be computed. A future is either unresolved or resolved, where resolving a future means that the future is populated with a value. Initially, a future is un- resolved and once it is resolved, it cannot be resolved anymore. This resolution process is done transparently inα

ABS

via method returns. To obtain the value of a resolved future, it has to be claimed, which is done explicitly inα

ABS

. Apart from avoiding having to expose names, the use of futures also reduces the num- ber of methods that need to be declared because the computation result can be retrieved without having to explicitly perform another method call. Inα

ABS

, the futures are non-shared, meaning that a future is accessible only by its generator and cannot be passed around as a parameter of a message. While less flexible than sharable futures, their introduction provides an interesting challenge in terms of task coordination and verification.

Cooperative multi-tasking. To coordinate the progress of a task with other

tasks and the future resolutions, α

ABS

adopts the cooperative multi-tasking ap- proach[AGGS09]. In this approach, each task is categorized either as being ready, suspended, or active, such that a new task initially has a ready status. Following the actor model, there can be at most one active task at any time being executed by an actor. Other tasks can only be active if the active task explicitly gives up control or if it completes its computation.

Inα

ABS

, cooperative multi-tasking is presented through explicit introduction of release points. A release point is the point within an actor where an active task gives up control. A release point can be introduced because a task requires some condition on the internal state to be fulfilled or it waits for a future value to be resolved (i.e., the result of some method execution becomes available). It is also introduced by default when a task finishes its computation (i.e., it provides

3.2. Syntax ofα

ABS

In document Obras y Acciones de Gobierno 2015 (página 90-94)