International Journal of Computer Information Systems, Vol. 3, No.

3, 2011

Agglomeration of Component Based Software Engineering

Sravan Kumar Jonnalagadda1
1

Subha Sree Mallela2

2

DMS SVH College of Engineering, Department of IT, Machilipatnam, Andhra Pradesh, INDIA jnvsravankumar@gmail.com

DMS SVH College of Engineering, Department of CSE, Machilipatnam, Andhra Pradesh, INDIA

Abstract Software components are specified, designed and implemented with the intention to be reused, and they are assembled in various contexts in order to produce a multitude of software systems. In this paper, we introduce Software Architecture (SA) based approach in which the usage of the system SA and of SA verification techniques allows the system assembler to design architectural components whose interaction is verified with respect to the specified properties. One of the main problems in component assembly is how to establish properties on the assembly code by only assuming a limited knowledge of the single component properties. Answer to this problem is an architectural approach in which the software architecture imposed on the assembly prevents black-box integration anomalies. During the last two decades, there has been a growing interest in component-based software system (CBSS) development both in academia and in industry. In CBSS development, it is common to identify software modules first. Once they are determined, we need to select appropriate software components for each software module. A genetic algorithm (GA) is used to solve the optimization model for determining the optimal selection of software components for CBSS development. Performance prediction and measurement approaches for component-based software systems help software architects to evaluate their systems based on component performance specifications created by component developers. It helps practitioners to select an appropriate approach and scientists to identify interesting topics for future research. Keywords-component; component based software architecture; genetic algorithm; cohesion; coupling; reuse; performance;

world such as structured [2], object-oriented [3] and component-based. The last, component-based approach, introduces more benefits to this world in terms of reusability, flexibility and maintainability. Component-Based Approach: This approach is expected to revolutionize the development and maintenance of software systems. It increases in reuse should dramatically improve time-to-market, software lifecycle costs, and quality. Basic concepts, promises, modeling languages that help for analysis and design and recent technologies of this approach are described further in detail. So in this section the emphasis is how this approach and its seed, CBD, are taken from previous approaches and intermediary approaches such as distributed objects and distributed systems. Figure 1 depicts the transformation that occurs after object oriented approach. The distributed object approach extends the object-oriented approach with the ability to call objects across address space boundaries, typically using an object request broker capability. The distributed system approach we mean a development approach for building systems that are distributed, are often multi-tier.

I. INTRODUCTION The effective development of large-scale software systems is always a challenge to the software industry. Concepts and methods, such as abstract data types, structured programming, object orientation, design patterns, and modeling languages, have been employed to improve the effectiveness of software systems [1]. In recent years, a component- based approach to software system development has become more and more popular. A software component is defined as a unit of composition with contractually specified interfaces and explicit context dependences. Component-based software systems (CBSS) development focuses on the decomposition of a software system into functional or logical components with well-defined interfaces. It allows a software system to be developed using appropriate software components. This approach has been proven to facilitate shorter software systems development time and better system maintainability. There are three main approaches in Software Engineering

Figure (1) CBD maturity phases

[4]

Many companies today claim to be doing component-based development when what they are really doing is distributed system development, or using some kind of distributed object technology. While this can deliver significant benefits, such as allowing the technical bridging of heterogeneous systems. It does not decrease the cost of development. It is slightly addressed by using object-oriented techniques but not enough

September Issue

Page 20 of 75

ISSN 2229 5208

to make a big difference. At this point, distributed component approach is embraced in industry to reap the desired benefits, often looked for by a software development organization. This uses current build-time and run-time technologies such as Enterprise Java Beans to attempt to reduce cost and development time for distributed systems. It becomes apparent that what is needed is something that addresses both the challenge of distributed systems interoperability and the challenge of how to build individual systems that can be treated as atomic units and can easily be made to cooperate with each other. Despite the industrial evolution, mentioned above, component-based technology introduces abstraction and lower-level mechanisms but has to be orchestrated into a comprehensive software engineering process [5]. II. COMPONENT BASED DEVELOPMENT

