2 Universidade Federal do Rio Grande do Norte (UFRN)

O artigo tem por objetivo analisar as ferramentas disponiveis no Sistema Integrado de Patrimonio, Administracao e Contratos - SIPAC que complementam os registros contabeis efetuados no Sistema Integrado de Administracao Financeira do Governo Federal – SIAFI no controle dos bens de consumo da Universidade Federal do Rio Grande do Norte - UFRN. Para responder a este questionamento, realizou-se um levantamento bibliografico acerca dos dois sistemas utilizados na referida instituicao, iniciando com um breve historico de cada um e, em seguida, trazendo uma explanacao geral dos objetivos e das funcionalidades dos sistemas. A pesquisa foi exploratoria, descritiva e avaliativa e o metodo estudo de caso, onde foi realizado um comparativo entre os principais relatorios utilizados no controle do Almoxarifado Central da Instituicao disponibilizados pelos dois sistemas, a fim de identificar as possiveis informacoes complementares disponiveis no SIPAC. A partir desta constatacao, conclui-se, que a implantacao do SIPAC foi de grande relevância no controle dos bens de consumo dessa instituicao de ensino superior por apresentar maiores informacoes sobre os itens armazenados no almoxarifado da UFRN.


Introduction
Computer systems are an integral part of everyday life.Therefore, dependabilityalong with its various dimensions (availability, reliability, safety, integrity, maintainability, and security)-has become a key issue in the design of such systems.Until recently, the concerns associated with dependability have been mostly on system design and implementation, and less attention has been paid to the need for the dynamic reconfiguration of dependable systems.However, this is set to change.For example, network systems design and autonomic computing are two application areas in which dependability and dynamic reconfiguration must be taken into account together.Modern network systems, such as access and backbone routers, have strong requirements for both 24x7 operation and managed software evolution (e.g. to allow network operators to dynamically deploy new QoS/ resource management and security strategies) [11].And in autonomic systems such as self-organized sensor networks [2], minimising the degree of human-manned reconfiguration is the central tenet.
The need for dynamic reconfiguration is a complicating factor in building dependable systems (irrespective of the reasons why dynamic reconfiguration is necessary), as it demands from software architects both appropriate rigour and planning for adaptability.Recent research has shown that systematic and integrated "specification-to-deployment" environments are promising approaches to architecting dependable systems; but few proposals have yet considered dynamic reconfiguration, and then only in particular application areas such as embedded systems [36], or have focused on specific aspects such as adaptive fault recovery [15].More specifically, previous work in this area has not yet considered a more comprehensive integration (and possible extension) of classical software architecture concepts, such as architectural styles [13] (we discuss the concepts of software architecture and architectural style in Section 2.2 below), and the most recent developments in reconfigurable runtime technologies, such as the adoption of reflective or aspectoriented programming techniques [23,24].
In this paper, we propose just such a generic approach to architecting dynamic reconfiguration in dependable systems.The proposed approach is built on our view that dynamic reconfiguration needs to be causally connected at runtime to a corresponding high-level architecture specification.In more detail, we propose two causally-connected models, as depicted in Fig. 1: a runtime-level model and an architecture-level model (Fig. 1 also depicts some of the services-e.g. the configuration management service-that we discuss later in the paper).Dynamic reconfiguration can be applied either through reconfiguration primitives at the runtime level or through architecture specifications at the architecture level-using, for instance, general-purpose architecture description languages (ADLs) or domainspecific languages (DSLs).Moreover, we argue that both foreseen and unforeseen reconfigurations should be supported.

Architecture-Level Model
Our previous publications [3,20] have focused on the design and implementation of our approach using two mature technologies-the OpenCOM reflective component runtime [10] and the Acme ADL [14].By providing a less technology-grounded overview of our approach, we aim in this paper at thinking forward about the more stringent requirements for dynamic reconfiguration in dependable systems.The remainder of the paper is structured as follows.The key elements of our approach to dynamic reconfiguration in dependable systems at the runtime and architecture levels (and causality relationships between them) are presented in Section 2. The issue of handling foreseen and unforeseen reconfigurations at both levels is then discussed in Section 3. Sections 4 and 5 summarise our implementation efforts to date, including a detailed case study, and is therefore an up-to-date account of our previous work [3,20].Section 6 is devoted to a discussion of related work, and Section 7 provides concluding remarks.

