Scholarly article on topic 'Precepts and Evolvability of Complex Systems'

Precepts and Evolvability of Complex Systems Academic research paper on "Computer and information sciences"

CC BY-NC-ND
0
0
Share paper
Academic journal
Procedia Computer Science
OECD Field of science
Keywords
{Evolvability / "Complex Systems" / "Control Flows" / "Software Evolution" / "Evolvability Metrics" / Precepts.}

Abstract of research paper on Computer and information sciences, author of scientific article — Urjaswala Vora

Abstract In complex enterprise systems that undergo continual evolutions, the change impact tends to get cumulative and adverse and have high probability of degradation of software quality. Functional evolutions are the most frequent and the most impacting evolutions. The functional components in a software architecture that are aligned with them are the activities. Activity is a business process that fulfils an operation contract of an application. An application is a set of activities that get invoked by different users. In the software evolution process, the change impact analysis techniques generate the model(s) of the data-flows and/or control-flows within the source code for the activity to be evolved. They capture the propagation of changes and derive the change impact sets which are then used for the planning, estimation, development and verification phases of the evolution process. The taxonomical surveys of evolutions indicate that the control structures embedded within the source code undergo changes much more rapidly than the other elements and are the major culprits in the evolvability degradation. We define an architectural approach of modeling the control structures within the activities of an application as precepts, the control-flow rule-sets, that mitigates the adverse impact of evolution. Precepts also facilitate the definition of Evolvability Metrics that measure the evolvability index of an application. The existing metrics that indicate evolvability, measure the complexity as well as modularity at a low level and cannot be aggregated trivially. To validate these metrics, we define Efforts Deviation Index that captures the difficulty level of the change implementation process.

Academic research paper on topic "Precepts and Evolvability of Complex Systems"

Available online at www.sciencedirect.com

ScienceDirect PrOC6d ¡0

Computer Science

Procedia Computer Science 62 (2015) 565 - 574

The 2015 International Conference on Soft Computing and Software Engineering (SCSE 2015)

Precepts and Evolvability of Complex Systems

Urjaswala Voraa *

aCentre for Development of Advanced Computing (C-DAC), Juhu, Mumbai 400049, India

Abstract

In complex enterprise systems that undergo continual evolutions, the change impact tends to get cumulative and adverse and have high probability of degradation of software quality. Functional evolutions are the most frequent and the most impacting evolutions. The functional components in a software architecture that are aligned with them are the activities. Activity is a business process that fulfils an operation contract of an application. An application is a set of activities that get invoked by different users. In the software evolution process, the change impact analysis techniques generate the model(s) of the data-flows and/or control-flows within the source code for the activity to be evolved. They capture the propagation of changes and derive the change impact sets which are then used for the planning, estimation, development and verification phases of the evolution process. The taxonomical surveys of evolutions indicate that the control structures embedded within the source code undergo changes much more rapidly than the other elements and are the major culprits in the evolvability degradation. We define an architectural approach of modeling the control structures within the activities of an application as precepts, the control-flow rule-sets, that mitigates the adverse impact of evolution. Precepts also facilitate the definition of Evolvability Metrics that measure the evolvability index of an application. The existing metrics that indicate evolvability, measure the complexity as well as modularity at a low level and cannot be aggregated trivially. To validate these metrics, we define Efforts Deviation Index that captures the difficulty level of the change implementation process.

© 2015TheAuthors.PublishedbyElsevierB.V.This is an open access article under the CC BY-NC-ND license (http://creativecommons.Org/licenses/by-nc-nd/4.0/).

Peer-reviewunderresponsibility of organizing committee of The 2015 International Conference on Soft Computing and Software Engineering (SCSE 2015)

Keywords: Evolvability; Complex Systems; Control Flows; Software Evolution; Evolvability Metrics; Precepts.

CrossMark

1. Introduction

Software needs to be changed on a continuous basis with major enhancements within short timescale, thus coping with the changing environments and the radically changing requirements. The modification and enhancement are referred by the terms 'maintenance' and 'evolution'. Leintz et al.28 identify the maintenance and evolution as two distinctive scenarios. Software maintenance commonly refers to the changes that address bug fixes, minor

* Tel.: +91-22-2620 1606 ; fax: +91-22-2621 0139. E-mail address: urja@cdac.in

1877-0509 © 2015 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.Org/licenses/by-nc-nd/4.0/).

Peer-review under responsibility of organizing committee of The 2015 International Conference on Soft Computing and Software Engineering (SCSE 2015)

doi:10.1016/j.procs.2015.08.533

enhancements and migration. Software evolution, on the other hand, is focussed on major functional enhancements and adaptations. Breivold et al.10 distinguish software evolvability from software maintainability and define it as 'the ability of a software system to adapt in response to changes in its environment, requirements and technologies that may have impact on the software system in terms of structural and/or functional enhancements, while still taking the architectural integrity into consideration'. Ciraci and van den Broek15 define evolvability as an attribute of the software architecture of a system. The current methods for measurement of maintainability are contested by the research community12' 15' 26 30.