Component-based development (CBD) is, by far, the most promising way of controlling the soaring complexity and cost of business information systems. It is also the best way to architect, design, implement, and deploy scalable systems that provide the flexibility and agility required by todays enterprise environment. CBD is the latest advance in software development, promising the possibility of extending the real world approach to create well-specified parts and top incorporate legacy code wrapped as components. Many software development organizations throughout the world have learned to recognize that component development is an engineering activity. Just as CBD is a revolutionary activity emerging well beyond the programming paradigms that preceded it, component-based software engineering (CBSE) is both a subset and a revolutionary extension of current software engineering practices. In the same way, civil engineers have established standardized, time-tested engineering principles to building bridges using reusable parts, component-based software engineers must define and describe processes to assure timely completion of high quality, complex software systems that are composed of a variety of pre-built software components. III. BASIC CONCEPTS There are two basic concepts for Component-Based Development. Main one is the component and the other is interface. Their functionalities are described below in detail. A. Component The parts, which are composed, are etymologically components. The phrase component-based system has about as much inherent meaning as part-based whole. In the world of software engineering, software components enable practical reuse of software parts and amortization of investments over multiple applications. There are some other units of reuse, such as source code libraries, designs, or architectures. Therefore, to be specific, software components are binary units of independent production, acquisition, and deployment that interact to form a functioning system. Being independent and in a binary form is essential to allow for multiple independent vendors and robust integration. In the software

International Journal of Computer Information Systems, Vol. 3, No. 3, 2011 industry, the term component is used in many different ways. A descriptive explanation about component and its features from Kruchten [6] is summarized below; A component is a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component conforms to and provides the physical realization of a set of interfaces. A closer examination of this definition is warranted. First, a component is nontrivial; it is functionally and conceptually larger than a single class or a single line of code. Typically, a component encompasses the structure and behavior of a collaboration of classes. Second, a component is nearly independent of other components. It rarely stands alone. A given component collaborates with other components and in so doing assumes a specific architectural context. This architectural context is driven in large part by the implementation, which is chosen. Third, a component is a replaceable part of a system. A component is substitutable for any other component, which realizes the same interfaces. This aspect helps during development, where parts of a system can be stubbed, sketched, and then replaced by mature, robust implementations. It also supports the evolution of a system, once deployed by making it possible to upgrade and evolve parts of the system independently. Fourth, a component fulfills a clear function. A component is logically and physically cohesive, and thus denotes a meaningful structural and/or behavioral chunk of a larger system. It is not just some arbitrary grouping. Fifth, a component exists in the context of a well-defined architecture. A component represents a fundamental building block upon which systems can be designed and composed. This definition is recursive: a system at one level of abstraction may simply be a component at a higher level of abstraction. Components never stand alone, though. Every component presupposes an architectural and technology context wherein it is intended to be used. Finally, a component conforms to a set of interfaces. A component that conforms to a given interface means that it satisfies the contract specified by that interface and may be substituted in any context wherein that interface applies. B. Interface Kruchten defines an interface as a collection of operations that are used to specify a service of a component [6]. An interface serves to name a collection of operations and specify their signatures and protocols. An interface focuses upon the behavior, not the structure, of a given service. An interface offers no implementation for any of its operations. An interface is used for specifying a service. An interface gives a name to a collection of operations that work together to carry out some logically interesting behavior of a system or a part of a system. An interface defines a service offered by a component (or a class). An interface defines a service that is in turn implemented by a class or a component. As such, an interface spans the logical and physical boundaries of a system. One or more classes (which are likely a part of some

September Issue

Page 21 of 75

ISSN 2229 5208

component subsystem) may provide a logical implementation of a given interface; one or more components may provide a physical packaging that conforms to that same interface. IV. BUILDING AN ARCHITECTURAL MODEL

