Modeling of Architectural Reconfiguration Case Study: Automated Teller Machine

Taha A. Cherfia Belala Faïza Nadira Benlahrache Department of Computer

Science Mentouri University Constantine, Algeria

Department of Computer Science Mentouri University

Constantine, Algeria

Department of Computer Science Mentouri University

Constantine, Algeria taha.cherfia@gmail.com belalafaiza@hotmail.com nbenlahrache@gmail.com

Abstract

Software applications are continuing to grow at a rapid pace and became more and more complex. Thus, the use of software architectures in the development process is the ideal solution to deal with this issue. In this context, many Architecture Description Languages (ADLs) have been introduced to define the software architecture and its elements. Most of these ADLs do not address the dynamic behavior of the software architecture. This dynamic behavior is most commonly known as architectural reconfiguration. In our work, we use the Architecture Analysis and Design Language (AADL) due to its capacity to represent the architectural reconfiguration. However, AADL suffers from the absence of a concrete model to define its formal semantics. This paper presents a formal approach based on Bigraphical Reactive Systems (BRS) to model the dynamic architectural reconfiguration of embedded real-time systems expressed in AADL.

Keywords: Architecture Analysis and Design Language, Bigraphical Reactive Systems, Reconfiguration of Software Architecture.

1. Introduction

Recently, increasingly complex system functionalities are changing the old development technologies, such as algorithms and data structures, and introduce new approaches, tools and methods to deal with a new kind of issues such as physical distribution, hierarchical organization and dynamicity. Software architectures are centered on the idea of reducing complexity of suchsystems by offering modeling mechanisms that are abstract but precise. The software architecture is a specification which describes systems as a set of interconnected software components. In this context,

Architecture Description Languages (ADLs) became a major research theme in the software engineering community. They represent software architecture in terms of components, connectors and configuration. Thus, numerous ADLs have been proposed due to the need to facilitate a high quality development of the software system, but only few ADLs are provided with some hold for dynamic behavior specification. Hence, in this paper we focus on the Architecture Analysis and Design Language (AADL) which is an international standard widely used in the industry and sufficiently rich to describe both the software architecture and the execution platform architecture. Besides, it models the dynamic behavior of software architectures through operational modes and mode transitions concepts. However, the lack of a formal model in the AADL standard reflects the weakness in semantic precision. This limitation is particularly severe for real-time embedded systems, because many of them are critical systems, requiring safety and efficiency, whose failures may cause serious damage to valuable assets and even to people. Thus, it seems clear that overcoming these limitations is highly significant, by the use of formal methods. Some existing works [1] suggest formal supports to precise the semantics of some concepts involved in this architecture description language. In the same context, this paper extends the Bigraphical Reactive Systems (BRS) based approach given in [2] to formalize the dynamic reconfiguration of AADL software architectures at runtime. Informally, BRS introduced by Milner and co-workers [3], consists of graphs with double structure, representing locality and connectivity, called bigraphs and a set of reaction rules providing to bigraphs the ability to reconfigure themselves. Therefore, BRS may give a high-level modeling of AADL software architecture in terms of graphical representation which does not only contain information about the components hierarchies but also the interaction between them. Furthermore, reaction rules may serve to model AADL dynamic architectural reconfiguration.

2012 IEEE Second International Workshop on Advanced Information Systems for Enterprises

978-0-7695-4845-6/12 $26.00 © 2012 IEEE

DOI 10.1109/IWAISE.2012.9

40

We apply our approach through Automated Teller Machine (ATM) case study which serves to demonstrate the feasibility and benefits of BRS in the embedded real-time systems modeling context.

The rest of this paper is organized as follows: section 2 discusses the related work on the existing approaches that formalize the architectural reconfiguration. In section 3, basic concepts and definitions of both Architecture Analysis and Design Language and Bigraphical Reactive Systems are introduced. Next, section 4 presents a case study of an embedded real-time system called ATM system and gives its AADL specification. Then, section 5 introduces an extending BRS based approach to model the architectural reconfiguration. Finally, section 6 concludes with discussion and future work.

2. Related Work

