Specification and refinement of dynamic software architectures

Systems specified in LEDA can be checked for compatibility, ensuring that the behaviour of their components conforms to each other and that the systems can be safely composed. A notion of polymorphism of behaviour is used to extend and refine components while maintaining their compatibility, allowing the parameterisation of architectures, and encouraging reuse of architectural designs. Documents: Advanced Search Include Citations. Authors: Advanced Search Include Citations.

To conceptually model such platforms including provided reconfiguration mechanisms, we use architectural styles formalized by graph transformation rules.

Based on formal refinement relations between abstract and platform-specific styles, we can then investigate how to realize business-specific scenarios on a certain platform by automatically deriving refined, platform-specific reconfiguration scenarios. Documents: Advanced Search Include Citations. For instance, consider a file transmission between two components, named Sender and Receiver respectively.

Component Receiver plays the role of reader, receiving the data which is sent by Sender, which acts as writer Figure 1. However, our goal is to describe the observable behaviour of components, that is, how they react to external stimuli, and how input and output stimuli are related. This behaviour is described by the roles that form the interface of the component. Roles Writer and Reader in Figure 2 specify the protocol of interaction between the components Sender and Receiver, i.

Data is transmitted matching two complementary actions w! As indicated by the use of local choices, the responsibility for action falls in the Writer part, which knows when the file has been completely transmitted, and sends an event wq! Writer w,wq w?

A composite contains several subcomponents which are instances of other component classes. Any software system can be described as a composite. Thus, the syntax of LEDA does not distinguish between components and systems or architectures.

As we have shown, simple components are described by the roles of their interfaces, but for composites, we must also describe their internal architecture. This architecture is the result of the interconnection or attachment of several subcomponents. Both the Client and the Server are composites which contain an unbound array of service components.

Role request describes the behaviour of the Client, while role serve describes that of the Server. When receiving a request, the Server creates a service component with the statement new.

Then, the reference to the service is transmitted to the Client through the private link reply. The name n is used in the role serve for taking account of the number of requests received, which will be also used in a subsequent example. Troya 9 4. These relations are explicitly represented in LEDA by a set of attachments among the roles of these subcomponents. Attachments relate roles of several components, and they are specified in the composite which contains these components.

Attachments are set when the corresponding components and role instances are created, possibly dynamically, and can be modified during system execution. LEDA distinguishes among several kinds of attachments, which permit the specification of both static, reconfigurable, and dynamic software systems. Static attachments are those which are never modified once they are set. For instance, recall the components Client and Server from Figure 3.

For instance, suppose that we have two Server components, and each request is assigned to one of them trying to balance their work load Figure 5. Each pair of interconnected components may use private links in their communication, or these links may be shared by all the components involved. Thus, multiple attachments can be either shared or private. A shared attachment describes an 1:M communication channel, while private attachments establish multiple communication channels.

Each request will be served by one of the Servers non- deterministically. On the other hand, the attachment between the Clients and the ServerPool is also multiple Figure 6, right , and all clients share the link r through which they request services. Notice that mobility is used to establish private reply links for each request, though all the Clients are connected to the ServerPool using a single request link.

Troya 11 An additional form of attachment is that of role exportation. Usually, when dealing with a composite, some of the roles of its components are not used for the interconnection of these components, but to form the interface of the composite.

We have already used this mechanism in Figure 6, left, where the roles of the Servers were exported to form the interface of the ServerPool. Attachments have a formal semantics Canal et al.

Thus, specifications can be tested at an early stage of the development process, checking their conformance with system requirements. Apart from description and prototyping, LEDA specifications also serve for validation purposes. In particular, for determining whether a system is consistent, i. As we usually want to connect components that match only partially, the relations of bisimilarity customarily used in process algebras are not well suited for our purposes.

A formal definition of compatibility and its properties is out of the scope of this paper, but it can be found in Canal et al. A proof of compatibility for every system attachment using this relation ensures that the corresponding components will be able to interact safely until they reach a well-defined final state. Thus, if a software system is built according to the specifications of the architecture, no failure will arise from the interaction in any attachment between its components.

Obviously, local analysis of compatibility cannot ensure that the whole system is deadlock-free, since deadlock could arise from the global interaction of a set of components whose roles are compatible. We consider that a system is consistent when each attachment in its architecture connects compatible roles, indicating behavioural conformance of the corresponding components.