International Journal of Computer Information Systems, Vol. 3, No. 3, 2011 system as third-party components. Indeed, in CHARMY this task is completely delegated to the developer. V. METHOD DESCRIPTION

Two antonymous approaches to guarantee that a software system satisfies a set of properties: A. Architectural analysis: The analysis process is based on checking if the specified properties hold in the SA design of the assembled system via, e.g., model-checking techniques [1]. B. Code Synthesis Code synthesis technique can be defined in order to generate the correct assembly code for the (preselected and preacquired) components forming the specified system. Both approaches have advantages and drawbacks. On the one hand the architectural analysis permits to formally prove that an SA satisfies given properties, under the assumption that the running version of the system will completely conform to its SA. Unfortunately, this is not always the case. As a result the verification step might loose much of its power, being conducted on an SA that might refer to a system that is different from the implemented one, e.g., the SA might refer to only an abstraction of the actual system. On the other hand, performing automatic verification of an SA that is too close to its implementation may lead to the statespace explosion phenomenon hence making the analysis useless. As a consequence, in this work, an SA-based approach that combines architectural analysis and code synthesis in order to efficiently and correctly assemble a system out of a set of already implemented components. The assembled system must be synthesized in such a way that it can evolve, at run-time, to possible changes (e.g., component replacement). Firstly, the systems SA is verified and refined with respect to a set of properties of interest (i.e., standard analysis). Successively, an initial version of the composed system is built by taking into account both the models of the architectural components in the SA and the ones of the actual components. Actual components are selected and acquired on the market in order to implement a verified architectural component. This approach builds on two existing approaches that have been developed by some of the authors. One has been implemented in the CHARMY tool [7] (architectural analysis) and the other in the SYNTHESIS tool [8]. These two approaches take advantage from each other. On the one hand, CHARMY provides SYNTHESIS with an already verified systems SA. SYNTHESIS can exploit this systems SA to perform adaptation locally on each architectural component rather than at the level of the global system interactions, thus reducing the state-space explosion phenomenon. On the other hand, SYNTHESIS adds to CHARMY automation in assembling and implementing the designed and verified

This method is composed of four main phases organized as shown in Fig. 2 In the following the description of the method assumes that an SA has been modeled by using CHARMY (System SA + properties of interest in Fig.2).

Figure 2: Method Description

A.

Design-time phase:

The first phase concerns the system SA verification. This phase is performed by using CHARMY. The input of this phase is an SA and the properties that one wants to check. The output is a system SA specification that respects the properties of interest (Verified system SA in Fig. 2). For each verified architectural component that has not yet been implemented, the Actual components selection phase is performed. After that all the architectural components have been implemented, they are deployed (Re-implemented components deployment in Fig. 2) hence producing a first running version of the system (Running system in Fig. 2). B. Actual components selection phase: Our method implements each architectural component as an assembly of actual components acquired from a third-party, when possible. This phase aims at selecting third-party components by looking at their interfaces and functionalities. This phase and the selection criteria used to establish which actual components have to be acquired to implement an architectural component. This phase takes as input a verified architectural component and it is performed with respect to a repository of actual components acquired from a third-party (black-box components). The output is the set of actual

September Issue

Page 22 of 75

ISSN 2229 5208