Each evolution impacts different components of the software with different magnitude5' 11. Sometimes nonfunctional requirements like performance, maintainability, and testability degrade even though the functionality is error-free36. Boehm9 and Cai and Huynh12 identify two major factors, viz., modularity and complexity, that contribute to the evolvability of an architecture. The existing evolvability indicators do not consist of any direct metrics for evolvability of a system. The metrics are either indirect and/or are applied at the lower level of software architecture. Aggregating the complexity and modularity metrics values of all lower levels components effectively is a challenging task, especially for complex enterprise level systems. We propose a new set of metrics to measure evolvability of a system based on the activities of the system. Activity is a high-level functional component in the behavioural model of the software architecture of a system. An evolution is based on the changes at the activity level. The evolvability metrics satisfy the Weyuker's properties for complexity measures. The metrics can effectively differentiate among the systems that demonstrate varying design properties and hence the evolvability. The metrics values correlate with the actual change implementation efforts required for a set of evolutions.

In a software development process, the complex control structures of the activities get modelled as highly coupled components18. These control components are counterproductive to a system's evolvability. We propose an alternative modelling approach for such components as Precept that is a set of control rules39. The precept prohibits unwanted types of couplings which are otherwise unavoidable in imperatively programmed control components. We validate the mitigation of change impact and subsequent enhancement in evolvability of precept-based systems using multiple approaches and in various design scenarios.

We present literature survey in section 2. We propose an activity as the basis of evolution in section 3. We present the activity-based Evolvability Metrics in section 4. In section 5 we correlate control flows and their impact on the evolvability of an application. We discuss the mitigation of the impact of evolution in precept-oriented design as well as the effectiveness and correctness of Evolvability Metrics based on precepts in section 6. The results obtained during the validation study of the enhancement in evolvability of precept oriented systems and the correctness of Evolvability Metrics are discussed in section 7. Section 8 concludes the paper.

2. Related Work

The correctness of evolvability metrics26, 30 is an open issue. Scenario based techniques22, 23 are not very useful for quality attributes that deal with future changes15. Maintainability Index (MI)32 based on metrics such as Halstead Volume17, Cyclomatic Complexity (CC)29 and source lines of code (SLoC) has been found ineffective, particularly for the systems built using OO technology26. Metrics like cyclomatic complexity, which essentially is module based metric, are difficult to be aggregated at the class level or application level. On the other hand, Halstead's metrics17 though are measured at application level, capturing them after every evolution is a complex and error-prone task20. Alves et al.2 present a methodology for the calibration of mappings from code-level measurements to system-level ratings but the prerequisite of a large, well-curated repository of benchmark data is a subjective task. Bijlsma et al.8 establish correlation between code metrics for maintainability and duration of maintenance tasks empirically based on a limited number of Java projects and face limitations if extrapolated in different scenarios. The OO metrics14 are useful quality indicators, but they predict evolvability indirectly6 and not so effectively12 when aggregated to the application level. Also they are based on structural model where as evolvability is aligned with the activities that form a behavioural model.

Complex software systems are built by combining heterogeneous architectural styles to solve the design problems16 as every software architecture style prioritises a subset of software quality attributes and not all23. The interdependencies among the architectural components result in the propagation of change impact farther than expected leading to the undesired effects such as software ageing33, architectural erosion or decay and architectural

drift34. The OO design overcomes the flaws of structured methodology with encapsulation but the implicit control flows there add to the complexity in the important interactions of the programs. Also, OO design has proved to be inadequate in addressing design issues due to the crosscutting concerns. Aspect Oriented Software Development31 proposes a solution to this problem but faces the risk of decomposing the components with multiple concerns that may impact the quality of the system adversely. In Component-Based Software Development, software systems are built out of reusable and autonomous application components with well-defined functionality and interfaces. But the correct definition of an autonomous component and arriving at a generic design of a component is a tricky part19. The Model-Driven Engineering promises the reduction of efforts in the development and maintenance phases but it can lead to a lock-in with the abstractions and generator technology that is adopted in the project initiation stage. Service Oriented Architecture supports a flexible and dynamically reconfigurable end-to-end realization of business processes. The difficulty in organizing the solution as a framework with interconnected architectures with transformation capabilities is a challenge3. Rule-based systems as well as Workflow based systems are based on the principle of externalisation of rules making them more adaptable. In large rule-based systems, modularity breaks down leading to higher coupling24. The correctness of the execution of active workflows during the dynamic evolution of a workflow based system is still an open issue25. Other architectural styles such as the blackboard model where a complex and heterogeneous problem is solved by a set of knowledge sources. However, these systems are unable to deal with applications with complex control strategy27.

3. Activity as Basis of Evolution

