Potential Link between NFRs and Self Properties

(1)

International Journal of Electrical, Electronics and Computer Systems (IJEECS)

________________________________________________________________________________________________

ISSN (Online): 2347-2820, Volume -3, Issue-2 2015 95

Potential Link between NFRs and Self Properties

1Harsimran Kaur, ²Sonam Mahajan, ³Aman Arora

1Research Scholar, ASU, Gurgaon

2Student, SSIET, Amritsar

3Assistant Professor, SSIET, Amrtitsar

Abstract— Self Properties are the important characteristics for self adaptive software’s. These properties have been defined by researchers in accordance to biological self- adaptation mechanisms [12]. Beside self properties Quality Factors (Non-functional requirements) are also important for self adaptive software. In this paper we will discuss the potential link between NFRs and self properties. Paper also implements the self adaptive software with the help of Java RMI by modifying its original architecture. The Proposed architecture is named as Buffering RMI which supports self adaptive software.

Index Terms— Non Functional Requirements, Self adaptive software’s, Java RMI.

I. INTRODUCTION

Emergence of highly distributed, mobile, and embedded systems has prompted the development of a new class of software systems, namely self-adaptive software systems, which can modify their behavior at run-time due to changes in the system, its requirements, or the environment in which it is deployed [12]. The self- adaptation problem being considered is how to obtain reliable and available stock quotes through architectural reconfiguration. Besides other stock it is assumed that the non-functional requirements (NFR) has important role in adaptive software’s. The links can help us define and understand self-* properties better, and to utilize the existing body of knowledge on quality factors, metrics, and requirements, in developing and operating self- adaptive software. According to [12]: To demonstrate such relationships, it is better to analyze how a well- known set of quality factors defined in the ISO 9126-1 quality model [3] are linked to major and primitive self-*

properties.

The paper is organized as follows: section 2 will discuss the link of NFR in self adaptive software. Section 3 will show the improved architecture of Java RMI that can be used for implementing Self-Adaptive software.

II. NFR AND SELF PROPERTIES

Self Properties has a hierarchy in three levels as shown in figure 1 [12].

Figure 1: Hierarchy of the Self-* Properties Self-configuring potentially impacts several quality factors, such as maintainability, functionality, portability, and usability. One may argue that self-configuring may be linked to reliability as well. This depends on the definition of reconfiguring. For self-healing, the main objective is to maximize the availability, survivability, maintainability, and reliability of the system [2]. Self optimizing has a strong relationship with efficiency.

Since minimizing response time is often one of the primary system requirements, it also impacts functionality. On the other hand, self-protecting has a strong relationship with reliability, and it can also be linked to functionality. Primitive properties may also impact quality factors, such as maintainability, functionality, and portability. Sterritt etal. [11] also emphasize this view by discussing the relationship between dependability aspects (e.g., availability and reliability) and the self-* properties [10].

Consequently, the ideas developed in the context of software quality for realizing and measuring quality (including all -ilities) are potentially applicable to self- adaptive software. A few research efforts, like [9], have aimed to establish this link. The important point is that self-* properties are mostly related to Several researchers

(2)

________________________________________________________________________________________________

have used NFR models, particularly goal models, in self- adaptive software..

III. IMPLEMENTATION OF SELF ADAPTIVE SOFTWARE WITH JAVA RMI

The Remote Method Invocation (RMI) as shown in figure 2 is an API that provides a mechanism to create distributed application in java. The RMI allows an object to invoke methods on an object running in another JVM.

RMI applications often comprise two separate programs, a server and a client with registry. Effort has been put to make this system as self adaptive by making few alterations in Java RMI Architecture. The alternative architecture (Buffering RMI) is shown in Figure 3. The working of RMI new architecture is shown with the example of telecom industry. The complaint system of the telecom is made distributed with the help of RMI.