An abrupt work is being done in the literature to formalize the reconfiguration operation of software architecture. But, graphs equipped with graph transformation tools are actually emerging as a natural approach to specify software architectures and their dynamic reconfiguration.

A first class of works [4] applies graph transformation to only define structural reconfiguration, thus the models used neglect behavioral aspects that are inherent to such dynamic architectures. A second class of approaches as in [5] [6] [7] considers a clear separation of concerns between individual components behavior and software architecture dynamics. In such case, at least two different formalisms are necessary to specify the same dynamic software architecture, without mentioning side effects of each aspect on the other one. In another class of models, graphs are used for both aspects of dynamics. Authors of [8] consider class diagrams as software architectures and attempt to specify state evolutions, such as class instantiation or object destruction, by graph transformations. This leads to additional and sometimes complex formal constructs that are usually unnatural. Our contribution is quite similar to these approaches since it uses a Bigraphical Reactive Systems (BRS) based approach to model the dynamic architectural reconfiguration of real-time systems expressed in AADL.

We try to either graft behavioral models, based on rewriting rules, to graph transformation ones, thus we enrich existing BRS constructs to support both structural and behavioral evolution of software architectures.

3. Basic concepts

3.1. BRS Overview

The Bigraphical Reaction System or BRS in short, is a graphical model emphasizing both locality and connectivity of distributed systems.

A bigraph consists of a place graph expressing the physical location of nodes (system components), and a link graph, representing interconnection between these nodes. Definition 1 Formally a bigraph takes the form � � ��� �� ��� ��� � � � � � �where: • � and ��are finite sets of nodes and edges

respectively. • �� � � � ��is a control map, it assigns a control to

each node. The signature � is a controls' set where each control dictates how many ports the node has.

• �� � ��� ��� ����� � �� is the place graph of �which represents the forest where �� � � �� � ����� is the acyclic parent map which associates to each node its hierarchical parent. ��and ��are both finite ordinal numbers that represent sites and regions respectively.

• � � ��� �� ��� ������ � � �� is the link graph of G which represents the hypergraph where: ���� � � �� � �� ���is the link map, � and �represent respectively inner names and outer names and � is the set of ports of �.

• The interfaces � � � ��� � and � � � ��� � represent respectively the inner and outer faces of the bigraph��.

������������ � ������������ ����

A BRS consists of a category of bigraphs and a set of reaction rules that may be applied to rewrite these bigraphs. Thus, reaction rules define the dynamics of bigraphs where two transformations types are possible, nesting and linkage. Definition 2 A (parametric) reaction rule takes the form �!� !"� #� where !�� � ��is a bigraph called redex, !$��$ � � is also a bigraph called reactum and #���$ � �� is a map of ordinals.

41

������������� ��������������� �� ������� �������

Within BRS, each reaction rule consists of a redex (the part to be changed) which may be transformed to a reactum (the changed part) to rewrite the bigraph. For example in Figure 2, the reaction rule formalizes the packet (P) transport from the computer (PC1) in the network (NETA) through another computer (PC2) in a different network (NETB). Thus, this reaction rule is purely a locality reconfiguration. Based on definition 2, this reaction rule can be written by:

�!� % � �%� &'� (� )� *+�� !$� % � �%� &'� (� )� *+�� &�% � %+�

3.2. AADL Overview

AADL (Architecture Analysis & Design Language) is an international standard which provides formal modeling concepts to represent real-time embedded systems as component-based architecture in terms of distinct components and their interactions. AADL consists of a standardized textual and graphical notation for modeling the architecture of embedded software systems and their target platforms. Thus, many tools around AADL havebeen developed such as OSATE [9], TOPCASED [10], Ocarina [11], and Cheddar [12]. These tools can be used to create AADL architecture diagrams (TOPCASED), perform various tests and analysis (OSATE, Cheddar) or generate automatically software system applications from an AADL model (Ocarina). AADL standard defines three sets of components categories: Software category, this category includes data, subprogram, thread, thread groups, and process, while the components of Platform category are processor, memory, device and bus. Finally, Composite category represents AADL system components which organize hierarchical compositions of software and execution platform components. Within AADL, a component is defined through type and implementation declarations where component type declaration defines component interface elements and externally observable attributes such as features, flow specifications and property values. Conversely, implementation declaration defines the component’s internal structure in terms of subcomponents and their connections, subprogram call sequences, flow implementations, properties and modes.