An activity drives the control-flows and data-flows among the components of the system. Evolution impacts these components as they are functionally coupled. Evolvability of the architecture then depends on the design quality of these components. These characteristics of evolution and evolvability lead us to propose activity as the

basis for evolvable designs as well as for

activity

module

-uses/updates

-falls on

-chosen based on state

Figure 1. Activity Metamodel

as well as

evolvability measurement. Figure 1 illustrates the concept of activity. When defined at a higher level abstraction of software architecture, an activity is a complex subsystem which includes a number of member modules. The purpose of a module is to provide some cohesive functionality. These modules are segregated across a number of execution paths within the activity. Every

execution path of an activity represents a scenario of the use case realised by the activity. It is a

control-flow graph where each node can be reached by the entry node and each node can reach the exit node. The nodes of the control flow graph correspond to the modules that participate in the activity functions. The modules within an activity have varying complexity and may get invoked from more than one execution paths. The control flows, data flows, and the common data shared by the modules define the dependencies among the modules and paths. A module may get decomposed into a number of modules based on its complexity. In such case, the module within an activity is a nested activity.

The impact of evolution is decided by the granularity of the changes that define the evolution as well as by the types of components under change impact. We correlate the evolvability measurement with the granularity of software evolution at (i) activity level and (ii) execution-path level. An evolution when impacts the member modules that are part of multiple execution paths, the evolution is called as activity level evolution.

4. Measuring Evolvability

Correct measurement of evolvability facilitates the choice of the most evolvable design alternative among the possible set of alternatives. The extent of impact of evolution at the activity level as well as at the execution path level is decided by the evolvability of the activity. Evolvability of an activity, in turn, is measured by the design properties of its member modules. We take an example to understand the limitation of metrics that are defined on

Activity: ai

Ci-mjO

CC = 1 CC = 1

Activity: a2

Ci.m2()

Ci.m9()

CC = 20

CC = 20

CC = 1

Ci.msO

CC = i

Ci.m4()

CC = i" [ Ci.m5() k-l

CC = i

Ci.mi0()

.CC = i

Ci.m7()

CC = i

Ci.m8() 1

structural components as evolvability indicators. We use the object oriented metrics for coupling and complexity, CBO and WMC, respectively. WMC measures the complexity of an individual class and CBO provides the number

of classes to which a given class is coupled. Class Ci has 10 methods mi, m2,......m10 where mi,... m8 have complexity

of 1. But methods m9 and m10 have complexity 20 each. CC(m1),... CC(m8) = 1; CC(m9) = 20; CC(m10) = 20 each.

WMC(C1) = X CC (M) = 48 M=m1

Application A consists of two activities, a1 and a2, that invoke methods of C1 as shown in Figure 2. Activity a1 has 2 execution paths having methods of cyclomatic complexity 4 each and a2 has 2 execution paths having methods of Figure 2. Control Flow Graph of Activities ai and a2 cyclomatic complexity 42 each. If a1

evolves, the class level complexity under consideration will be 48. The changes required to be done in the modules participating in a1 have the overall complexity 5. If a2 evolves, the class level complexity under consideration will be again 48. But in this case the changes are required to be done to the modules of the overall complexity 43.

Suppose application A comprises 10 activities defined using 10 classes. Classes C1 and C2 have WMC = 50. Each

of the classes C3.....C10 has WMC as 5. Then aggregated WMC of A is 14 when Application A has 20 percent of its

classes and 20 percent of its business processes have complexity equal to 50. If 80 percent of the changes are applied to these classes then the evolvability indicated by the metric is incorrect. It indicates the same evolvability to a system having a single class implementation with WMC as 14. Thus metrics like WMC that are defined on the structural components tend to hide the extreme values concentrated within a small part of an application that may play crucial role in dynamic scenarios.

4.1. Evolvability Metrics

Evolvability of an activity is decided by the design properties of each of its member modules as well as by the complexity of the activity's control flow graph and the interactions among the member modules. The impact then needs to be measured by using an appropriate aggregation method applied on the design properties of the modules and their distribution across the execution paths of the activity. All the modules that are invoked from a single execution path are procedurally and/or sequentially cohesive. The effective evolvability at the execution-path level is the summation of the design properties of the modules that are invoked from the same path. Some paths have concentrated complexity and couplings than other paths. If modules of high complexity are invoked from multiple paths, then the change impact is higher compared to the scenario where the high complexity modules are invoked from a single path. Then the control complexity (number of execution paths) and the distribution of the design properties of the member modules across the execution paths play the major role. We propose the Evolvability Metrics that are based on: (i) Process Complexity; (ii) Modularity; and (iii) Data Coupling.

Process complexity at the method level is measured by cyclomatic complexity29, 37. Cyclomatic complexity captures the control complexity of a module and also indicates its testability. Both these quality attributes have major impact on the evolvability of a system. The first metric we define is the Complexity Index 'C' which measures the effective cyclomatic complexity of the modules that participate in an activity at the path-level, at the activity-level and at the application level.

