As software is designed, there are well-established principles applied by software developers. These principles guide the development effort with the goal of creating quality software that is understandable, testable, and measurable. Three of the most popular design principles are encapsulation, data hiding, and separation of concerns. In Meilir Page-Jones’ book, encapsulation is defined as [10]:

The grouping of related ideas into one unit, which can thereafter be referred to by a single name.

In programming languages, encapsulation refers to one of two related but distinct notions, and sometimes to the combination thereof. First, it is a language construct that facilitates the bundling of data with the modules (or other functions) operating on that data. Secondly, it is language mechanism for restricting access to some of the object’s components.

Sometimes, encapsulation and data hiding are used interchangeably. However, data (information) hiding is a software design principle originally introduced by David L. Parnas. In his paper written almost 40 years ago, Parnas used data hiding to discuss the criteria leading to good modularity in structured programming [11]:

Every module in the [...] decomposition is characterized by its knowledge of a design decision which it hides from all others. Its interface or definition was chosen to reveal as little as possible about its inner workings.

Specifically, in object-oriented programming, data hiding shields internal object details (data members). Data hiding ensures exclusive data access to class members and protects object integrity by preventing unintended or intended changes. Decision logic that does not use public global and parameter data indicates strong data hiding (since other objects cannot access this data) and decision logic that uses public global and parameter data indicates weak data hiding (since other objects can access this data).

The term, separation of concerns, was first used by Edsger W. Dijkstra in his 1974 paper “On the Role of Scientific Thought”. Dijkstra wrote that separation of concerns [12]:

Even if not perfectly possible is yet the only available technique for effective ordering of one’s thoughts.

Separation of concerns has grown into a software design characteristic for separating a program into objects such that each object addresses a separate concern. A concern is a logic or a set of information that affects the code of a program. Decision logic that connects modules and uses public global and parameter data indicates weak separation of concerns, since this logic and data is influencing the operation of one or more other objects.

Encapsulation, data hiding, and separation of concerns are design principles that are, sometimes, misunderstood and, at other times, misapplied. Figure 1 illustrates an important view of the overlap and uniqueness among these design principles. In this view, program and data logic elements are essential factors in determining encapsulation, data hiding, and separation of concerns. The intersection among encapsulation, data hiding, and separation of concerns represents principle overlap. High use of local data drives encapsulation; low use of global data promotes data hiding; low inter-module program logic establishes separation of concerns. Yet, there is interaction among these principles. When good encapsulation is achieved, software exhibits good data hiding or a low level of global data usage. By contrast, poor encapsulation results in poor data hiding or higher use of global data. A similar relationship for data hiding exists with encapsulation. If good data hiding is achieved, software exhibits good encapsulation or a high level of local data usage. In inverse, as poor data hiding is exhibited, it is accompanied by lower use of local data. When high encapsulation is achieved, software exhibits a high separation of concerns since inter-module influence is low from local data and program logic. When lower encapsulation is

realized, it is accompanied by lower separation of concerns as less local data usage will promote more global data and program control logic that reaches into other modules. Finally, when the intersection of data hiding and separation of concerns is considered, software exhibiting high data hiding will result in high separation of concerns. When lower data hiding is realized, it is accompanied by lower separation of concerns as more global data usage will promote more data and program control logic that reach into other modules.

There are pragmatic implications associated with the relationship among encapsulation, data hiding, and separation of concerns. Note the 7 regions in Figure 2 and consider region 1. This region which is the intersection of all three design principles represents good encapsulation, good data hiding and good separation of concerns. What is the software engineering implication of the combined states of these three design principles? As described in Table 2, enhancing, modifying, fixing, and reusing success is best when encapsulation, data hiding, and separation of concerns are all good. As software changes are implemented, design activities should not try to introduce global references or call additional modules to sustain good design principles.

In Table 2, each region represents potential effects on software when alternative combinations of good or poor encapsulation, data hiding, and separation of