According to the present architecture if the registry got stopped then any complaint submitted through client side cannot be accepted But with the Buffering architecture when Registry is shut down then Buffer in client side accepts the request of Clients. In this example as shown in Figure 4 and Figure 5 only client and server are running. Complaint got accepted without having registry between client and server [12]. The Buffering RMI works as follow:

i. The server of the RMI listening for an incoming connection request.

ii. A client queries for the specific type of remote object with an RMI registry to obtain stub.

iii. The client application calls a specific initialization method on a stub. The stub will forward the invocation to the RRL.

iv. The RRL parses the method invocation, looks for available RMI servers on the basis of information present in repository.

v. If the connection is not possible then buffer in client side server the need of client for that time.

vi. Data are loaded by server-side buffer to the client through sockets automatically. The controller on the client side buffer collects data, which are stored in the server buffer when connection is made.

vii. If subsequent data requests from client applications can be satisfied by data stored in the buffer, these method invocations will be returned immediately.

Figure 2. Original Architecture of Java RMI

Figure 3. Alternative Architecture of Java RMI (Buffering RMI)

By adding protocol extensions the new architecture becomes more reliable. It allows the client to avoid waiting for a communications request by increases the buffer area so that a client can complete his work whenever wants. There is overhead incurred by the additional work in creating a Repository and object on the client side and on server side. But it improves communication. Obviously this communication is going to be benefit whenever the efficiency of the remote method is greater than the overhead cost. The algorithm used aims to exploit Java RMI to replicate objects so as to ensure both availability and adaptability. As the Java RMI architecture includes a remote server called registry, used as a repository facility for registering remote objects and retrieving stubs for them. Each registry object acts independently and maintains a different set of bindings (name, remote object), thus constituting a single point of failure. Furthermore, a registry object running on a certain host can be used to register only remote objects running on the same host; thus, in order to obtain a stub

Client

Stub

RRL Buffer

Server

Skeleton

RRL

Transport Layer

Buffer Controller

Algorithm for Registry Repository

(3)

________________________________________________________________________________________________

for a certain service, a client need to be aware of its location. This registry algorithm makes registry objects running in a distributed system cooperate in order to maintain a replicated database of bindings and offer a reliable and high-available repository facility. A distributed system can be designed by including a certain number of registry replicas running on different hosts and possibly on distinct portions of the communication network. Clients access these replicas through standard RMI interactions as if they were a single registry, and are guaranteed that their invocation will successfully terminate, provided that at least one operational replica is running in their partition.

Algorithm:

i. This algorithm comprises two methods lookup () and update ().

ii. Update includes further two methods bind () and remove ().

iii. The Remote lookup (String name) method returns the stub for the remote object group identified by a certain name. The RID bind (String name, Remote remote) method is used to add a replicated remote object to the remote object group registered under a certain name. It returns a binding identifier RID used to globally identify the registration of this replicated remote object.

iv. RIDs are generated by the local registry stubs, and are composed by the identifier of the client issuing the bind operation plus an invocation timestamp.

RIDs are used to uniquely identify every bind operation, in order to solve the problems originated by the possibility of duplicated invocations of the same method on different replicas. Moreover, RIDs are used in the void remove (RID rid) method to remove a replicated remote object from a group; the replica to be removed is identified by the binding identifier obtained when it has been registered.

v. Suppose p has maintained the registry replicas and q is the new object. Bound[q] is a set containing the bindings that p knows that q has added to its database, while variable removed[q] is a set containing the RID identifiers that p knows that q has removed.

vi. Since each registry replica maintains its copy of the update set, the lookup method can be executed locally: the replica that receives the method invocation inspects its local database and returns the set of remote objects that have been registered under a certain name and have not been removed.

vii. The behavior of update methods is different, since they involve the update of each replica forming

the registry group. When replica receives a bind or remove method invocation, it multicasts a BIND or REMOVE message to the replicas in its current view.