The evolvability is impacted by the modularity of a system as much as by the complexity9. Modularity of the activity is the degree of discretion achieved in the composition of the modules35. It ensures that a change to one module has minimal impact on the other modules. We use Fan-in and Fan-out metrics of the modules invoked within the activity. The metrics measure the impact due to the coupling of the modules of an activity with the modules that are not part of the control flow graph of the activity but still are in the scope of change impact. The second metric, Modularity Index 'M' is defined at the path-level, at the activity-level and at the application level.

The third metric that we define is Data Coupling Index 'D'. Data coupling index captures the dependencies among the modules of an activity that share the same global data structures or are coupled due to the data-flows

existing between them7. Data coupling index measures these data couplings at three levels: (i) among the modules on a single execution path that is at the path level, (ii) across the execution paths that is at the activity level, and (iii) across the activities that is at the application level. The symbols used while defining the evolvability metrics are shown in Table 1.

Table 1. Symbols Used in Definition of Evolvability Metrics

Symbol Meaning Symbol Meaning Symbol Meaning

i Module Counter r A rule a An activity

Path/Rule Counter R Total number of rules in a precept A Total number of activities in an application

k Activity/Precept counter app An application C Complexity Index

m A module d A data structure/parameter M Modularity Index

P Total number of paths in an activity D Data Coupling Index

P A path Pr A precept E Efforts Deviation Index

Md Total number of modules invoked on a path or in an action clause of a rule Pr Total number of precepts in an application

4.1.1. Complexity Index (Cp\a\app) at Various Levels

Complexity Index, 'C', has the objective of measuring the impact on the evolvability of an application based on the distribution of the control complexity across the execution-paths of its activities. 'C' considers the extent of change propagation along with the complexity of modules that are part of the change set in an evolution. C measures the cyclomatic complexities of the modules that participate in the execution of an activity by getting invoked from a number of execution. Based on the applicability of the evolution we define:

Path-level Complexity Index (Cp, of path p in activity Aj having total paths P): Cp = £ CC(mi)

Activity-level Complexity Index, Ca = ( Y. Cpj) and Application-level Complexity Index, Capp = ( £ C°%)

Illustration

Activity ai

Path pi

Activity a2 Path pi

Path p2

Path p2

20 ü:

Activities a1 and a2 as shown in Figure 3 where the modules are represented by their cyclomatic complexities. Both the activities have 2 execution paths, each invoking 4 methods on the path p1 with the same cyclomatic complexities. Here for activity a1 the path p1 as well as p2 bear the cyclomatic complexity of more

Figure 3. Illustrating C: Activity Diagrams of a1 and a2

than 40. But in activity a2 the path p1 only has the cyclomatic complexity more than 40. Hence when the method which is common to both the execution paths, evolves, the impact in case of a1 is much higher than it is in case of a2. In this case the Complexity Indexes of aj and a2 are,

Caj = (20 + 5 + 20 + 5) + (20 + 5 + 1 + 5) = 81 and Ca2 = (5 +20 + 20 + 5) + (5 + 1 + 5)=61. Activity Complexity Index distinguishes the evolvability of a system having methods with the same cyclomatic complexity but distributed differently across its execution paths. This distinction facilitates the measurement of the extent of change efforts required for an evolution.

4.1.2. Modularity Index (Mp\a\app) at Various Levels

Activity Modularity Index measures the coupling between the modules participating in the activities of an application that impacts its evolvability. The modules on the execution paths of an activity may participate in other activities too. Their fan-in and fan-out thus is not quantified within the control-flow graph of a single activity. We consider the Fan-in and Fan-out of all the modules that are part of an activity to assess possible change impact across activities. Fan-out captures the coupling of each member module with the modules that get internally invoked within the activity but are not part of the activity control flow graph. Fan-in captures the number of modules that are

outside the boundary of this particular activity but may get affected if this module is impacted by an evolution. The module dependencies outside the boundary of the activity may lead to the wider ripple effect of an evolution and as a result, reduce the evolvability of an activity and its application.