Using modes, AADL can describe the dynamic behavior of systems where each component can have different modes that represent alternative operational

states, with only one mode being active by time. Thus, the dynamic behavior is defined by mode transitions that may change the set of active components, connections and property value associations.

These concepts are illustrated using a running example introduced in the next section.

4. Running Example : ATM System

In this section, we represent the AADL architectural elements through a concrete case study, Automated Teller Machine in short ATM which is a computerized machine that provides accessing facility and financial transactions to the banks customers. ATMs have become a part and parcel of new generation banking that can be found at most supermarkets, convenience stores and travel centers.

The ATM system is an embedded real-time system which provides banking services such as withdrawals, deposits transfers and balance checking using cash cards as identification on a 24-7 basis, with the support of central bank server and centralized accounts database. The architecture of the ATM system, as shown in Figure 3, is basically made up of a card reader to identify the bank customer, keypad for numeric input, processor to route the transaction requests to the bank via a modem, monitor to display messages, printer for providing customers with a receipt of their transactions and cash dispenser to allow customers to receive their cash.

���������������������������

In order to ease the understanding of AADL concepts described in this section, we will first introduce the main syntax of this language through the ATM system example, and then we exploit the bigraph based approach given in [2] to give a well-defined semantics to the ATM system at a runtime execution.

The considered system is formed of a collection of hardware and software components that control the banking services provided by ATM machines.

42

Corresponding to AADL model of ATM system as shown in Figure 4, AADL hardware components used in this case study to represent the internal structure of ATM system are: one processor (CPU), one piece of memory (ATM_Memory), six devices (Card_Reader, ATM_Keypad, ATM_Screen, ATM_Printer, ATM_Modem and Cash_Dispenser) and one bus (ATM_Bus) to interconnect these hardware components. In addition, ATM system encompasses a set of software components such as customer, session, accountand ATM_Service to represent the processes which model ATM functionalities and internal control.

---------------------------- --Automated Teller Machine-- ----------------------------system ATM_System end ATM_System;

system implementation ATM_System.impl

-- Declare all needed subcomponents Subcomponents

-- Software components customer : process Customer.impl; session : process Session.impl; account : process Account.impl; ATM_Service : process ATM_Service.impl;

-- Execution platform components CPU : processor ATM_Processor.impl; ATM_Memory : memory ATM_Memory.impl; ATM_Keypad : device ATM_Keypad; ATM_Screen : device ATM_Screen; ATM_Printer : device ATM_Printer; ATM_Modem : device ATM_Modem; Card_Reader : device Card_Reader; Cash_Dispenser : device Cash_Dispenser; ATM_Bus : bus ATM_Bus;

������������ ��������� �������������������������������������

We can see in Figure 4 that there are two different notations for the ATM_System component. As already mentioned, ATM_System (component type) specifies its external interface, while ATM_System.impl(components implementation) represents its internal structure in terms of hardware and software subcomponents.

Within an AADL specification, physical connections among the execution platform components are provided over a shared bus and specified using bus access declaration.

Figure 5 shows a portion of ATM_Systemspecification which represents the different physical connections over ATM_Bus. -- Attach the ATM_Bus to all other -- devices on the ATM_System

Connections

bus access ATM_Bus -> CPU.PRO_bus; bus access ATM_Bus -> ATM_Memory.MEM_bus; bus access ATM_Bus -> ATM_Keypad.KPAD_Bus; bus access ATM_Bus -> ATM_Screen.SCR_Bus; bus access ATM_Bus -> ATM_Printer.PRNT_Bus; bus access ATM_Bus -> ATM_Modem.MDM_Bus; bus access ATM_Bus -> Card_Reader.CRD_Bus; bus access ATM_Bus -> Cash_Dispenser.CDP_Bus;

�������!���� ��������� ������������������ ��������������

In addition, the ports represent the logical connections support among AADL components as shown in the figure bellow.

--------------------------- -- Connect all the ports -- ---------------------------

cnx1: data port ATM_Modem.status_data -> ATM_Service.ATM_Status; cnx2: event data port customer.Card_Number_out -> session.Card_Number_in; cnx3: event data port customer.PIN_out -> session.PIN_in; cnx4: event data port customer.Function_Key_out -> account.Function_Key_in; cnx5: event data port customer.Amount_out -> account.Amount_in; cnx6: event data port session.SessionID_out -> customer.SessionID_in; cnx7: event data port account.TransactionID_out -> customer.TransactionID_in; cnx8: event data port account.Balance_out -> customer.Balance_in;

�������"���� ��������� ����������������� ��������������

Within AADL, these logical connections must be bound to physical connections through the Actual_Connection_Binding property as shown in Figure 7.

43

-- Logical connections properties

Actual_Connection_Binding => reference ATM_Bus applies to cnx1 in modes (IN_SERVICE); Actual_Connection_Binding => reference ATM_Bus applies to cnx2 in modes (IN_SERVICE); Actual_Connection_Binding => reference ATM_Bus applies to cnx3 in modes (IN_SERVICE); Actual_Connection_Binding => reference ATM_Bus applies to cnx4 in modes (IN_SERVICE); Actual_Connection_Binding => reference ATM_Bus applies to cnx5 in modes (IN_SERVICE); Actual_Connection_Binding => reference ATM_Bus applies to cnx6 in modes (IN_SERVICE); Actual_Connection_Binding => reference ATM_Bus applies to cnx7 in modes (IN_SERVICE); Actual_Connection_Binding => reference ATM_Bus applies to cnx8 in modes (IN_SERVICE);

�������#�$��%��������� ��������������������&$���

Furthermore, for a complete system specification, software components must be bound to their appropriate execution platform components.

Figure 8 shows that ATM_System processes which contains threads must be bound to CPU through Actual_Processor_Binding property. Similarly, Actual_Memory_Binding is a predeclared property that references ATM_Memory to bind these processes.

-- Binding properties -- Installation Actual_Processor_Binding => reference CPU applies to customer; Actual_Processor_Binding => reference CPU applies to session; Actual_Processor_Binding => reference CPU applies to account; Actual_Processor_Binding => reference CPU applies to atm_service; Actual_Memory_Binding => reference ATM_Memory applies to customer; Actual_Memory_Binding => reference ATM_Memory applies to session; Actual_Memory_Binding => reference ATM_Memory applies to account; Actual_Memory_Binding => reference ATM_Memory applies to atm_service;

�������'�$��%��������( ������������������)���������� �����������������

5. Extending BRS to model architectural reconfiguration

Most existing ADLs do not deal with the dynamic behavior of software architectures; particularly their modifications at runtime such as adding, removing and substituting components and/or connections. However, AADL language offers the modes concept to model the dynamic reconfiguration of runtime architectures. Thus, modes represent the system’s active states of its components whereas mode transitions give them the possibility to reconfigure themselves. The transition between two operational modes is triggered by an event.

Authors in [2] show that BRS constitute a suitable mathematical model allowing the formalization of the two AADL structures: application and execution platform, included within a complete declaration of an AADL configuration, using two distinct bigraphs (see figure 9). This is achieved thanks to a formal mapping based on correspondence rules between the architectural elements of AADL language and bigraph concepts (lines 1-6 of table 1).