On the other hand, a failure detected when analysing an attachment stands for a mismatch in the behaviour of the corresponding components, usually leading to a system crash. In the object-oriented paradigm, reuse is achieved by inheritance and polymorphism. Data polymorphism is defined as the capability of an identifier to point or refer to instances of different classes, while inheritance refers to a relation among object classes by which an heir class inherits the features methods and attributes of its parent classes.

Heirs can extend their parents by adding new features, and they may also redefine some of the inherited features, usually under certain restrictions.

Inheritance is a natural precondition for polymorphism, since it ensures that heirs will have at least the same features than their parents, and that they can replace them safely.

A relation of inheritance will be also of use for specifications of software components. However, in our context the interface of a component is defined not only by the signature of its features i. Thus, role redefinition and extension must be restricted in order to preserve the behaviour specified in the parent role. This relation defines the restrictions for polymorphism of behaviour, allowing the replacement of a role by a derived version, while preserving compatibility.

Role extension in LEDA can be formally validated. Again, we refer to Canal et al. Role extension can be used to i redefine, partially or completely, the parent role, giving a new specification for some of its agents; and ii extend a role, providing it with additional functionality.

In both cases we must check, using the relation of inheritance, that the extended role is effectively an heir of the parent role. For instance, consider the role Serve of Figure 3. Its behaviour can be extended allowing clients to query the number of requests solved by the server, which can be used for statistics. Troya 13 The notion of extension can be also applied to components. Derived components inherit their parent's specification, including roles, subcomponents and attachments.

An heir component extends its parent by adding new roles, components, or attachments, or by redefining some of its parent's. In case of redefinition of a role or component, the redefined instance must be an heir of the original instance.

Component extension can be implicitly achieved by architecture instantiation, which indicates the replacement of a component instance in a composite with another one whose class extends that of the former. Architecture instantiation can be used for incremental specification, description of families of software products sharing a common architecture, and also for dynamic replacement of a component in a software system. The syntax of instantiation is as follows: derivedComponent : ComponentClass[subcomponent : DerivedSubcomponentClass]; which means that derivedComponent is an instance of ComponentClass in which we have replaced its subcomponent which let's suppose was declared of a certain SubcomponentClass by an instance of DerivedSubcomponent- Class, where DerivedSubcomponentClass must be an heir of Subcomponent- Class.

When instancing an architecture, some of its attachments are modified, since some of its former components are replaced by derived versions. However, compatibility rechecking of the instanced architecture is not required, since role inheritance ensures the preservation of compatibility. This property is commonly referred to as refinement. For example, we can begin with a high level specification of a system in which we describe only its top-level components, their interface, and how they are attached to construct the system.

Then, refinement is applied to obtain a more detailed specification, by describing the internal structure or the behaviour of previously defined components, obtaining more complex specifications which come gradually closer to implementation.

As we have seen, component extension is a useful mechanism for refinement, but other forms of refinement can be applied using LEDA. We can obtain more specific architectures by describing the details of the service, i. Its role request is refined indicating that a component receiver is created each time the client requests a service.

The service itself is refined, too, indicating that its type is now Sender instead of any, and a new attachment is included, connecting the roles of the receiver and the service. Components Receiver and Sender were specified in Figure 1, while its roles were described in Figure 2. We can use the mechanism of architecture instantiation for obtaining an instance of the refined architecture: refinedCS : MultipleClientServer[client : ReceiverClient, pool.

On the contrary, the compatibility of the new attachment between the roles Reader and Writer, which was not present in the original architecture, must be checked. This will be done using an adaptor, which acts as a glue allowing the construction of composites from components which are not strictly compatible.

Adaptors are also used to modify the interface that a certain component exports to its environment. However, roles describe the interface of a component, and they are declared in the interface section, while adaptors are mainly used as a glue to tie the components of a composite, and they are declared in the composition section.

In the preceding examples, servers are always prepared to receive requests, which is not a realistic assumption. The specification of a non- reliable server NRServer is shown in Figure 9, left.

Obviously, the behaviour of our NRServer is not compatible with that of Clients, which suppose that servers are always willing to attend their requests. However, using a simple adaptor restart we can build a fault- tolerant server pool FTServerPool, Figure 9, right.