concerns exist. Let’s examine region 2, this region represents a design with good encapsulation and poor data hiding and separation of concerns. Since this design has good encapsulation, global data and interdependent control logic among modules produce poor data hiding and separation of concerns. When work is conducted on this design type, modifications should pinpoint the risk of global data changes and the affected modules should be closely monitored for ripple effects. Consider another area, region 3. This region represents a design with good data hiding and poor encapsulation and separation of concerns. When implementing software changes to this class of software, it is important to check the effects on called modules and to ensure that changes are not referencing global data. In Table 2, additional scenarios are described for combinations of encapsulation, data hiding and separation of concerns interaction and potential actions taken when working with various combinations of subjective design qualities.

The proof in the pudding is the usefulness of these design principles in doing what must be done with software modules—constructing, enhancing, modifying, reusing, understanding, and testing. When a module is modified or reused, design principles provide a sensitivity than can help avoid errors and increase productivity. The above Venn diagram has seven distinct regions delineating unique advice and reuse sensitivity based on their encapsulation, data hiding, and separation of concerns qualities. Table 2 addresses issues unique and identifiable by the underlying three design principles. The Venn diagram and table can be useful desktop guides making software developers aware of the sensitivities and issues that should be recognized when dealing with or modifying software. Likewise, these tactics could enhance a modification walkthrough or review to insure the pertinent and unique issues are emphasized and focused upon. It goes without saying that the proposed modifications should only enhance and improve the design so as to not degrade it. The explicit design principles, above Venn diagram, and table can be desktop guides assisting this effort. Even more effective would be quantitative metrics for these design principles. Since the establishment of the values of good and poor is completely subjective, this approach would be strengthened when an objective quantitative measure for encapsulation, data hiding, and separation of concerns is determined. The next sections will develop such quantitative metrics which will ground these concepts and make them operational.

In 1976, McCabe introduced a number of software metrics. Cyclomatic complexity, v, is a measure of the number of paths through a program [13]. The number of paths can be infinite if the program has a backward branch, and cyclomatic measure is built on the number of basis paths through the program. Cyclomatic complexity is derived from a flowgraph and mathematically computed using graph theory. Cyclomatic complexity is a measurement of the logical complexity of a module and the minimum effort necessary to qualify a module. For the remainder of this research, a module and a method are considered to be synonymous and the word, module, is used to represent both software code types. v is the number of linearly independent paths in a module and, consequently, the minimum number of paths that one should test using McCabe Structured Testing Methodology. There are three mathematical ways to calculate cyclomatic complexity; a simple way is determining the number of decision predicates. Then, cyclomatic complexity is calculated as:

1. v(G) = number of predicates + 1

By examining the decision statements, the design predicates can be counted resulting in the cyclomatic complexity metric. It is important to recognize that many decision statements have compound conditions. An example is a compound IF statement [13]:

If A = B and C = D and E = F then

In this example, v(G) is equal to 4 (three IF design predicates + 1). Cyclomatic complexity recognizes that compound predicates increase program logic complexity and integrates complex decision constructs in order to calculate v(G). An upper limit of 10 for a testable software unit is proposed because McCabe’s research found software with v(G) > 10 was less manageable, more difficult to test, and less reliable.

In McCabe’s original article [13], essential complexity (ev) was also defined. Essential complexity is a measurement of the degree to which a module G contains unstructured constructs.

2. ev = the cyclomatic complexity of a reduced flowgraph, v(G)

Reduction is completed by logically removing all structured constructs. Essential complexity can range from 1 to v. When ev is low, a module is well-structured and can easily be decomposed into multiple modules. In contrast, when ev is high, a module is not well-structured and cannot be easily be decomposed into multiple modules [13]. McCabe methodology utilizes graphical representation of software (see Figure 3). A flowgraph is an architectural diagram of a software module logic, and a flowgraph is constructed from written code. It is a visualization of module decision logic. A Battlemap is an architectural diagram of a software design. A Battlemap is constructed from written code and is a hierarchical visualization of software modules or classes and methods. Both of these code visualizations are tools used to analyze software design and testing requirements.

In 1989, McCabe and Butler extended cyclomatic complexity-based metrics into design principles. Module design complexity, iv, is a measurement of the decision structure of a module, G, which controls the invocation of G’s immediate subordinate modules.

3. iv = the cyclomatic complexity of a reduced flowgraph, v(G)