Path-level modularity index (Mp, of path p with total modules Md on path p), Mp = £ Fan-in (m^ + Fan-out (m¡)

Activity-level Modularity Index, Ma = ( £ Mpj) and Application-level Modularity Index, Mapp = ( £ Mak)

j=1 k=1

Illustration

For example in Figure 4, if method m4 evolves, the impact may propagate to the modules that are considered by the fan-in and fan-out metrics of methods mi, m2, m3, m5 and m6. But if m6 is to be changed, then the modules that are part of the fan-in and fan-out of modules m2 and m3 are not under the change impact. Here, Ma1 = (15+19) = 34.

Figure 4. Illustrating M (1): Activity Diagram of a1 and Control Flow Graph of Module m4

4.1.3. Data Coupling Index (Dp^app) at Various Levels

Data Coupling Index, D, aims to measure the intra-activity data couplings as well as the inter-activity data couplings. Coupling decreases the reusability of the coupled modules and increases the complexity in changing the coupled modules. Data coupling index measures the data parameters shared by the modules that are part of the same or different execution paths. Data coupling between the execution-paths of an activity may result in wider change propagation during the evolution. Similarly, data coupling at activity level raises the risk of the change propagating to farther than expected. Different types of data couplings defined by Berard7 are Global Data Couplings (GDCs), Internal Data Couplings (IDCs) and Data Couplings (DCs). The existing architectural styles as well as the high level languages prevent IDC. Hence we consider the coupling through global data structures and through the data flows among the modules of a path (path-level), or among the paths of an activity (activity-level) or among the activities of an application (application-level).

Path-level Data Coupling Index, Dp = (dj x ij) + (d2 x i2) +.....+ (dn x in)

here, dn = a data structure/parameter shared by more than one module on path p of an activity; in = number of modules on path p that share the data structure/parameter dn.

Activity-level Data Coupling Index, Da = (dj x jj) + (d2 x j2) +.....+ (dn x jn)

here, dn = a data structure/parameter shared by more than one path of activity a;

jn = number of paths in activity a that share the data structure/parameter dn.

Application-level Data Coupling Index, Dapp = £ Dak

Illustration

For the activity a1 shown in Figure 5, there are 2 data structures, a and b, shared across 2 paths, p1 and p2. Hence, Da1 = 4.

4.2. Efforts Deviation Index (E)

Efforts deviation index, E, correlates the efforts required for an evolution in a system with its evolvability. The impact of the quality of a system on its evolution process is measured using the Efforts Deviation Index. If a system is evolvable, its design facilitates the change impact analysis as well as the change implementation. The efforts estimation in such case is more precise. Here we assume that the techniques used for effort estimation and for change impact analysis are correct and consistent for the evolutions under consideration. The evolution efforts

Activity a1

module Fan-in Fan-out

m, 3 1

m2 2 1

m3 2 1

m, 4 1

Module mi (start)

statement-block1

statement-block2 -~f --

( exit )

Activity a! {a, b, c, e} {a, b}

Path p1 Path p2

Figure 5. Illustrating D°fl1: Execution Paths of Activity a1

depends on the size of the change and the complexity of the activity to be evolved. Hence comparing the efforts-estimated or the efforts-put across a number of evolutions is incorrect. The size of change that is indicated by a metric such as enhancement function points (EFP)1 is used to estimate efforts. The actual efforts required for 1 EFP at different stages of its life cycle indicates the variation of its evolvability at that stage. For example, in a system app, efforts required for 1 EFP of evolution e1 was 5 man-days and efforts required for 1 EFP of evolution e2 was 8 man-days. It proves that the evolvability of the app has degraded between e1 and e2. The evolvability indicated by the evolvability metrics before e1 and before e2 needs to be coherent with this increase in the difficulty level of evolution. We define effort deviation index, E, as the ratio of the actual efforts-put for change implementation for an evolution to the efforts estimated based on EFPs.

Efforts Deviation Index (E) = Efforts-put / EFPs

5. Control Flows and Evolvability

The taxonomical study of evolution indicate that the control structures of complex systems get highly impacted in magnitude as well as frequency during the evolutions21. Software evolution adds new functionality and hence the complexity. It subsequently degrades the evolvability of the system. The remodelling and refactoring of the control components may repair the evolvability degradation. Control components are a few in number compared to other components. However they tend to have a highly complex control flow structure as compared to other components within the system. The difficulty level of implementing changes in such components increases so does the possibility of the changes getting propagated farther than anticipated.

Illustration

Let us take the example of ATM^ of automated teller machine and apply 5 evolutions. Table 2 presents the comparative study of the metrics for ATM vis-à-vis those for the control classes measured after every evolution. Analysing the design properties of control classes we find the following facts:

Cyclomatic Complexity(control classes) / Cyclomatic Complexity (all classes ) = 0.47 Halstead's Volume(control classes) / Halstead's Volume (all classes) = 0.42 Number of control classes / Total number of classes = 0.2 Table 2. Design Properties with respect to the Control Classes in OO-based Example: ATM

Evolution no. No. of Classes WMC CBO Halstead's Volume Cyclomatic Complexity SLoC MI

Total Classes Control CBO of All Classes CBO of Control CC of All Classes CC of Control

Classes Classes Classes

Initial 38 8 3.9 2.7 6.5 5220 148 69 5000 38.8

1. 38 8 4.13 2.78 6.7 5220 148 75 5050 38.8

2. 38 8 4.05 2.78 6.7 5450 150 76 5200 37.2

3. 40 9 4.13 2.9 6.7 5600 156 81 5400 36.8

4. 40 9 4.05 2.9 6.7 5600 156 81 5450 35.2

5. 42 9 4.13 2.9 6.7 5700 162 85 5500 34.25

We also studied these design parameters for a number of case studies that are in production and are under maintenance phase for more than five years. The facts that observed uniformly across these case studies are:

> Control components if modelled similar to other imperative components, tend to become highly coupled and complex components. Changes get propagated farther than anticipated when evolution impacts them.

> Responsibility of a control component is to control and coordinate execution of modules for an activity. They need to avoid being saddled with additional computational responsibilities.

> A control component increases the difficulty level of change implementation during evolution.

> Control components, though approximately 1/4 in number of total components, bear more than 3/4th of the application's complexity.

> Control components are the high risk centres in the evolution of a software system.

^ www.math-cs.gordon.edu/courses/cs211/ATMExample/, retrieved on March 16, 2013.

6. Precept

A precept has a dictionary meaning of a 'commandment or direction given as a rule of action or conduct' or a 'procedural directive or rule, as for the performance of some technical operation'. We define precept as a declaratively programmed component that controls and coordinates actions required to achieve a business goal of an activity. Precept implements the control structure of the activities using a rule set. The resulting architecture reduces control complexity and control coupling and hence is more evolvable.

In a precept oriented system, the activity is translated into a precept that comprises a set of declarative control flow rules. The rules control the execution of the modules. A precept's execution cycle depends on the state change of its

data parameters. The state change may occur due to the execution of a module that is part of the actions of the corresponding activity. The state change results into selection of next set of rules(s).

The modules that participate in the activity are then invoked as part of the action clause of the selected rules. The precept orientated design is presented in Figure 6. The declaratively programmed precept:

- reduces the couplings among the classes whose methods are invoked by its rules and hence the change propagation.

- is restricted from taking unnecessary responsibility of computation that otherwise is possible to be taken up by a control class. The additional responsibility tends to add complexity to the control class and makes it less evolvable.

- reduces the getter and setter methods in entity classes as computations within the control-class methods are moved as methods to appropriate entity classes.

Precept oriented systems have an advantage that the rules as well as the data required of the rule selection and execution have a well defined scope of the activity. It makes a precept oriented system more maintainable than a rule-based system. The precept model is a critical element in the design of precept oriented system. A precept is defined by a 4-tuple as, Precept = ({input parameters}, {output parameters}, {internal parameters}, {rules}). A rule in precept oriented system belongs to a single precept. We define the rule by a 2-tuple as: rule = (pre-condition, action). Pre-condition defines the required state of the working memory for the selection of the rule. The working memory includes the input, output and internal parameters of the precept. The action of a rule contains the module(s) invocations.

When a user invokes a precept through a boundary component, the corresponding input parameters are passed to the precept. The rule engine selects the rule(s) by matching the state of the working memory with the pre-conditions of the rules. When no rule can be selected further and the execution of the modules of the already selected rules is complete, the precept exits and returns its output parameters. The dataflow is not coupled with the control flow within a precept. The member modules that correspond to the methods to be invoked as part of the actions of the selected rules are not explicitly sequenced as is the case in the imperative programming. The inputs to the modules and outputs from them are managed by the working memory that facilitates the selection of the next applicable rule. This decoupling has its advantages as well as the limitations. The additional precept data is required to be maintained to ensure the correct sequencing is achieved among the modules that do not have explicit dataflow but are functionally related. A rule can also invoke another precept as part of its action resulting in a nested hierarchy. If the state of the working memory matches the pre-conditions of multiple rules then the rules are selected and their respective modules are executed concurrently. The concurrency control and synchronisation needs to be handled by the rule engine correctly.

6.1. Designing a Precept

Precept and its rules can be designed for existing systems as well as for the systems to be developed ab initio. Reverse engineering a precept has dependency on the initial design of the control component which is designed for imperative programming. We validated the design properties of a purely OO-based system against its precept-based design and the design that was reverse-engineered into precepts. The observations were:

i) The repetitive code in the control class methods gets cleaned up due to the use of the state-based rules. High control complexity translates into a number of independent execution paths. The large number of execution paths means the number of possible scenarios within the particular use case is high. When multiple scenarios are controlled from a single component, the possibility of code repetition for the common edges of the paths is high. In such cases, the declarative rules may result in more modular design.