Dynamic Reconfiguration at the Runtime and Architecture Levels
The essential elements of our approach are summarised in the the following list (see also Fig. 1) and discussed in detail in the following two sub-sections: • reconfiguration primitives -used to initiate reconfiguration requests at the runtime level; • reconfiguration notification service -used to support causal connection between the runtime and architecture levels by enabling the former to notify the latter of any changes arising from calls to the reconfiguration primitives; • reconfiguration transaction service -used to atomically group sequences of calls to the reconfiguration primitives and also to enable rollback in aborted reconfigurations; • mapping from architecture-level concepts to runtime-level concepts -used to formalise the correspondences between the two levels; • configuration management service -used to map architecture level reconfiguration specifications onto sequences of calls to the reconfiguration primitives; • style enforcement service -used to embody and enforce rules and constraints on reconfigurations specified at the architecture level.

Runtime Level
A runtime defines a deployment and execution environment for software systems.Runtime-level models are becoming quite sophisticated in their capabilities for dynamic reconfiguration, providing (among other services) primitives that allow inspecting and adapting the structure of a system (i.e. its configuration) and its behaviour.Examples of such primitives-referred to as reconfiguration primitives in this paper-include addition, removal, and replacement of software elements, (dis)connection between such elements, (dis)closure of element interfaces, etc.Such reconfiguration primitives can be used to introduce dependable functionality in the system.
To motivate the functionality that should be provided at the runtime level, consider a dependable web-based client-server application.In a very simple configuration, two servers (primary and secondary) are involved.If the primary server is no longer available, the client is automatically switched to the secondary server.For this runtime-level reconfiguration to be causally connected with the architecture level, the runtime should provide a reconfiguration notification service to inform the architecture level about the calls to the reconfiguration primitives that are involved in the client switching.
The runtime should also be able to manage complex reconfiguration operations, such as the client switching reconfiguration in the aforementioned example.This specific reconfiguration operation involves two related calls to reconfiguration primitives: a disconnection from the primary server, followed by a connection to the secondary one.For such cases we argue that the runtime-level model should provide a reconfiguration transaction service, whose aim is twofold: (i) to provide the architecture level with a view of multiple calls to reconfiguration primitives as generating a single reconfiguration notification (an example of this is provided in Section 2.2); and (ii) to keep track of the calls to the reconfiguration primitives involved in a reconfiguration operation so that a rollback can be done if such operation is invalidated at the architecture level.This service is therefore essential for a proper dependability support as it prevents the system to be in an invalid state both at architectural and runtime levels.
Finally, a runtime must preserve the safety and integrity of a dependable system even within single calls to reconfiguration primitives, especially where multithreading is employed.To understand this, consider again the client switching reconfiguration.In this situation, we need to suspend all threads issuing new requests from the client to the primary server, and wait for the completion of the currently outstanding requests before actually disconnecting these elements.