Reduction is completed by logically removing all decision constructs that do not significantly impact calls and returns from subordinate routines. It is a quantification of the testing effort of a module as it calls its subordinates [14]. Module design complexity is mathematically computed using a reduction technique on a flowgraph. The technique eliminates decision predicates that do not significantly impact calls to subordinates. Module design complexity varies from 1 to v. When iv is low (iv = 1), a module does not conditionally call subordinates. In contrast, when iv is high (iv = 15), a module executes many conditionally calls to subordinates. In order to measure the proportion of logic that is associated with calls, ivdensity (iv/v) was defined. High ivdensity is a design characteristic that indicates high use of calls in module logic; low ivdensity indicates low use of calls in module logic (ivdensity ranges between 0 and 1) [14]. Two other metrics, design complexity and integration complexity, were introduced. Design complexity, S₀, is a measurement of the decision structure which controls the invocation of modules within the design. It is a quantification of the testing effort of the calls in the design, starting with the top or root module, trickling down through subordinates and exiting through the top. Design complexity is calculated as ∑iv. The third metric, integration complexity, is a measurement of the integration tests that qualify the design tree. Integration complexity, S₁, is a quantification of a basis set of integration tests and measures the minimum integration testing effort of a design. Each S₁ test validates the integration of several modules and is known as a subtree of the whole design tree [14].

After introducing these three metrics in 1989, McCabe and Butler developed two variations of S₀ and S₁ for testing of object-oriented code. These metrics took advantage of object oriented design efficiencies to reduce the number of design tests. Object design complexity (OS₀) is a measurement of the decision structure which controls the invocation of modules within an object-oriented design. It is a quantification of the testing effort of all calls in the design, starting with the top module, trickling down through subordinates and exiting through the top. Object integration complexity (OS₁) is a measurement of the integration tests that qualifies the design tree for an object-oriented program including any unresolved module references. A subtree is a sequence of calls from a module to descendant modules and of returns from them. Just as integration complexity design defines the number of test subtrees in the required basis set for that design, OS₁ defines the number of linearly independent design subtrees in a basis set for an object-oriented design [15].

McCabe metrics are not limited to measurement of logic and decision structure. The data domain includes two classes of metrics [14].

4. gdv = the cyclomatic complexity of a reduced flowgraph, v(G)

5. sdv = the cyclomatic complexity of a reduced flowgraph, v(G)

Reduction is completed by logically removing all decision constructs that do not significantly the use of global or selected data [14]. Global data complexity (gdv) is a measurement of the decision structure of a module which controls the use of global and parameter data. gdv is the cyclomatic complexity after the decision predicates are logically reduced that do not impact data defined either outside the module or passed as formal parameters. Second, specified data complexity is a flexible, configurable measurement of data targeted by a software developer. Specified data complexity (sdv) is a measurement of the decision structure of a module which controls the use of selected local, global, and parameter data. sdv is the cyclomatic complexity after the decision predicates are logically reduced that do not impact target (selected) local, global and parameter data. Specified data complexity can be used in many ways. For the purposed of this research, it is used to quantify data metrics for measuring encapsulation, data hiding, and separation of concerns [16].

Six specified data metrics are used in building design coefficients for encapsulation, data hiding, and separation of concern. Below is the definition of these six metrics.

· local data complexity (ldv): specified data complexity of local (private) data; 0 ≤ ldv ≤ v;

· ldvdensity (ldv/v): high ldvdensity is a design characteristic that indicates high use of local (private) data in module logic; low ldvdensity indicates low use of local (private) data in module logic; 0 ≤ ldvdensity ≤ 1;

· public global data complexity (pgdv): specified data complexity of global (public) data excluding parameter data; 0 ≤ pgdv ≤ v;

· pgdvdensity (pgdv/v): high pgdvdensity is a design characteristic that indicates high use of global (public) data in module logic; low pgdvdensity indicates low use of global (public) data in module logic; 0 ≤ pgdvdensity ≤ 1;

· parameter data complexity (pdv): specified data complexity of parameters (passed arguments) excluding public global data; 0 ≤ pdv ≤ v;

· pdvdensity (pdv/v): high pdvdensity is a design characteristic that indicates high use of parameters in module logic; low pdvdensityindicates low use of parameters in module logic; 0 ≤ pdvdensity ≤ 1.

These specified data metrics and their density metrics form the foundation for design coefficients.