ii) Rules with the same prerequisite state support implicit parallelism in the execution of corresponding modules. The rules are to be designed such that there are no conflicting control and/or data dependencies.

6.2 Evolvability Metrics for Precept Oriented Systems

Evolvability in precept oriented systems depends on the distribution of the design properties of modules across the rules as well as across the precepts. Hence the evolvability is measured at rule-level, at precept level and at application level. We propose the extension of Evolvability Metrics39 that are easily applicable to the precept oriented systems. The verification of the precept-based evolvability metrics if satisfy Weyuker's properties is done successfully39 proving the correctness of the metrics that are applicable irrespective of the architectural style(s) used in the design.

7. Validating Evolvability Metrics and Precept

Weyuker properties38 provide a basis for validation of complexity metrics13. The Evolvability Metrics are based on activities hence we apply Weyuker's properties to the activities of an application. When new modules are added to an activity, the evolvability does not necessarily degrade in the proportion of the complexity added as it depends on the location of the change as well. Evolvability Metrics do consider the resultant control flow graph of the activity and the effective impact of the additional complexity. Evolvability Metrics satisfy all nine Weyuker's properties indicating that the complexity of an application is measured correctly by them and so is the evolvability of an application39. We also used a number of case studies to validate (i) the effectiveness of the evolvability metrics and (ii) the mitigation of the impact of evolutions in a precept oriented system compared to its counterpart. The case studies were from different domains, implemented based on different architectural styles (purely OO-based, service oriented, workflow-based etc.) with their counterparts implemented using precept oriented design. A number of evolutions were recorded for these case studies. The quality of both design alternatives (precept-based and its counterpart) were measured after every evolution along with the efforts required for the change implementation. The observations from the validation scenarios are:

(i) The evolvability metrics capture the growth in the complexity of the activity. The reduced impact of evolutions and enhanced evolvability of the precept oriented system compared to its counterpart is seen.

(ii) Existing metrics are unable to make the distinction between the evolvability of two design alternatives of a systems though the difference in quality of design is apparent. Existing metrics measure evolvability as a function of the complexity of the structural components. The functional enhancement thus indicate evolvability degradation of the system. The mitigation of the change impact due to (i) modularity of a system; (ii) distribution of the complexity within the system is not captured as do the Evolvability Metrics.

(iii) The precept oriented complex systems require less evolution efforts with enhanced modularity and mitigated impact of evolutions, especially in case of the evolutions that require major changes in the control structure of the program.

8. Conclusion

The measurement of the evolvability of a complex software system is currently an indirect and ineffective process. We define Evolvability Metrics based on complexity and coupling properties of every activity, the unit of behavioural model rather than structural model, within an application. The metrics also consider the distribution of

complexity along with its magnitude of impact across the dynamic model of program execution. Aggregating these metrics values to the application level gives more precise indication of evolvability of the system.

There are techniques and methodologies that intend to facilitate evolution, but the change set of an evolution may lead to the architectural erosion and/or drift. Especially complex enterprise level systems facing continual evolutions have high probability to face such cumulative impact. We focus on the possibility of reduction of impact of evolution, especially by the changes that involve major modifications in the complex control flow structure. We transform the imperatively programmed control components into sets of declarative rules, precepts which are externalized resulting into refactoring of the architecture.. When such a system undergoes continual evolutions, the cumulative impact is mitigated resulting in a longer life cycle for the system.

References

1. Albrecht A. AD/M Productivity Measurement and Estimate Validation. IBM Corporation. New York; 1984.

2. Alves T., Correia J., Visser J. Benchmark-based Aggregation of Metrics to Ratings. In: Proc. of the Joint Conf. of 21st Int'l Workshop on Software Measurement and the 6th Int'l Conf. on Software Process and Product Measurement, IWSM/Mensura. Japan; November 2011.

3. Arsanjani A., Zhang L., Ellis M., Allam A., Channabasavaiah K. S3: A Service-Oriented Reference Architecture. IT Professional. Volume 9, Issue 3; May 2007. pp. 10-17.

4. Badri L., Badri M., St-Yves D. Supporting Predictive Change Impact Analysis: A Control Call Graph Based Technique. In: Proceedings of the 12th Asia-Pacific Software Engineering Conference. Taiwan; December 2005.

5. Banker R., Datar S., Zweig D. Software Complexity and Maintainability. In: Proceedings of the Int'l Conf. on Info. Systems. USA; 1989.

6. Basili V., Briand L., Melo W. A Validation of Object-Oriented Design Metrics as Quality Indicators. In: IEEE Transactions on Software Engineering. Volume 22, Issue 10. October 1996. pp. 751-761.

7. Berard E. Essays on Object-oriented Software Engineering (Vol. 1). Berard Software Engineering. Prentice-Hall; 1993.

8. Bijlsma D., Ferreira M., Luijten B., Visser J.. Faster Issue Resolution with Higher Technical Quality of Software. Software Quality Control Journal, Vol. 20(2). Kluwer Academic Publishers; June 2012. pp. 265-285.

9. Boehm B. Software Engineering Economics. Englewood Cliffs. New Jersey: Prentice-Hall; 1981.

10. Breivold H., Crnkovic I., Eriksson P. Evaluating Software Evolvability. In: Proceedings of the 7th Conference on Software Engineering Research and Practice. Sweden; 2007. pp. 96-103.

11. Briand L., Wüst J., Daly J., Porter D. Exploring the Relationship between Design Measures and Software Quality in Object-Oriented Systems. In: Journal of Systems and Software. Volume 51, Issue 3. Elsevier Science; May 2000. pp. 245 - 273.