components selected as possible candidates for the implementation of the architectural one or an empty set. In case of an empty set, the architectural component is manually implemented (Manually implemented architectural component in Fig. 2) since we did not find suitable components that can be assembled to implement the considered architectural component. In this case it is up to the developer to guarantee that the component implementation conforms to its architectural specification, e.g., via verification techniques. If possible candidates are found (Selected actual components in Fig. 2) they could still need some adaptations (e.g., they might provide more functionalities as needed or interaction mismatches might occur). The compile-time phase and the run-time phase will automatically manage that in the first implementation of the architectural component and in its further implementations, respectively. C. Compile-time phase In order to correctly implement the considered architectural component automatically produces an assembly of the selected actual components that is correct with respect to the architectural components observable behavior (Automatically implemented architectural component in Fig. 2). D. Run-time phase: When a new implementation of an architectural component is needed, the correct implementation of the considered architectural component is produced analogously to what is done in the compile-time phase. The run-time phase performs additional operations with respect to the compile-time phase. These operations are the stop of the running system in a consistent state and the transfer of the computational state. One of the main problems in component assembly is how to establish properties on the assembly code by only assuming a limited knowledge of the single component properties. Our answer to this problem is an architectural approach in which the software architecture imposed on the assembly prevents black-box integration anomalies. The basic idea is to build applications by assuming a coordinator-based architectural style. We, then, operate on the coordinating part of the system architecture to obtain an equivalent version of the system which is failure-free. A failure-free system is a deadlock-free one and it does not violate any specified coordination policy. A coordination policy models those interactions of components that are actually needed for the overall purpose of the system. One of the main problems in component assembly is related to the ability to establish properties on the assembly code by only assuming a limited knowledge of the single component properties. Our answer to this problem is software architecture-based approach in which the software architecture imposed on the assembly prevents black-box integration anomalies. Notably, in the context of component-based concurrent systems, Commercial-Off-The-Shelf (COTS) component integration may cause deadlocks or other software anomalies within the system [9]. Building a system from a set of COTS components introduces a set of problems. Many of

International Journal of Computer Information Systems, Vol. 3, No. 3, 2011 them arise because of the nature of COTS components. They are truly black-box and developers have no method of looking inside the box. This limit is coupled with an insufficient behavioral specification of the components, which does not permit the understanding of the interaction of components. Component assembly can result in architectural mismatches when trying to integrate components with incompatible interaction behavior [10]. Thus if we want to ensure that a component-based system obeys specified behavioral properties, we must take into account the component interaction behavior. In this context, the notion of software architecture assumes a key role since it represents the reference skeleton used to compose components and let them interact. In the software architecture domain, the interaction among the components is represented by the notion of a software connector. VI. OPTIMIZATION OF SOFTWARE COMPONENTS SELECTION FOR COMPONENT-BASED SOFTWARE SYSTEM DEVELOPMENT In CBSS development, it is common to identify software modules first. Once they are determined, we need to select appropriate software components for each software module. The formulation of an optimization model of software components selection for CBSS development has two objectives: maximizing the functional performance of the CBSS and maximizing the cohesion and minimizing the coupling of software modules. In the development of modular based conventional software systems, the criteria of minimizing the coupling and maximizing the cohesion of software modules were commonly used [11] Coupling is about the measure of interactions among software modules while cohesion is about the measure of interactions among the software components which are within a software module. A good software system should possess software modules with high cohesion and low coupling. A highly cohesive module exhibits high reusability and loosely coupled systems enable easy maintenance of a software system [12]. The software quality metrics of coupling and cohesion were proposed by Larry Constantine based on characteristics of good programming practices that aimed at reducing maintenance and modification costs. A methodology proposed to perform the optimal selection of software components for CBSS development based on the criteria of minimal coupling and maximal cohesion of software modules as well as maximizing the functional performance of a CBSS yielded by selected software components. Because the optimization model to be formulated based on the proposed methodology is a quadratic binary type containing quadratic constraints, a genetic algorithm (GA) is introduced to solve the optimization problem [13]. With this a modified way of measuring the cohesion and coupling of software modules and considering the function ratings of various software components for CBSS development are introduced. Based on that proposed methodology, an optimization model can be formulated to perform the selection of software components for the software

September Issue

Page 23 of 75

ISSN 2229 5208