The encapsulation coefficient is a measurement of the quality of data bundling within a module operating of that data; a measurement of the decision logic that uses (refers to) local data and global data. The coefficient measures the relative magnitude of local data manipulation to the magnitude of combined local and global manipulation. Decision logic that uses local data indicates high encapsulation (since the data is exclusively bundled with the module) and decision logic that uses global data indicates low encapsulation (since the data is not exclusively bundled with the module).

Module encapsulation coefficient:

C e n c a p = f ( cyclomatic   complexity ,   local   complexity ,                               publiccomplexity ,   public   global   data   complexity )

C e n c a p = f ( v , l d v , p g d v )

(rationale: ldv is a measurement of local data manipulation within a module; high ldv indicates that module logic is bundled using local data)

C e n c a p 1 = ( l d v d e n s i t y − p g d v d e n s i t y l d v d e n s i t y + p g d v d e n s i t y ) = ( l d v v − p g d v v ) ( l d v v + p g d v v ) = ( l d v − p g d v l d v + p g d v )

where ldv and pgdv not = 0 and 0 ≤ C_encap¹ < |1|; −1 indicates low encapsulation and 1 indicates high encapsulation.

So that encapsulation, data hiding, and separation of concerns behave quantitatively with common magnitude, encapsulation is scaled to be:

C e n c a p = ( C e n c a p 1 + 1 ) / 2

where 0 ≤ C_encap ≤ 1; 0 indicates low encapsulation and 1 indicates high encapsulation.

Where ldv and pgdv = 0, C_encap = 0.

A peculiar and sometimes pathological case occurs when both ldv and pgdv are zero. This strange case implies that the algorithm references no data—no local data nor any global data. Even though the denominator is zero in the above formula, the convention of defining the metric value to be zero is used. This convention gives an encapsulation coefficient indicating the lowest (worse) value for encapsulating data. Over and above this mathematical anomaly, these bizarre modules deserve careful inspection. Often they are doing something strange that affects data below the syntactic level of the language being used. For example, in a real-time system, a module referencing no data may just be looping in order to waste some time so it can properly synchronize. It appears that it is using no data but that is not the case. It is affecting the system clock which is data below the syntactic level of language. Change the units in the system clock or get a faster processor and the low encapsulation in this logical construct would cause errors. Another case that has been witnessed is dividing by zero in Ada which triggers an exception recovery procedure. Although there is no syntactic data being used, there is compiler generated data keeping track of these anomalies—so, in fact, this is low encapsulation with risky properties. This same argument applies to data hiding (defined next) when ldv, pgdv and pdv = 0. When modules use no data, they are exhibiting the lowest encapsulation and data hiding characteristics.

The data hiding coefficient is a module measurement of the quality of hiding a module’s internal data members and limiting data access from external objects.

Module data hiding coefficient:

C d h = f ( cyclomatic   complexity ,   local   datacomplexity ,                         public   global   data   complexity , parameterdatacomplexity )

C d h = f ( v , l d v , p g d v , p d v )

(rationale: pgdv and pdv are measurements of public global and parameter data manipulation within a module; low pgdv and pdv indicate that module logic is hiding data from other modules)

C d h = 1 − ( ( p g d v d e n d i s y + p d v d e n s i t y ) / ( l d v d e n s i t y + p g d v d e n s i t y + p d v d e n s i t y ) )

C d h = 1 − ( ( ( p g d v / v ) + ( p d v / v ) ) / ( ( l d v / v ) + ( p g d v / v ) + ( p d v / v ) ) )

C d h = 1 − ( ( p g d v + p d v ) / ( l d v + p g d v + p d v ) )

where ldv and pgdv and pdv not = 0 and 0 ≤ C_dh≤ 1; 0 indicates low data hiding and 1 indicates high data hiding.

Where ldv and pgdv and pdv = 0, C_dh = 0.

Module separation of concerns coefficient: module separation of concerns (soc) is a design characteristic for partitioning a design into modules such that each module addresses a separate internal function concern, not relying on other modules.

C s o c = f ( cyclomatic   complexity ,   module   design   complexity ,                           global   data   complexity , parameter   data   complexity )

C s o c = f ( v , i v , p g d v , p d v )

(rationale: iv, pgdv and pdv are measurements of module logic influencing one or more other modules; low iv, pgdv and pdv indicate that module logic is not influencing other module logic or data manipulation)