12. Cai Y., Huynh S. Measuring Software Design Modularity. In: Proceedings of 23rd OOPSLA Companion. USA; October 2008.

13. Cardoso J., Control-flow Complexity Measurement of Processes and Weyuker's Properties. In: 6th International Enformatika Conf., Transactions on Enformatika, Systems Science & Engineering. Volume 8. 2005. pp. 213-218.

14. Chidamber S., Kemerer C.. A Metrics suite for Object Oriented Design. In: IEEE Transactions on Software Engineering Vol20/6. June 1994.

15. Ciraci S., Broek P. Evolvability as a Quality Attribute of Software Architectures. In: Proc. of ERCIM Workshop on Software Evol.; Apr'06.

16. Garlan D., Shaw M. An Introduction to Software Architecture. In: Adv. in Software Engg. and Knowledge Engg. Vol. 1. 1993. pp. 1-39.

17. Halstead M. Elements of Software Science. In: Amsterdam: Elsevier North-Holland, Inc.; 1977. ISBN 0-444-00205-7.

18. Jacobson I., Booch G., Rumbaugh J.. The Unified Software Development Process. Addison-Wesley Professional; 1999.

19. Jarzabek S., Hitz M. Business-Oriented and Component-Based Software Development and Evolution. In: Proceedings of the International Workshop on Large-Scale Software Composition. Austria; 1998.

20. Jones C. Software Metrics: Good, Bad, and Missing. In: IEEE Computer. Volume 27 Issue 9; September 1994. pp. 98-100.

21. Kagdi H., Collard M., Maletic J. A Survey and Taxonomy of Approaches for Mining Software Repositories in the Context of Software Evolution. Wiley Inter Science Journal of SWMaintenance & Evolution: Research & Practice. Volume 19 Issue 2; March 2007, pp. 77-131.

22. Kazman R., Bass L., Abowd G., Webb M. SAAM: A Method for Analyzing the Properties of Software Architectures. In: Proceedings of the 16th International Conference on Software Engineering (ICSE). Italy. May 1994. pp. 81-90.

23. Kazman R., Klein M., Barbacci M., Lipson H., Longstaff T., Carriere S. The Architecture Tradeoff Analysis Method. In: Proceedings of the 4th International Conference on Engineering of Complex Computer Systems (ICECCS); 1998. pp. 68-78.

24. Kingston J. Rule-Based Expert Systems and Beyond: An Over-view. Expert Systems, British Association of Accountants Conf.; April 1987.

25. Kradolfer M., Geppert A. Dynamic Workflow Schema Evolution Based on Workflow Type Versioning and Workflow Migration. In: Proc. of the Fourth IECIS International Conference on Cooperative Information Systems (COOPIS). Edinburgh. September 1999. pp. 104-114.

26. Kuipers T., Visser J. Maintainability Index Revisited - Position Paper. In: Special Session on SQM of the 11th CSMR; 2007.

27. Lalanda P. Two Complementary Patterns to Build Multi-Expert Systems. In: Pattern Languages of Programs. Illinois; 1997.

28. Lientz B., Swanson E., Tompkins G. Characteristics of Application Software Maintenance. In: Comm. of ACM. Vol. 21/6; June 1978.

29. McCabe T. A Complexity Measure. In: IEEE Transactions on Software Engineering. Volume 2 Issue 4; December 1976. pp. 308-320.

30. Marco L. Measuring Software Complexity. Enterprise Systems Journal. April 1997.

31. Navasa A., Prez M., Murillo J., Hernndez J.. Aspect Oriented Software Architecture: a Structural Perspective. In: Proceedings of International Conference on Aspect-Oriented Software Development (AOSD); 2002.

32. Oman P., Hagemeister J.. Metrics for Assessing Software System Maintainability. In: Proceedings of ICSM. USA. 1992. pp. 337-344.

33. Parnas D.. Software Aging. In: Proceedings of the 16th International Conference on Software Engineering (ICSE); 1994. pp. 279-287.

34. Perry D.. A. Wolf. Foundations for the Study of Software Architecture. In: ACM SIGSOFTSoftware Engineering Notes. Vol. 17/4; 1992.

35. IEEE Standard 610.12-1990-IEEE Standard Glossary of Software Engineering Terminology. 10.1109/IEEESTD.1990.101064; Sept. 1990.

36. van Gurp J.. Bosch J. Design Erosion: Problems & Causes. Journal of Systems and Software. Volume 61, Issue 2; 2002. pp.105-119.

37. Watson A., McCabe T. Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric. In: CSL, NIST; August 1996.

38. Weyuker E. Evaluating Software Complexity Measures. In: IEEE Transactions on Software Engineering. Volume 14; 1988. pp. 1357-1365.

39. Vora U. Precept: A Design Paradigm to Enhance Evolvability of Object Oriented Systems. Ph.D. Thesis, IIT Bombay. February 2014.