modules of a CBSS. To obtain an optimal/near optimal solution for the selection of software components, GA is introduced to solve the optimization problem. VII. RELIABILITY ESTIMATION OF COMPONENT BASED SOFTWARE Now in order to satisfy the users needs, software systems must demonstrate high reliability; they must function correctly and without interruption. For example, high reliability is needed when ensuring information exchange over network in urgent situations. Moreover, reliability is a perquisite for meeting security requirements and service availability. Therefore, reliability is a precondition for achieving customer satisfaction and realizing profit potential. The nature of software engineering is changing. The software industry has adopted a lean and agile development approach, in which small teams typically perform short development iterations and frequent and continuous deployment for the same system in parallel. Whereas the previous predominant activity was building systems and significant amounts of new software, now software engineering aims at composing existing opensource, commercial and proprietary components in creative configurations and building functionality that is truly competitively differentiating. Thus, instead of coding, software engineering is now more focused on architecture design, component selection and system integration tasks. Software engineering is an incremental and iterative process that applies the top-down and bottom-up approaches concurrently; the architecture is the result of top-down design and the components selected for its realization are made using the bottom-up approach. The control and coordination of software development cannot be based on traditional software processes because external partners and third-party developers cannot be subjected to these processes. Therefore, the architecture of the system needs to shoulder this responsibility and help independent and mostly decoupled teams to evolve their parts of the system without causing problems. The quality of the system architecture is the critical success factor in collaboration-based software engineering. Thus, the three key drivers in architecture-centric software engineering are: (i) the architecture has to tolerate evolution and allow the replacement of existing components with new ones; (ii) it must be possible to evaluate the quality of the architecture and implementation components; and (iii) it must be possible to ensure that the software system meets the desired requirements. This paper addresses reliability evaluation as one part of software quality evaluation. Reliability is one of the execution qualities and is defined as the probability of the failure-free operation of a piece of software for a specified period of time in a specified environment [14].One unreliable component in a critical path can ruin a software system. Thus, critical components must pass a thorough reliability evaluation before their integration into a software system. The reliability of a component depends on its internal capabilities, e.g. implementation technology,

International Journal of Computer Information Systems, Vol. 3, No. 3, 2011 size and complexity, and information about which of these may be unavailable or not yet exist, while architecting. Thus, the properties of components are to be defined or estimated at the required level of detail in the component descriptions. The reliability of a software system depends on the reliability of the individual components, component interactions and execution environment. In addition, the impact of faults on reliability differs depending on how the system is used. Reliability evaluation is a complex task that imposes a set of requirements for a software design and can be made using analytical, simulation and monitoring methods. Reliability prediction is an analytical method calculating predicted Probability of Failure (PoF) values for components, execution paths and the whole software system. Reliability testing exploits monitoring method producing measured PoF values for components in different execution paths. The system-level reliability prediction enables reliability errors to be caught early at the design level and thus reduces implementation effort and maintenance costs later on. A thorough comparison of the reliability evaluation methods given in [15] reveals that although several methods capable of predicting reliability from software architecture exist, they still have serious short comings that restrict or prevent their application in the industry. The most common shortcomings are a lack of supporting tools, the weak reliability analysis of software components and the weak validation of the methods and their results. However, we think that the lack of co-operation is the most serious shortcoming of existing reliability evaluation methods. The reason is that the methods (and supporting tools) are developed separately and are not generally capable of sharing information and models. Thus, an integrated approach for reliability evaluation is needed. Such an approach will allow software developers to do system-level reliability evaluations on architecture models containing both the notyet-implemented components and the existing components and repeat the evaluation quickly and easily in each iteration cycle of the software development. VIII. PERFORMANCE EVALUATION OF A COMPONENT BASED SYSTEM Component performance models are required to support the component-based software development process and to exploit the benefits of the component paradigm, such as reuse and division of work. The challenge for component performance models is that the performance of a software component in a running system depends on the context it is deployed into and its usage profile, which is usually unknown to the component developer creating the model of an individual component.

Figure 3: Factors influencing component performance

September Issue

Page 24 of 75

ISSN 2229 5208