�������*�$��� ���� ��+��(��������( ��� �%�� �%( ���� ������������������

These bigraphs once composed define the installation pattern of a software application on an execution platform as shown in the figure below.

�������,�-����������������� ���������������.��,,-�,.�

44

Example 1: In the ATM_System specification’s portion given in Figure 11 there are two modes: IN_SERVICEand OUT_OF_SERVICE. These modes are related to the entire system where the IN_SERVICE mode is the initial mode. The external event brought from the ATM_Modemdevice into the ATM_Service process by event port OFFLINE results in a mode transition to the OUT_OF_SERVICE mode. Likewise, the event brought by the port ONLINE results in switching from the OUT_OF_SERVICE mode to the IN_SERVICE mode.

-- Operational modes modes

IN_SERVICE : initial mode; OUT_OF_SERVICE : mode;

-- Mode transitions IN_SERVICE -[ATM_Service.OFFLINE]-> OUT_OF_SERVICE; OUT_OF_SERVICE -[ATM_service.ONLINE]-> IN_SERVICE;

����������� ��������� ���������������&/��������%���

In the following, we extend the BRS based approach [2] to deal with the dynamic behavior of AADL runtime architecture. We enrich the proposed rules set defining correspondences between AADL configuration elements and bigraph concepts by additional rules associating a precise semantics to modes.

� ��������� ��0������� � ���������� �����������

In AADL, we note that any system configuration at runtime is defined by a pair �/� �� expressing the possible architecture of a system / in an operational mode��. Reconfiguration is specified by transitions between configurations thanks to mode changes. To achieve its formalization, we first extend bigraph definition by enriching its control function to deal with possible modes assigned to each declared component (node). Then, we exploit dynamic behavior of bigraphs (reaction rules) to represent the reconfiguration operation at runtime.

Definition 3 A bigraph /0 modeling an AADL configuration of a system / in a mode � over a signature 10 is given by: /0 � 2�3� �3

0� ��0� �34� �3

5$6 where: • 7 is a finite set of all possible operational modes.• �� 8 �7 represents a current operational mode.• 10 � �1� 9 7 is an extended signature which

represents a set of controls where each control ��:� �� � �;�(�:�� ���dictates how many ports a node : 8 �3 has in a current mode �.�

• �<=>�:� is a function which returns a set of all possible declared modes of a node :.

• ��0� �3 � �10 is a new control map assigning to each node : a control � 8 10

Within BRS, the dynamic behavior of bigraphs is

defined by the reaction rules. As already mentioned, a reaction rule is a substitution of a redex with a reactum where the source bigraph redex models the current state of a system and the reactum models the next state of this system after the execution of the reaction rule. Hence, exploiting this effective concept helps to formalize the AADL operational modes and their transitions.

Definition 4 Let ? � �:��� � �:��"�� be a mode transition of a components : between � and��". Formally a mode transition ? is defined by a parametric reaction rule noted @ � �!0� !0

$ � #� where: • !0 is a redex bigraph of a component : in a mode �A• !"0$ is a reactum bigraph of a component : in a new

mode �". • # is a map of ordinals.

Example 2: Turning now to the AADL specification given in Figure 11, we can see that the ATM_Systemmay have a particular behavior when it is switched from the IN_SERVICE mode to the OUT_OF_SERVICEmode. Thus, transitions between these modes express two possible reconfigurations of the entire system which means all the components and connections among them(given in Figure 7) are affected. In the ATM_System specification, the customer process consists of two threads Authentication and Banking and represents the main process for the

AADL elements Bigraphical semantic Architecture Formalization

System: / Bigraph/Region: / � � ��3� �3� ��3� �3

4� �35�����3 � � �3�

Component: : Node : 8 �3

Port/Role: � Port/Inner-name or Outer-name: � 8 �3 �9 �3

Interaction Port-Role: B Hyper-edges: B 8 �3

Hierarchy Imbrication of Nodes and Sites: ��3��3 9 �3 � �3 9 �3

Binding properties

Composition: /3-�/C where /3�and /C are bigraphs modeling respectively both software and hardware parts of /

Dynamic Runtime Formalization

Configuration�/0

Bigraph: /0 � 2�3� �3

0� ��0� �34� �3

5$6��

representing / in mode �Mode transitions Reaction rule: �@ � �!0�!0$

$ � #�

45

banking transactions which may be offered only in the IN_SERVICE mode. Thus, in the OUT_OF_SERVICEmode both of these threads are deactivated.

Applying our approach on the customer process we obtain the mode transition ? where:

? � � ��)D<�>� �EF/�!��:�� � ��)D<�>� GH?FGIF/�!��:��

The reaction rule associated to ? is noted as follows: @ � �!JKF3LMNJOL� !PQRFPSF3LMNJOL

$ � #� where: • !JKF3LMNJOL � % � � �T� U • !PQRFPSF3LMNJOL � % � � �T� U • # � % � %

���������-�������� ������������ ����VWXFYZV[W\Z � �%�V]^_F]`FYZV[W\Z

$ �

Finally, the signature 10��)D<�>� is defined as follows: 10��)D<�>� � &�%� �EF/�!��:��� �a� GH?FGIF/�!��:��+Where: • 7 � &�EF/�!��:�� GH?FGIF/�!��:�+ is the set

of operational modes which affect the customercomponent at runtime.

• ���)D<�>� � �%� �EF/�!��:�� is a control of the node �)D<�> where ;�(��)D<�>� �� �% in the �EF/�!��:� operational mode which represents the current runtime mode.

• ���)D<�>� � �a� GH?FGIF/�!��:�� is also a control of �)D<�> where ;�(��)D<�>� �� �aand the current runtime mode is the GH?FGIF/�!��:��mode.

6. Conclusion

The architectural reconfiguration represents an important activity during the development of embedded real-time systems. We have mentioned that only few ADLs can deal with this issue. Whereas, AADL is considered as an effective architecture description language in terms of richness in modeling both the system architecture and its dynamic behavior. However, it lacks a formal model to represent the required semantics.

In this paper, we have proposed an extension of the BRS model to formalize the dynamic architectural reconfiguration of AADL systems. Then, we have demonstrated our approach through a case study of an ATM System. Our ongoing research focuses on handling BRS to adopt the context-aware information.

7. References

[1] P.C. Ölveczky, A. Boronat, J. Meseguer, “Formal semantics and analysis of behavioral AADL models in real-time Maude”, Lecture Notes in Computer Science, volume 6117/2010, Springer, 2010, pp. 47-62.

[2] N. Benlahrache, F. Belala, K. Barkaoui, “Description formelle du déploiement d’architectures AADL basée sur les systèmes réactifs bigraphiques (BRS)”, CALL’2011, 5ème

Conférence Francophone sur les Architectures Logicielles, Lille, France, 2011, pp. 65-75.

[3] R. Milner, “Bigraphs and their algebra”, Proceedings of the LIX Colloquium on Emerging Trends in Concurrency Theory (LIX 2006), Electronic Notes in Theoretical Computer Science, Volume 209, Elsevier, 2008, pp. 5-19.

[4] Z. Chang, X. Mao, and Z. Qi, “Towards a formal model for reconfigurable software architectures by bigraphs”,In Proceedings of the 7th Working IEEE/IFIP Conference on Software Architecture, (WICSA 2008), IEEE Computer Society, 2008, pp. 331-334.

[5] R. Allen, R. Douence, and D. Garlan, “Specifying and analyzing dynamic software architectures”, In Proceedings of the 1st International Conference on Fundamental Approaches to Software Engineering, Lisbon, Portugal, 1998, pp. 21-33.

[6] D. Le Métayer, “Describing software architecture styles using graph grammars”, IEEE transactions on software Engineering, SE-24(7), 1998, pp. 521-533.

[7] R. Milner, “Bigraphs: a space for interaction”, Cambridge, UK, 2008, available at http://www.cl.cam.ac.uk

[8] L. Baresi, and R. Heckel, “Tutorial introduction to graph transformation: A Software Engineering Perspective”, In Proceedings of the First International Conference on Graph Transformation, (ICGT 2002) LNCS-2505, Springer-Verlag, Rome, Italy, 2002, pp. 402–429.

[9] SEI, “OSATE: An extensible Source AADL Tool Environment”. SEI AADL Team technical report, 2004.

[10] TOPCASED, “AADL Editor user manual”, 2006, Available: http://www.topcased.org/

[11] T. Vergnaud and B. Zalila, “Ocarina: a Compiler for the AADL”. Technical report, 2006, Available: http://ocarina.enst.fr

[12] F. Singhoff, A. Plantec and P. Dissaux, “The Cheddar project: a free real time scheduling analyzer”, LISyC, France, 2008, Available: http://beru.univ-brest.fr/~singhoff/cheddar/

46