Architecture Level
Software architecture modelling plays an important role in the development of dependable software.An architecture specification uses high-level representations such as ADLs or DSLs to embody information about a system's configuration while abstracting away details about the internal implementation of its elements.Such a specification allows the software architect to reason about structural properties early in the development process, fostering dependable and extensible designs.Typically, an architecture specification also describes some principles governing the system's design and evolution.In our view, architectural specifications and styles must also consider and enforce dependability requirements.Architectural styles [13] are the most common way to describe such principles in software architecture modelling.These are defined in terms of formally-described software element types, as well as rules that govern the composition of such elements.For instance, a pipeline style might comprise a basic set of pipe and filter element types and rules that permit only non-circular compositions of such elements in a configuration.A configuration following a specific style can thus be seen as an instance of such style at the runtime level.
In our view, three main issues should be addressed at the architecture level to allow its causal connection with the runtime level.
First, there must be a precise (complete) mapping from architecture-level concepts to runtime-level concepts.Surprisingly, this is a largely overseen requirement in the literature [1].
Second, the architecture level should be able to handle architecture specifications not only during system deployment (i.e. an initial configuration that is set up from 'scratch' based on a complete specification) but also over a currently running system (in which case the current specification will typically be a delta from the original configuration).Getting back to our example of a dependable web based client-server application, imagine that the primary-backup configuration can no longer cope with the load from the clients.The system architect then decides to replace the primary server with a more sophisticated implementation that is able to detect an imminent overload and redirect new client calls to the secondary server.This is a typical situation in which the system architect might enact a "partial" specification.We argue that, in such cases, the system architect could be provided with a configuration management service that would map (either full or partial) architecture specifications onto reconfiguration primitives to be effected at the runtime level.Moreover, partial specifications should allow for both architectural construction and destruction (the latter to correctly represent element removals and disconnections at the runtime level).
Thirdly and finally, architectural styles should be extensively used at the architecture level as a means of constraining reconfigurations in running systems.For instance, it would be interesting to associate our dependable web-based application with a runtime impersonation of the client-server style, which would forbid invalid reconfigurations such as clients with dangling connections.In this case, the figure of a style enforcement service comes into play, handling style-specific rules governing reconfigurations.A style enforcement service would receive reconfiguration notifications from the runtime level and check whether any of the corresponding calls to reconfiguration primitives have violated the architectural rules defined in the corresponding style.Note that the definition of architectural rules depends on the target functionality domain-e.g. a layered style and a client-server style each have their specific constraints-and can vary considerably.To avoid specific controller implementations for each style of interest, a generic style enforcement service should be devised.This controller would be configurable with regard to the rules it can enforce.More specifically, validation scripts would be used as runtime representations of architectural rules.Such scripts (implemented, for example, as code in an interpreted language, or as finite state machines) could be loaded to (or unloaded from) the style enforcement service during runtime."Running" styles could therefore be evaluated and refined/ fixed without compromising the availability of the dependable system-as long, of course, as the running configuration did not violate the rules of the modified style.
It is important to bear in mind that a call to a reconfiguration primitive at the runtime level may be part of a complex reconfiguration operation, implementing some dependable functionality, and therefore it is not sufficient for the style enforcement service to check each call in isolation.To understand this, consider a system that follows a pipeline style (i.e. a system in which non-contiguous configurations and 'cycle' connections are disallowed), such as a software-based router.In a dependable implementation, this router could adapt to new network conditions by inserting a new element (e.g. a new packet scheduler) in the middle of the pipeline.This reconfiguration operation could be regarded as valid from the point of view of the currently defined architectural rules.Nevertheless, inserting such an element might involve sequences of distinct calls to reconfiguration primitives in the configuration.For example: (i) the addition of the new element, (ii, iii) disconnections between the two to-be-neighbour elements, and (iv) new connections between these two elements and the new one.Any of the first three calls would appear invalid if treated in isolation.Hence the need for the style enforcement service at the architecture level interacting with the transaction service at the runtime level.The way such interaction is accomplished depends, however, on the type of reconfiguration in question; this issue is discussed in the next section.

Handling Foreseen and Unforeseen Reconfigurations
Dynamic reconfiguration can be classified as either programmed or ad-hoc, according to the moment at which it is specified.Programmed reconfiguration [37] is specified at design time while ad-hoc reconfiguration is unpredictable at design time but can occur at runtime.While the former is important for automatic reconfiguration, the latter is suitable for software maintenance.In this sense, programmed reconfiguration is related to the concept of self-organizing architectures [16,29].
The example (in Section 2) of a dependable web based client-server application illustrates a common situation in which both types of reconfiguration can co-exist at the architecture level.First, consider the simpler configuration involving two servers with automatic client switching on failure.This situation can be foreseen at design time, so an important requirement at the architecture level is to provide constructs to specify such a situation as a programmed reconfiguration.More specifically, to support such type of reconfiguration the architecture-level model must provide predicate-action constructs to specify the situations that trigger reconfigurations and which reconfigurations must take place.Now consider the case of the system architect replacing the primary server with the more sophisticated implementation that, on overload, redirects new client requests to the secondary server.This situation has not been predicted at design time; therefore, it is interesting that ad-hoc reconfiguration-in terms of enacting partial specifications-be available at the architecture level as well.In this case, the style enforcement service is called to analyse the reconfiguration specified in the partial specification, and if the architectural rules are not violated, the system representation at the architecture level is updated and the related reconfiguration operation is executed atomically at the runtime level by the transaction service.Note that, in this situation, the style enforcement service can make the transaction service completely aware of the beginning and end of the reconfiguration operation.
Ad-hoc reconfiguration can be also effected directly at the runtime level.For instance, dependability requirements identified at runtime can be inserted in the application using ad-hoc reconfiguration.The notification service described in Section 2.1 is then crucial to keep the architecture level consistent with the runtime configuration, and vice-versa.
Architecture-level consistency can be attained through an additional configuration update service, which would provide causal connection in the runtime-to-architecture direction by updating the system representation at the architecture level.Although this can be of interest to provide full causal connection in both directions-e.g. for the purpose of architecture analysis [1]-we expect that in practice most systems will employ either architecture or runtime level ad-hoc reconfigurations, but not both simultaneously.More specifically, we believe that runtime level ad-hoc reconfiguration is more likely to happen in lower-level system environments-e.g.those driven primarily by OS events-whereas architecture level ad-hoc reconfiguration seems more suitable for higher-level functionality.In Section 4 we discuss an implementation of our approach that provides full causal connection in the architecture-to-runtime direction only.This mechanism guarantees that dependable conditions and statements of the architectural level are enforced at the runtime level.
Runtime-level consistency, on the other hand, can be provided through the combination of the runtime-level transaction service and the architecture-level style enforcement service, as in the case of architecture level ad-hoc reconfiguration.In contrast to what happens in the architecture level, however, the style enforcement service cannot make the transaction service aware of which calls to reconfiguration primitives start and finish the reconfiguration operation at the runtime level.Ideally, the transaction service should be also transparent (at least selectively) to someone calling reconfiguration primitives at this level, thus allowing the seamless adoption of our approach in legacy systems.