Specifying the performance of reusable software components is difficult, because the provided performance depends not only on the component implementation, but also on the context the component is deployed into. Factors influencing the performance of software components are fig: 3 and [16] A. Component implementation Component developers can implement the functionality specified by an interface in different ways. Two components can provide the same service functionally, but exhibit different execution times running on the same resources and given the same inputs. B. Required services When a component service A invokes required services B, the execution time of B adds up to the execution time of A. Therefore, the overall execution time of a component service depends on the execution time of required services. C. Deployment platform Different software architects deploy a software component to different platforms. A deployment platform may include several software layers (e.g., component container, virtual machine, operating system, etc.) and hardware (e.g., processor, storage device, network, etc.). D. Usage profile Clients can invoke component services with different input parameters. The execution time of a service can change depending on the values of the input parameters. Besides input parameters of provided services, components may also receive parameters as the result of calls to required services. The values of these parameters can also influence the execution time of a service. Furthermore, components can have an internal state from initialization or former executions, which changes execution times. E. Resource contention A software component typically does not execute as a single process in isolation on a given platform. The induced waiting times for accessing limited resources add up to the execution time of a software component. IX. SECURITY CYCLE
CHARACTERIZATION OF

International Journal of Computer Information Systems, Vol. 3, No. 3, 2011 stage. In this phase, security properties of the components functionality are identified and expressed with the component interface. Secondly, component packaging phase concerns with the certification process of the published security properties of the component at the certification stage. Thirdly, system compositional phase falls under the deployment stage. In this stage, static or run-time compositional security contracts between components and other systems take place. Finally, in the post compositional phase, the ultimate security properties of the federated system is derived based on the security properties of the atomic components and their compositional contracts with others within the system. We call it operational stage because the component is in actual operation at this stage. In Figure 4, the dotted rounded rectangles depict four processes corresponding the four life cycle phases. The arrows between different processes show the sequence and their dependency. Iteration between characterizing security properties and approving and sealing published properties is needed because a component may modify its published properties in a later stage of its life cycle. In that case, it requires a new certificate. Similarly, iteration is required between compositional security contract and systems level security contract due to constant configuration and reconfiguration of the entire system with various components. The enclosing system from time to time may require different types of functionality and accordingly, the composition of the security contracts need to be re-tested and recharacterised to match the re-configuration requirements of the system in order to support system evolution. The horizontal lines show the separation of processes. The dotted vertical line shows the progression of the processes matching the life cycle of the component in terms of time.

COMPONENT LIFE

This includes four aspects of security characterization: (1) security characterization of atomic components; (2) certification of characterized security properties at the atomic component level; (3) compatibility checking of security properties between components; and (4) security characterization of the composite system [8]. Figure 4 shows the component life cycle and the corresponding four aspects of the security characterization process. The life cycle of software components is divided into four distinct phases at different development stages. Firstly, component development phase is the pre-certification phase falls under the construction

Figure 4: Component Life Cycle

The first two processes of characterizing security properties of atomic components and approving and sealing published properties are achieved during the development of components, whereas the compatibility checking of the characterized properties is accomplished automatically at the development stage by the interested parties. The characterization of a composite system is formed when a

September Issue

Page 25 of 75

ISSN 2229 5208