C s o c = ( ( 1 − i v d e n s i t y ) + ( 1 − p g d v d e n s i t y ) + ( 1 − p d v d e n s i t y ) ) / 3 = ( ( 1 − ( i v / v ) ) + ( 1 − ( p g d v / v ) ) + ( 1 − ( p d b / v ) ) ) / 3 = ( 3 − ( ( i v + p g d v + p d v ) / v ) ) / 3 = 1 − ( ( i v + p g d v + p d v ) / 3 v )

where 0 ≤ C_soc ≤ 1; 0 indicates low separation of concerns and 1 indicates high separation of concerns.

In Table 3, the design coefficients are calculated for a set of software modules, presented as module pairs A and B, C and D, and E and F. The v for these modules is 10. Modules A and B demonstrate the effect of local and public global data complexity in determining the encapsulation coefficient. In these modules, module design and parameter data complexity are constant. In module A when local data complexity is high (10) and public global data complexity is low (1), the encapsulation coefficient is high (0.909) indicating the module exhibits high encapsulation. In contrast in module B, when local data complexity is low (1) and public global data complexity is high (10), the encapsulation coefficient is low (0.091). In contrasting these two modules, module A uses large quantities of local data and low quantities of global data which are good encapsulation qualities.

Module B uses low quantities of local data and high quantities of global data which are poor encapsulation qualities. The encapsulation coefficient behaves mathematically consistent with these intuitive qualities. Values between these extremes are determined by the actual values for local data and public data complexities for a given module.

In Table 3, modules C and D demonstrate the effects of local data, public global data, and parameter data complexities in calculating the data hiding coefficient. In the data hiding coefficient example, module design complexity is a constant. In module C, local data complexity is high (10), public global data complexity is low (0), and parameter data complexity is low (0). This module’s data hiding coefficient is 1.000. In module D, the local data complexity is low (0) and the public global and parameter data complexities are high, 10 and 10, respectively. Module D’s data hiding coefficient is 0.000. When contrasting these two modules, module C uses large quantities of local data and low quantities of both global and parameter data which are good data hiding qualities. Module D uses low quantities of local data and high quantities of global and parameter data which are poor data hiding qualities. The data hiding coefficient behaves mathematically consistent with these intuitive qualities. As with the encapsulation coefficient, values between these extremes are determined by the actual values for local data and public global and parameter data complexities for a given module.

The final example illustrated in Table 3 is the separation of concerns coefficient. In this example, modules E and F contrast the effects of module design, public global data, and parameter complexities. In this example, local data complexity is constant. In module E, module design, public global data, and parameter complexities are 0, 0, and 0, respectively. These low metrics indicate that module E has no interaction with other modules, either through control logic or data sharing. Its coefficient is 1.000. In contrast, module F’s design, public global data, and parameter complexities are 10, 10, and 10, respectively. Module F has high levels of interaction with other modules through control logic and data sharing. Its separation of concerns coefficient is 0.000. Again, as with the encapsulation and data hiding coefficients, values between these extremes are determined by the actual values for local data and public global and parameter data complexities for a given module.

There is one other important illustration of the encapsulation, data hiding, and separation of concerns coefficients in Table 3. There are two modules, G and H, whose v = 20. By traditional McCabe measurement, these modules have twice as much decision logic as the previous 6 modules. This code is considered “too complexity” and is a candidate for decomposition. Compare the encapsulation coefficients for modules G and H with those for modules A and B. Modules A and B have encapsulation coefficients of 0.909 (high) and 0.091 (low). Modules G and H encapsulation coefficients are 0.952 (high) and 0.048 (low). Consider the higher encapsulation coefficients of modules A and G. Module G’s encapsulation coefficient is higher than module A’s, indicating it is better encapsulated. Even though module G’s cyclomatic complexity is considered to be poorer than module A’s, its encapsulation coefficient is better. This outcome reflects the fact that the module G makes good use of proportionally more local data and proportionally less public global data. The encapsulation design of module G is better and more desirable. When comparing modules H and B, module H has a lower encapsulation coefficient, 0.048 and 0.091, respectively. Module H’s encapsulation coefficient is lower than module B’s because it makes use of, proportionally, less local data and more public global than module B.