The Plastik Architecture
To experiment with our approach, we have been developing an architecture called Plastik, which extends and causally integrates two existing technologies.The runtimelevel technology is based on the OpenCOM reflective component model [10] and the associated notions of reflective meta-models and component frameworks.The architecture-level technology is based on the Acme ADL [14] and the associated Armani first-order predicate logic (FOPL) constraint language [26].Both of these technologies are presented below, with a particular emphasis on the model extensions provided by Plastik to underpin the concepts discussed in the previous sections.

The Runtime-Level
We have chosen OpenCOM as the basis of Plastik's runtime-level model because of its high performance and good support for dynamic reconfiguration in comparison with related technologies [6].Besides, it has been successfully used over the past few years for building reconfigurable software in a variety of domains [4,11].Fig. 2 provides a pictorial view of the fundamental entities of OpenCOM's model: components (language-independent units of functionality and deployment), interfaces and receptacles (units of service provision and consumption respectively), bindings (runtime associations between interfaces and receptacles), and capsules (containers offering runtime kernel services such as (un)loading, instantiating and destroying components, and (un)binding interfaces and receptacles).Other first-class entities in the model-omitted in Fig. 2 for clarity-are caplets (nested sub-scopes within capsules), loaders (pluggable caplet-specific loading mechanisms), and binders (pluggable intra-and inter-caplet binding mechanisms).These provide OpenCOMbased software with capsule distribution transparency, thus playing a crucial role in facilitating the uniform deployment of such software in a wide range of platforms from standard PCs, to resource-poor PDAs, to OS-bare embedded systems, to highspeed network processor hardware.
Above those fundamental entities, the notions of reflective meta-models [9] and component frameworks (CFs) [34] are extensively employed in OpenCOM to manage and constrain dynamic reconfiguration.The reflective meta-models provide OpenCOM with 'low-level' facilities to programmatically inspect, adapt, and extend diverse system aspects (e.g.configuration topology, call interception and thread management) at runtime.These facilities thus offer openness and flexibility to system developers.CFs, on the other hand, are targeted at system-and application-level functionality.CFs are tightly-coupled sets of components (usually deployed as composites) that work together to address a focused domain of functionality.When deployed as composites, CFs can be also encapsulated in 'outer' CFs.Importantly, CFs in OpenCOM can incorporate policies that determine to what extent the CF can be reconfigured at runtime.Fig. 3  Reconfiguration transaction service.This is implemented in OpenCOM by per-CF proxy components-i.e. each CF is given an internal, dedicated proxy for the runtime kernel services, as illustrated in Fig. 4.Such a component addresses three issues.First, it provides inter-CF isolation; a proxy component prevents other components within one CF from interfering with other CFs because such components cannot access the kernel services directly.Second, proxy components allow for deferred reconfigurations; they can defer actual calls to reconfiguration primitives that make up a reconfiguration operation. 1Deferring such an operation allows a style enforcement service to validate it at the architecture level before the proxy actually commits it (i.e.forwards the deferred calls to the actual kernel services), with the possibility of rollback on failure.For all this to be possible the style enforcement service is explicitly notified about pending transactions-refer to the Plastik implementation of the reconfiguration notification service described below.Third, proxy components offer a local registry service, which allows arbitrary meta-dataexpressed in terms of <key,value> pairs-to be attached at runtime to any OpenCOM element.These are read and potentially modified by any component within the CF (including the proxy).