International Journal of Computer Information Systems, Vol. 3, No. 3, 2011 system is complete at the operational stage. The characterized properties of the atomic components are static in a sense that these cannot be modified unless a change of the component is done, whereas the compositional security contract (CsC) and systems-level security contract (SsC) are dynamic because these properties depend on the actual composition. X. CONCLUSION Component-based approach can increase software-building performance with effective component repository. In this paper, a methodology of selecting software components for CBSS development is described. Compared with the previous studies on CBSS development, a modified way of measuring the cohesion and coupling of software modules and considering the function ratings of various software components for CBSS development are introduced in this research. Based on that proposed methodology, an optimization model can be formulated to perform the selection of software components for the software modules of a CBSS. To obtain an optimal/near optimal solution for the selection of software components, GA is introduced to solve the optimization problem. There is a need for a systematic approach that facilitates software developers to both construct reliable component-based software systems and ensure that the software architecture, selected components and constructed software system meet the reliability goals. This paper focused on the reliability evaluation as one part of the software quality evaluation. The area of performance evaluations for component-based software engineering has significantly matured over the last decade. Several features have been adopted as good engineering practice and should influence the creation of new approaches. A mixed approach, where individual components as well as the deployment platform are measured and the application architecture and the usage profile are modeled, is advantageous to deal with the complexity of the deployment platform while at the same time enabling early life-cycle performance predictions. The necessary parameterized performance modeling language for software components has become clearer. REFERENCES
[1] [2] Clarke, E.M., Grumberg, O., Peled, D.A., 2001. Model Checking. The MIT Press, Massachusetts Institute of Technology. (references) PRESSMAN Roger, Software Engineering, McGraw Hill, 1997. [7] [8] [9] [10] [11] [12] [3] [4] [5] [6] HILL, Bennett, McROBB, Farmer, Object Oriented System Analysis and Design (using UML), 2nd Edition, McGraw Hill, 2002. HERZUM Peter, SIMS Oliver, Business Component Factory, Wiley, 1999. DOGRU Ali H., TANIK Murat M., A Process Model for ComponentOriented Software Engineering, IEEE Software, March/April 2003. KRUCHTEN Philippe, Modeling Component Systems with the Unified Modeling Language, http://cis.cs.tu-berlin.de/Lehre/WS0001/Sonstiges/ konteng_sem/papers/Modeling_Component_systems_with_UML.pdf, last access:01.12.2005. Charmy Project, 2004. Charmy web site. <http://www.di.univaq.it/charmy>. Synthesis Project, 2004. Synthesis web site. <http://www.di.univaq.it/tivoli/ SYNTHESIS/synthesis.php>. C. Szyperski, Component Software. Beyond Object Oriented Programming, Addison Wesley, Harlow, England, 1998. D. Garlan, R. Allen, J. Ockerbloom, Architectural mismatch: Why reuse is so hard, IEEE Software 12 (6) (1995). Carlo, G., Mehdi, J., & Dino, M. (1991). Fundamentals of software engineering. Prentice-Hall, Inc. Seker, R., van der Merwe, A. J., Kotze, P., Tanik, M. M., & Paul, R. (2004). Assessment of coupling and cohesion for component-based software by using Shannon languages. Journal of Integrated Design & Process Science, 8(4), 3343. Chan, W. T., & Tan, C. Y. (1996). Genetic-algorithm programming of road maintenance and rehabilitation. Journal of Transportation Engineering, 122, 246. Rodrigues, G.N., Rosenblum, D.S, Uchitel, S. Reliability Prediction in Model-Driven Development. MoDELS 2005, in: Briand, L., Williams, C. (Eds.), LNCS 3713, pp. 339353. Immonen, A., Niemela, E., 2008. Survey of reliability and availability prediction methods from the viewpoint of software architecture. Software and Systems Modelling 7 (1), 4965. Steffen Becker, Ralf Reussner, The impact of software component adaptation on quality of service properties, L'objet 12 (1) (2006) 105125. AUTHORS PROFILE

[13]

[14]

[15]

[16]

Sravan Kumar Jonnalagadda Pursued his M.Tech in Computer Science at Acharya Nagarjuna University. Now, he is an Assistant Professor in department of Information Technology in DMSSVH College of engineering, Machilipatnam (India). He has published papers in International Journals, Conferences, National Seminars and also attended for Workshop conducted by several universities.His current research interest includes Network Security and Software Engineering. Subha Sree Mallela Pursued her M.Tech in Computer Science and Engineering at Acharya Nagarjuna University. Now, she is an Assistant Professor in department of Computer Science in DMSSVH College of engineering, Machilipatnam (India). She has published papers in International Journals, Conferences, National Seminars and also attended for Workshop conducted by several universities Her current research interest includes Network Security, Software Engineering and Aspect Oriented Programming .

September Issue

Page 26 of 75

ISSN 2229 5208