Replicas must be able to react opportunely to new failure scenarios as depicted by views, for example by modifying the quality of the service they provide or trying to recover from previous failures. The fact that our partitionable group membership service allows the existence of multiple, concurrent views enables members to provide continuously available services in every partition of the system, but requires particular attention from application developers. Replicas contained in a partition may carry on the computation independently from the replicas not contained in it; but when the partition merges with another one, a reconciliation protocol is needed. This reconciliation protocol depends on the application semantics and must be carefully designed in order to minimize the number of messages exchanged. For this application availability, reliability, security is the few NFR which need to be specify while designing the system [1][5][9]. This example shows that there is a link between NFR and self properties of self adaptive software. So we need to focus on NFR specification and other issues while dealing with self adaptive software [12].

Figure 4. Client and Server are running but not registry

Figure 5. Complaint accepted even when registry is shut down in buffering architecture

(4)

________________________________________________________________________________________________

IV. CONCLUSION AND FUTURE WORK.

NFR (Quality Factors) is one of the soft areas of software engineering. There need to focus on the challenges for self-adaptive software’s which are mostly related to non functional requirements. As proposed in [7][12] coupling the software with formal modelling can allow monitoring and correctness and many other metrics with respect to specified requirement and properties. Many existing models and methods cannot be directly applied to self- adaptive software as they are meant for non adaptive software. So there is need to design the architecture by taking self adaptive software into consideration. One of the examples is shown with the help of Java RMI Architecture in this paper.

REFERENCES

[1] Dewi Mairiza et al. (2010) , An investigation into the notion of non-functional requirements, Proceedings of SAC’10, Pages 311-317, ACM New York, NY, USA

[2] Ganek, A. G. and Corbi, T. A. 2003. The dawning of the autonomic computing era. IBM Sys.Journal, Special Issues on Autonomic Computing 42.

[3] ISO/IEC 9126-1:2001(E): Software Engineering - Product Quality - Part 1: Quality Model(2001) [4] J. Mylopoulos, L. Chung, B. Nixon (1992).

Representing and Using Nonfunctional Requirements: A Process- Oriented Approach.

IEEE Transactions on Software Engineering 18, 6 (June 1992). 483-497.

[5] M. Glinz, "On non-functional requirements," in 15^th IEEE International Requirements Engineering Conference (RE '07), 2007, pp. 21-26.

[6] M. Glinz, "Rethinking the notion of non- functional requirements," in Third World

Congress for Software Quality, Munich, Germany, 2005, pp. 55-64.

[7] Pavlovic, D. 2000. Towards semantics of self- adaptive software. In Proc. of Int. Workshop on Self-Adaptive Software. Lecture Notes in Computer Science, vol. 1936. 65-74.

[8] Saeed Ullah, Muzaffar Iq bal, Aamir Mehmood Khan,( 2011) A Survey on Issues in Non- Functional Requirements Elicitation Computer Networks and Information Technology (ICCNIT), 2011 International Conference on 978-1-61284- 941-6/11 IEEE.

[9] Salehie, M. and Tahvildari, L. 2007. A weighted voting mechanism for action selection problem in self-adaptive software. In Proc. IEEE Int. Conf. on Self-Adaptive and Self-Organizing Systems. 328- 331.

[10] Sterritt, R. and Bustard, D. W. 2003. Autonomic computing - a means of achieving dependability?

In Proc. of IEEE Symp. and Workshops on Eng.

of Computer-Based Sys. 247-251.

[11] Sterritt, R., Parashar, M., Tianfield, H., and Unland, R. 2005. A concise introduction to autonomic computing. Advanced Eng. Informatics 19, 181-187.

[12] M. Salehie and L. Tahvildari, &ldquo,Self- Adaptive Software: Landscape and Research Challenges,&rdquo, ACM Trans. Autonomous and Adaptive Systems, vol. 4, no. 2, pp. 1-42, May 2009.

[13] SUN Microsystems (2004) Java TM Remote Method Invocation – RMI extensions. White paper, SUN Microsystems, 2004. Internet Publication .