Reconfiguration notification service. Plastik implements this service based on
OpenCOM's interception meta-model [9].This allows a programmer to interpose interceptors (small software modules) at bindings between interfaces and receptacles.As mentioned in Section 3, in an ideal scenario the runtime should allow for "implicit" reconfiguration transactions.In our current implementation, however, the proxy component includes transaction primitives for systems to explicitly scope multiple calls to reconfiguration primitives.For the reconfiguration notification service, interceptors are associated with the interfaces provided by proxy components.This permits that actions such as reconfiguration operations and updates of registry entries within a CF be sensed and notified to interested parties.To receive such notifications, interested parties must subscribe to per-CF notifier components that manage which subscribers are interested in which notifications.The following subsection provides an example of this service usage at the architecture level.

Safe reconfiguration primitives. Work in this area
is not yet complete in the context of the Plastik architecture.However, ongoing work on it has progressed in the context of a related OpenCOM project [31], and we are currently integrating this with Plastik.

The Architecture Level
We have chosen Acme as the basis of Plastik's architecture-level model because it offers sufficient generality to straightforwardly describe a variety of system structures.Besides, it comes with tools that provide a good basis for designing and manipulating architectural specifications and generating code.
Plastik employs the standard Acme constructs: components and connectors (elements of computation and interaction), ports and roles (interfaces of components and connectors respectively), attachments (associations between ports and roles), representations (internal decompositions of components/ connectors), properties (annotations on other Acme constructs), systems (configurations of components and connectors), and families (architectural styles).Plastik also employs Armani expressions embedded in Acme family specifications to define invariants (architectural rules) over Acme systems.
Fig. 5 provides an example of the specification (and an associated graphical representation) of a simplified software-based router in Acme (the RouterInst system).The example also illustrates the use of the family construct as a means of specifying the main component types involved in a typical router (the Classifier, Forwarder and Scheduler types) and an architectural rule on the pipeline composition of such components (the validTopology rule).Mapping architecture-level concepts to the runtime level.We address this first issue by defining a set of Acme-to-OpenCOM correspondences, which are shown in Table 1.The system-and representation-to-CF correspondences are central: Acme families naturally correspond to CF specifications as domain-specific units of reusable and dynamically reconfigurable functionality.Notice that, for system-to-CF correspondences, it is always assumed that software systems in OpenCOM are themselves contained in (outermost) CFs.Although somehow restrictive in general, we consider this characteristic particularly interesting for dependable systems.The one-to-one mapping between Acme connectors and OpenCOM components arises from the possibility of easily supporting 'rich' connectors (such as SQL statements or RPC channels) as inter-capsule bindings.Acme properties are mapped onto registry entries in the CF proxy component.For the mappings involving OpenCOM interfaces and receptacles, a more precise semantic proved to be necessary on the corresponding Acme constructs.proposed solution to this was to devise a generic PlastikMF family that defines port and role types identifying units of service provision (ProvidedPort, ProvidedRole) and consumption (RequiredPort, RequiredRole).The rest of the correspondences are intuitively clear from Table 1.Enacting partial specifications and programmed reconfigurations.Plastik extends the classic Acme constructs with the following additional ones: • an on-do construct: this allows software architects to express runtime conditions (using Armani expressions) under which programmed reconfigurations (specified in extended Acme) should take place in an architecture.This construct is used to map dependability requirements identified at specification time to the correspondent programmed reconfiguration operations.• detach and remove constructs: these allow software architects to dismantle parts of an architecture by deleting attachments or destroying existing components, connectors or representations.• a dependencies construct: this allows software architects to express runtime dependencies among components/ connectors.This construct itself intrinsically supports dependability as it avoids that a reconfiguration operation leads the system to an inconsistent state where the dependencies between the architectural elements are not available.This can be thought of as a 'syntactic sugar' to the on-do construct; it is useful when the runtime condition is a component or connector instantiation and the programmed reconfiguration operations associated with the established condition comprise other component/ connector instantiations as well as attachments between them.
Fig. 6 builds on the previous Acme example and provides the specification of a dynamically reconfigurable router that employs an on-do statement, and associated detach, remove and dependencies statements. 2 The intended effect of the specification is that on detecting an MPLS packet in an IPv4 flow (via the Packet property), the 2 This example comes out of a related OpenCOM project on programmable networking [25].
System RouterInst : Router = new Router extended with { ... // same as in Fig. 5 on (cls.i.packet.In the case of such statements, the corresponding runtime conditions are registered in the notifier component as events of interest to the style enforcement service.Fig. 7 illustrates these ideas.

Style enforcement service.
As depicted in Fig. 7, this architecture-level service is also implemented at the runtime level as per-CF components called policers.Such components host both validation and programmed reconfiguration scripts.Whenever a proxy notifies a policer about a pending transaction (see Subsection 4.1 for a discussion of transactions), the latter executes the validation scripts to ascertain the correctness of the corresponding reconfiguration operation, committing or aborting it accordingly.Similarly, programmed reconfiguration scripts effect reconfiguration operations in response to notifications about runtime conditions of interest.Both validation and programmed reconfiguration scripts are uniformly implemented as programs in the interpreted language Lua [19].We have chosen Lua because it provides fast code interpretation, high flexibility, and a small footprint (around 100k).This last feature is particularly important since Plastik is designed to be potentially deployable in resource-poor platforms.

Case Study
To evaluate our approach, we have experimented with the architectural specification of a telemedicine system called AToMS (AMI Teleconsultation and Monitoring System) [18].This system aims at fostering the ubiquitous adoption of pre-hospital drug treatment for patients with acute myocardial infarction (AMI) in Brazil.Crucially, only an specialist (cardiologist) can diagnose an AMI patient as elegible to drug treatment, based on the result of an eletrocardiogram (ECG) and the patient's clinical state.The AToMS system helps emergency teams (located at the place the first assistance is delivered-e.g. in an ambulance) and specialists (remotely located at a teleconsultation center) to exchange information about the patient and decide on his/her elegibility for promptly receiving the drug treatment.In this system, emergency teams carry portable devices communicating with ECGs that collect monitored data from the patient.The ECG data is sent to the teleconsultation center together with information about the patient's clinical state through a wireless network (e.g.GPRS, WiFi mesh, or WiMAX).The teleconsultation center puts the emergency team promptly in contact with available cardiologists, which can then remotely decide on the applicability of drug treatment based on the data provided to them.

Architecture Baseline
Fig. 8 presents a pictorial representation of the AToMS software architecture.A partial description of such architecture in Acme is given in Fig. 9.As can be seen from these figures, the system follows a pub-sub style at its outermost level.The ETSubsys and VCSubsys components (representing the emergency teams and the teleconsultation center, respectively) are internally composed as client-server subsystems.Within ETSubsys, ETCli components represent 'rich' client applications running on the portable devices held by the emergency teams, whereas the ETSrv component represents a web service.These components communicate with each other through an asynchronous SOAP connector deployed over a wireless medium.Within TCSubsys, TCCli components represent web applications accessed by cardiologists through standard web browsers (synchronous HTTP), whereas the TCSrv component represents another web service.Teleconsultation requests/ replies and monitoring notifications are exchanged asynchronously between the two aforementioned web services through two message bus connectors (TelBus e MonBus), which will be typically deployed over a wired network.

Dimensions of Dependability
The AToMS system presents various dependability dimensions, many of which can be considered at the architecture level.Some of these are described below.

MonBus ETSubsys ETSubsys
TCSubsys TCSubsys It is important to bear in mind that many exceptional situations may happen in the AToMS system which could not be foreseen by the system architect.For instance, suppose that within ETSubsys a GPRS connection is currently in use between a client and the server.Because of its current location, the client experiences some intermittence in its GPRS connection, but no other wireless technology is available therein for a handover.An alternative solution could thus be to apply an ad-hoc reconfiguration-for instance, by dropping in a retransmission module to work over the lossy connection.To guarantee that the client interface does not change, and that the retransmission of messages in case of failure occurs transparently to it, it is interesting that such module be inserted into the wireless connector, as part of the communication protocol, or into the client, as an application-level plug-in.
As ETSubsys follows the client-server style, the aforementioned ad-hoc reconfiguration can be constrained so that the new module can be inserted into the wireless connector or the client component, but not in between them.The architectural rule in the client-server style which constrains such reconfiguration is depicted in Fig. 11.This rule mandates that if two components are connected, one must be a client and the other one must be the server.
In Plastik, the rule depicted in Fig. 11 is mapped to a validation script in Lua, as illustrated in Fig. 12.Such script is to be hosted by the policer component in the CF implementing ETSubsys.Functions prefixed by rtk and rmm (shown in bold font in the figure) are implemented by the Lua interpreter as a set of operation invocations on the OpenCOM runtime kernel services and reflective meta-models respectively.The validation script is called in the context of a transaction (identified by parameter 'tid'), which is scoped by the proxy component in the same CF as the policer.More details about the mappings between Acme rules and Lua validation scripts can be found in [20].

Discussion
As it currently is, Plastik was able to cover the major dependability issues that arose in the presented case study.Nevertheless, some aspects have been identified for future investigation.
The first one is that the on-do construct does not allow dealing with sets of elements in a system or representation specification in a flexible way.Although the condition expressions in on-do statements can use the 'forall' and 'exists' Armani quantifiers, in the case of Fig. 11  programmed reconfiguration was to replicate the on-do statement for each connector in ETSubsys.
A second point is that there is currently no adequate support in Plastik for managing dynamic reconfiguration in distributed systems.For the programmed reconfiguration in Fig. 10 to be possible, the ETSubys component had to be mapped onto a widely-distributed capsule.Although the degree of capsule distribution is implementation dependent in OpenCOM, the general intention is that capsules be relatively tightly-coupled so that centralised state can be held [10].For widelydistributed systems, inter-capsule bindings (e.g. using RPC or pub-sub or streaming) are preferred.Currently, Plastik does not support the explicit management of such type of bindings.

Related Work
There has been a good amount of research over the past few years on specification-todeployment environments, although much of it has focused on particular application areas or specific aspects.Little of it, however, has comprehensively addressed dynamic reconfiguration issues, which in our belief is cructial to enabling the architecture of dependable systems.Dynamic software architecture techniques.Aster [5,22] is a development environment providing an ADL with an embedded property sub-language that supports the architectural specification of object-oriented distributed systems and their non-functional requirements.Based on an application specification, an Aster tool selects appropriate middleware objects and integrates them with the described application.Aster supports ad-hoc reconfiguration at the architecture level, but does not support any kind of programmed reconfiguration.Furthermore, Aster focuses on high-level functionality and cannot realistically be used for architecting systems in stringent environments such as the networking examples considered above.
Mae (Managing Architectural Evolution) [33] is an architectural evolution environment based on xADL [12].Mae explicitly supports programmed reconfiguration by employing a configuration versioning mechanism (i.e.configurations are basically checked in and out to/ from a version space), but does not support ad-hoc reconfiguration.
The work in [30] presents an approach to runtime software evolution based on the C2 ADL [35] and focused on connector-centred reconfiguration.This work has similarities to our approach as regards providing some causal connection between architecture-and runtime-level models.Nevertheless, reconfigurations can be applied only at the architecture level and enforced only on connectors.
ArchWare [28] is a specification-to-deployment environment that also provides some causal connection between architecture-and runtime-level models.ArchWare strengths reside in its formal support at the architecture level, which is provided by a specific π calculus-based ADL, and its reflective capabilities at the runtime level, which are provided by an implementation of the hyper-code abstraction [21].In contrast, we departed from two mature technologies (OpenCOM and Acme), leveraging both of them through the definition of precise inter-model mappings and a few extensions leading to the enablement of causally-connected reconfiguration.
Three other pieces of work on specification-to-deployment environments have bearing on our approach.First, in [7], architectural styles are treated basically as policies for system self-repair in the runtime infrastructure-i.e. the system is monitored during runtime so that style-prescribed reconfigurations are effected when style constraints are violated.Therefore, this system supports both programmed and ad-hoc reconfigurations.However, it does not consider the enactment of partial specifications directly provided by software architects during runtime-i.e.architecture-level ad-hoc reconfigurations are not considered.Second, in [15], an architectural runtime configuration management system is proposed, the focus of which is on adaptive fault recovery.The fundamental facility provided by this work, however, resides in enhancing adaptation visibility through visual tooling; this work relies on human judgement and intervention for determining whether a reconfiguration was valid or not.Third, work by Georgiadis et al. [16] discusses the feasibility of using architectural constraints as the basis for the specification and deployment of self-organising architectures at distributed execution environments.Finally, the work presented in [1] addresses the issue of precise mapping between architecture-and runtime-level models.In contrast to our approach, however, its primary contribution is to provide semi-automated incremental synchronization between architecture-and runtime-views, thus ensuring conformance between the architecture specification and the configuration of the running system.

Reconfigurable runtime technologies.
FORMAware [27] is a reflective componentbased framework that augments explicit architectural specifications with metainformation to constrain dynamic reconfiguration.FORMAware supports ad-hoc reconfiguration, which is managed by a transaction service; however, programmed reconfiguration is not supported.Another fundamental difference between FORMAware and our approach is that we adopt an ADL for the definition of architectural invariants, whereas FORMAware style rules are described as pieces of procedural code.This lowers its level of abstraction with respect to our approach.
Koala [36] is a component model that uses an ADL based on Darwin [25] to manage the complexity of software in consumer electronics products.Dynamic reconfiguration is, however, restricted to switching between pre-existing components based on statically defined conditions.Furthermore, there is no causal connection between the architecture-and runtime-level models.
Fractal [6] is a hierarchically-structured Java based component model which uses an XML-based ADL to specify the high level structure of an application, and which provides runtime reflective features to support dynamic reconfiguration.Nevertheless, Fractal has no support for the description of constraints at the architecture level, and again provides no causal connection between the levels.
Finally, Knit [32] is a component definition and linking language that promotes the wrapping and reuse of existing code (in C).One of its main features is minimising componentisation overhead; thus it is particularly useful for designing and implementing complex, low-level systems.Knit also provides some support for specifying and enforcing architectural rules, but it has nothing comparable to a fully general ADL.Also, in comparison with our approach, Knit is programming languagespecific and does not support either ad-hoc or programmed reconfiguration.

Final Remarks
We have motivated and discussed an approach to dynamic reconfiguration in dependable systems.The approach can be seen as bearing on dependability in two distinct ways.First, it helps us view dynamic reconfiguration as a concern that goes very naturally with generally-applied approaches to software engineering for dependability-such as ADLs, model driven development (MDD) paradigms, and domain specific languages.Second, our approach is intrinsically internally dependable though its use of system elements such as the reconfiguration transaction service, and policing components that are automatically generated from architecturelevel specifications.
Our approach is also highly generic in that it supports both programmed and adhoc reconfiguration at both the architecture and the runtime levels.
In future work we plan to evaluate the Plastik architecture in the context of real application scenarios.We are especially interested in applying the approach in the resource-poor and 'primitive' application environments (e.g.embedded systems and sensor networks) in which OpenCOM itself is routinely applied.This will be a strong test of the viability of our approach (and especially its runtime machinery).
We also plan to broadly evaluate the Plastik reconfiguration strategies using highly dependable (and possibly distributed) applications.We intend to consider dependable scenarios where software reconfiguration is specified in the architecture model and reified in the OpenCOM runtime and also where the reconfiguration is triggered by the runtime level.In this way we can explore the power of the Plastik dynamic reconfiguration mechanisms to the realization of the self-organizing, self-repairing and self-healing support commonly demanded by dependable applications More generally, we plan to formalise the interface between the runtime and architecture levels of the architecture, and on this basis, to explore the wider application of our approach.For example, this will enable us to plug in different and independently-developed architecture levels that conform to specific MDD paradigms (e.g.UML-based models [8] or DSL-oriented specification frameworks [17]).We believe that such a research direction will contribute strongly to bringing dynamic reconfiguration more into the mainstream of dependable systems design and deployment.

Fig. 7 .
Fig. 7. Per-CF configuration management and style enforcement services in OpenCOM.
Although conceptually at the architecture level, this service is implemented in Plastik at the runtime level as per-CF configurator components.Such components interpret specifications in (extended) Acme to reconfiguration operations that are effected at the runtime level, according to the Acme-to-OpenCOM correspondences presented above.The first task accomplished by a configurator is to initialise its CF with a full specification of an Acme system or representation.This involves establishing the initial state of the CF in terms of loading, instantiating and binding the necessary OpenCOM components, and ensuring that the rest of the runtime machinery (including the other Plastik services) is instantiated.Having established the runtime environment, the configurator processes the Acme family specifications and the on-do and dependencies statements related with the system/ representation, generating scripts to be deployed on Plastik's style enforcement service (see below).Family specifications are translated to validation scripts, as mentioned in Section 2. Similarly, on-do and dependencies statements are translated to runtime representations called programmed reconfiguration scripts.
In the following paragraphs we survey relevant research, classifying the work in two main categories: dynamic software architecture techniques and reconfigurable runtime technologies.