Structure Design Metrics Based On Information Flow Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Nowadays a Component Based System (CBS) is constructed by integrating components from other system or buying them from the shelf. Accordingly, the CBS designers will deal with only a set of requirements specifications which describe the component specification and interface specification to design the intended CBS. Instability of design, further, becomes more severe due to the specifications change requests. Therefore, the evaluation of CBS structural design has to be essentially mitigated by using a proper measurement approaches, otherwise, it may lead to increase maintenance cost, increase testing effort, decrease reusability of components. In this paper, internal design of CBS and the dependency between components are considered as major factors affecting the structure design of CBS. Two sets of metrics are proposed for each factor based on the concept of information flow from CBS designer's point of view.


A CBS is constructed by reusing of a component from other system or buying it from the shelf. Accordingly, the CBS designers will deal with only a set of requirements specifications which describe the component specification and interface specification, to design the intended CBS. However, a proper designing and structuring of the CBSs is an important is an important task; if you fail to design your CBS properly, the result is likely to be system that is hard to maintain or extend, difficult to test and less reliable.

There is a fundamental difference between the external product quality attributes and the internal attributes. An external quality attributes such as maintainability, reliability and testability are more meaningful, but cannot be measured directly early in the development process until some operational version of the software is available. For instance, reliability can be measured in terms of the mean time to failure of the operational product. An internal quality attribute of a product can be measured in terms of the product itself. Instance of internal quality attributes are structural properties such as complexity, size or coupling. Internal quality attributes are measurable during and after of implementation, but they are not meaningful to the users because they describe no externally visible quality of a system. For example, during the operation of a system, the users will not notice whether the components of that system have loose coupling or complex structural or not. However, usually during design time, we measure internal attributes of systems which are available in advance to be able to predict which components of the system are likely to be less reliable, more difficult to test, or require more maintenance than others.

Being able to evaluate the structure of CBS at an early stage of development life cycle leads to effective management the requirement specification and development, which in turns decrease maintenance cost, testing effort, and decrease reusability of components.

Researchers believe, and studies confirm, that structure design must evaluated using measure of several attributes, any of which could indicate that a design entity should be examined carefully[1,2]. This means that a single metrics of structure cannot be sensitive to assessment of structure design of CBS. The objective of this study is to define some simple structural design metrics that could be derived during CBS design or specification to explore potential design and implementation problems. It is not the intent of this study to address whether specific design methods result in a good structural of CBS. Rather, it is objective is to extract structure measure that can be applied to a wide range of CBS structure design to provide a quantitative basis for alternative structures, regard less of how they were produced. We conducted systematic mapping study to investigate existing CBS metrics, but we did not find any of them suitable for such application.

In this paper we adopted a few concepts and definitions from the standard COSMIC measurement method and Hernry Kafura information flow metrics to propose a technique to analyze information flow in CBSs. Based on the measurement of information flow between components two sets of metrics was proposed from CBS designer's point of view. The internal design of CBS is characterized and evaluated using Multidimensional Structure Metric, wherein dependency between components is measured using Coupling and Information Flow metrics.The proposed metrics are useful to characterize and evaluate an entire CBS structure design and individual component structure design quantitatively.

This paper is organized as follows: section 2 proposes a technique to analyze information flow in CBS. Section 3 describes a methodology of mapping the concept of information flow to complete structure flow. Section 4 discusses the definition of the metrics and their description.

A technique to analyze information flow in CBS

Basic Concepts of Information Flow

In this subsection, we introduce some basic concept of information flow according to references [3-6]. In traditional structural programming we say that information flows from X to Y when the values of Y depend on the values of X. The information flow analysis is based on data flow or control flow to infer dependency between variables. Intuitively, we distinguished the flowing types of information flows.

Flow types


Direct explicit flows

Direct assignment of one variable to other.

Y= x+10,

the input values of x are detectable from the output values of y

Direct implicit flows

Information flows via a control variable in a condition or loop.

If (x> 10); then Y= w

Else Y= z

Indirect flows

Information flows via a sequence of statements

y = w + z;

x = y + 10 ,

there are direct flow from variable y to x and variable w and z to y, which lead to indirect ¬‚ow from variable z to x and from w to x

In OOP due to the techniques of object, class and methods and the feature such as encapsulation, inheritance and polymorphism, information flows are not caused by only data flow and control flow, but also by object-flow and message- flow and class-flow. Therefore, information flow exists between statements variables, methods, objects and classes [3]. Practically, the variables are encapsulated inside object in the form of object's attributes, which can be changed only by the methods of the objects. Therefore, the analysis of information flow based on statement variable may not be useful for object oriented system. An information flow caused by message-flow captures the relationships among methods and between the methods and object's attributes. An object-flow refers to the information flow occurring among different objects, between objects and methods and objects and classes. Similarly, class flow captures the relationship between classes, or between classes and other part of the system.

In summary, in object oriented programming information flow analysis could be applied to different levels in the system, i.e. statement level, methods level, class level and object level.

Information Flow metrics.

The information flow metrics proposed by Henery Kafura [7] is the easiest measurement that can be applicable during design of software. It has received considerable attention to measure the total level of information flow between individual modules and the rest of the system.They looked at the UNIX operating system and found a significant relationship between the total level of information flow and the level of maintainability assigned to modules by programmers. Further research by Ince and Shepperd [8] and other authors such as [1,9,10] have conducted to help the practical application of Henry and Kafura's [7] metrics.The empirical results show that, information flow has significant correlation with maintainability, and it can be used effectively to help indentify components with poor maintainability. Ince and Shepperd [8] eliminated the length factor from the original information flow metrics, duplicate flows and redefined the metric as follow:

IF4 = (fan-in * fan-out )2

A technique to analyze information flow in CBS

In CBS, due to the black box nature (or the lack of source code) and the separation of interface specification from its implementation; the analysis of the CBS information flows become quite difficult using traditional information flow technique. Therefore, we proposed a new method named Interface Flow Technique (IFT) to analyze the information flow into a component, out of a component and between interfaces within the CBS. Then based on this technique, we are going to propose a new set of metrics to measure the structural of CBS.

Interface Flow Technique Context:

Information Flow metrics proposed by Henery Kafora[7] can be applied to any functional decomposition of a software system by the same principles. Examples of these include structure charts and Data Flow Diagrams [11]. For example, in a Data Flow Diagram instead of call you have data flows between processes. Given that information flow metrics apply to these forms of functional decomposition they come into play from as early as the high-level design stage. Therefore, the basis of the proposed Information Flow Technique is founded upon the following premise.

Assumption 1: component concept:

A component is a unit identified by decomposing software (system) into its constituent entities. Therefore, the basis of CBS structural design is a functional decomposition which results in hierarchical structural. At each level of decomposition, the CBS designer must decide whether to implement the indicated functionality in the current component or pass some of it to other components by requiring one or more interfaces via dependency relationships between components. The CBS structural specification method used in this study is that of Cheesman and Daniels[12]. A cording to this method the structural of CBS can be specified using interface specification and component specification. An interface is specified by a set of operation specification. Whereas, a component is specified by a set of interfaces offered and required.

Assumption 2: Interface concept:

A component is a modular unit that is replaceable within its environment. Its internals are hidden, but it has one or more well-defined provided interfaces through which its functions can be accessed. A component can also have required interfaces. A required interface defines what functions or services it requires from other components. Internals of component are hidden and inaccessible other than as provided by its abstract interfaces. Although it may be dependent on other elements in terms of interfaces that are required, a component is encapsulated and its dependencies are designed such that it can be treated as independently as possible. This abstraction can be represented in a UML diagram. Fig. 1, shows the relations ship between a component's required interface (Component1) with the provided interface of another component (Component2), to allows one component to provide the services that another component requires.

Fig. 1 the relationship between provided and requred interface

Assumption 3: Component Technologies

In the literature, there are differences in the concept of interfaces between the models of component technologies currently available, and in the way they are defined. However, some definitions focus on details structural characteristics and the others one on generic functional characteristics, what are common across all definitions is:

the nation of required and provided interfaces

the definition of interface as a collection of one or more operations

Provides only the specifications but not the implementation

We assume that the above general principle of an interface definition hold true for any target CBS in order to apply this technique. Particularly, Component technology standards such Sun's Enterprise JavaBeans (EJB), Microsoft's COM+, and the Object Management Group's CORBA Component Model provide good frameworks for defining and deploying distributed, server-side components. The techniques presented here are generally applicable to development using any of the technology standards.

Proposed technique:

In the high level view, we notice that there is very close correspondence between the concepts defined by COSMIC FFP [13]and the concepts of information flow defined by Henery Kafura [7]. The COSMIC measurement method involves applying a set of models, principles, rules and process to the Functional User Requirement of a given piece of software. We adopted a few concepts and definitions from the standard COSMIC method to model information flow in CBSs. The adoption of standard method such as COSMIC [13] and Herey Kafura[7] Information flow is highly recommended, due to its features in terms of applicability over software domains, software life cycles development phases, development methodologies and its accurate and standardized measurement results. [14]. Our propose method was designed in accordance with the COSMIC-FFP standard method and Henry Kafura [7].

COSMIC FFP background

In 1998, a set of experts in software metrics, from several countries around the world, established the Common Software Measurement International Consortium (COSMIC), and proposed a new method named COSMIC FFP (COSMIC full Function Point) to measure functional size of software requirements ( ). COSMIC FFP became the standard ISO/IEC 19761 in 2003 and is also ISO/14143 compliant. For an overview of the COSMIC measurement method, the reader can refer to the COSMIC documentation [15]; for a comprehensive illustration of the concept and definition [13] and reference [16] for measurement practice in the business domain. We mainly based our study on adoption of COSMIC generic Software model's principle.

Generic model of information flow from interface perspective

The separation of interface from implementation is a core principle of component based development. Meaning that, the functionality specified in the interface can be implemented in several programming languages. Therefore, it is important to view interfaces and their specifications isolation of any specific component that may implement or use such interfaces. To explain this view, it suffices to consider the interface of a component to define the component's access point. These access points allow clients of a component, usually components themselves, to access the functions provided by the component (see Fig). Normally, a component could have multiple access points corresponding to different functions. Therefore, this model perspectives focus on what the interface must do to fulfill the client's information needed, without considering how this will be accomplished.

A cording to the model in Fig 2, for any component in CBSs, tow conceptual boundaries are considered: (1) Conceptual Interface Boundary separates the interface from a client. The client might be a user, a required interface or an engineering device. (2) Conceptual Body Boundary separates the interface from its implementation. (see Fig 2).

The information flow is characterized by two directions, Back-end direction and Front-end direction and by distinct types of flow: In-flow, Out-flow, Read flow and Write flow. In the back-end direction, it is assumed that the data structure is used to storage and retrieve the information need by the interface which represented by read flow and write flow. Conceptually, the information flows across the body boundary. In the front-end direction, the interface communicates with client to exchange information by input flow and out flow. The input flow carries information from a client to an interface through the list of in-parameters. The out flow carries information from an interface to a client through the list of out-parameters. Conceptually, the information flows across the interface boundary.(see Fig 2).

Fig 2. Generic model of information flow from interface perspective

The flowing definitions describe precisely the terms and the four types of information flow presented informally above. These four types of flow identify the logical flow of information into a component, out of a component and between interfaces within the CBS. These definitions complies with the principles of information flow definition presented in [18,19].

Definition1: Information flow identifies the set of messages streaming across the conceptual boundary in the logical execution of the interface operations.

Definition 2: Input flow indentifies the information flow provided or passed by a client entity to a provider interface; on condition that the information flow has at least one parameter.

Definition 3: Out flow indentifies the information flow returned by a provider interface to a client entity; on condition that that the information flow returns at least one parameter.

Definition 4: Read flow indentifies the information flow retrieved by a provider interface from its implementation (component body); on condition that the information flow retrieves at least one attribute value from the component body.

Definition 5: Write flow indentifies the information flow updated by a provider interfaces its implementation (component body); on condition that the information flow updates at least one attribute value in the component body.

Definition 6: A client is any entity that uses the interface, although typically, clients are simply could be a required interface, an end user or an engineering device

Mapping phase the concept of interface flow technique to a complete structure flow

An important characteristic of the interface flow technique defined above is that the knowledge essential to build the complete flows structure can be established from a simple analysis of UML requirements specification. UML requirements specifications describe the component specification and interface specification to design the intended CBS. An interface specification consists of its operations specifications. The operation has to specify how the inputs, outputs, and component object state are related, and what the effect of calling the operation has on that relationship. [12]. practically, an operation specifies an individual action that an interface will perform for the client. Each action should show one or more types of information flow (i.e., In-flow, Out flow, Read flow or Write flow), where each type of information flow shows one possible execution flow. Therefore, for each interface we can identify all potential flows from the interface specification.

An Interface Flow Technique (IFT) involves generating a set of relationships indicating the flow of information through in-parameters, out-parameters and information retrieved from the component store. As shown in Table 1, we present a generic model of interface flow and indentified several rules and a set of constrain that characterize IFT in order to provide a precise mapping rule and confirm consist repeatable IFT:

Table1. Interface Flow Model

Interface flow types

Source of information flow

Destination of information flow

Input flow

Client interface

Provider Interface

Out flow

Provider interfaces

Client interface

Read flow

Provider Interface

Component store

Write Flow

Provider interface

Component store

A clear scope should be defined for each interface operation to describe a complete set of flow streaming across the conceptual boundaries.

The information flows within the scope of client interface have no knowledge of information flow within the scope of provider interface, even though the two interfaces exchange messages.

Each In-flow must be activate by a client entity and received by a provider interface.

Each Out-flow must be send by a provider interface and received by a client.

Read flow and Write flow must be retrieve and update component body respectively.

Information flow received by a provider interface either passed to other client (required interface) as Out flow or change the component status as Read flow or Write flow.

The main features of Interface Flow Technique are listed below

Support a variety of software architectures

Interface flow concept introduced here can support a variety of architectures from simple standalone application to large distributed software based on OSI 7 layers or J2EE n-tiers. Therefore, almost any kind of CBS structure can be modeled and evaluated.

Support all stages of the software life cycle

Information flow analysis concept can be carried out as early in the requirements specifications or as late in the life cycle as necessary.

Flexibility and standardization

Interface flow concept is proposed in compliance with the standard COSMIC-FFP, ISO/IEC.

Measurement unit

An elementary unit of the CBS-information flow defined by us is a base flow types (input flow, out flow, read flow and write flow) as correspondence to the COSMIC method data movement types (entry, exit, read and write).

Definition of CBS Structural Design Metrics

Many experts in software measurement domain such as [2,7,10{{64 Fenton,Norman 1997; }}] have discussed that a valid structural design metrics should reflect the capability of characterizing two different levels of design:

The relationship among components (i.e., modules/ procedures). Sometimes called as structure complexity measure or inter-modular measure.

The internal design of the components (i.e., modules/ procedures). Sometimes called as intra-modular measure ( or design of component size)

Henry and Kafura [7] did this by multiplying the information flow of a module by its size (or length in lines of code (LOC)). Shepperd [2] claimed that the structural complexity could be decreased by adopting an architectural containing single component. He clearly stated the problem of concentrating only on the manner in which components are linked ignoring the size of components. On the other hand, Card and Argesti [19] have proposed a measure to the architectural design complexity based on two separate metrics. They measured the complexity contained within module based on module size; and the structural complexity based on the relationship among the modules.

However, we are not going to combine these tow attributes in one metric, because it contradicts measurements theory which demands the characterization of specific attributes, but we want to Investigate the attributes of design structure to determine how they affect the outcome we seek [26].

Moreover, observation of multidimensional observe them in conjunction with each other to help designer decision making

1- The internal design of the components

We use the fowling metrics to characterize the affect of the internal design attributes on the structural design of CBS:

Number of Component (NoC): defined as the count of all components in a CBS those appear in the high level of design.

Number of interfaces (NoI): defined as the count of all components interfaces in a CBS.

Number of operations (NoO): defined as the total number of operation defined in all interfaces in a CBS system.

Total Level of Information Flows (TLIF): defined as the total level of system flow

TLIF (CBS) = low

Whereas c = number of component in a CBS

There is nothing interest about the metrics above, but let us have a look at the below derived ratio metrics:

Component Structural Metric (CSM) = NoI / NoC

This ratio indicates if components tend to be coarse grained or fine grained.

Interface Structural Metric = NoO / NoI

This ratio reveals the quality of interfaces design, because it exposes how operations are distributed among interfaces. Very high values might indicate a need for extra interfaces, or an excessive stuffing of operation into interfaces.

Operation Structural Metric (OSM) = TLIF / NoO

This ratio indicates how well the information flow distributed among operations. Very high number indicate the CBS operations are quite complex.

Shepperd [2] and Lanza {{88 Lanza,Michele 2006; }}have shown that the multidimensional approach is more effective at identifying problem components than any method based on a single metrics. Therefore, the metrics are placed one per line in a bottom-up manner, from a measure of lowest unit (i.e., Total Level of Information Flows (TLIF)) up to a measure counting the number of components. So that the CBS developer can see and interpret in shot a comprehensive characterization of an entire CBS.

Multidimensional Structural Metrics for Internal Design of CBS

The proposed multidimensional structural metrics for internal design of CBS has four important measurement characteristics:

Comparability: The ratio values allow for easy comparison of one component/or CBS with other component/ or CBS, independent of size. The comparability of measurements exists at varying levels of granularity or decomposition.

Independence: The CSM, ISM and OSM metrics are independent of each other. This gives each metrics value a distinct characteristics of a specific aspect of structure.

Accuracy and easy of interpretation: The model allows easy interpretation of multidimensional observable attributes of a system entity to indentify abnormality of their distributions among system components

Multi use: those metrics also can be used to characterize the internal design individual components by the same logic and principles.

Impact of complex internal design of components on quality of the system

Decrease reusability: High complexity internal design can lead to decreased understandability of components which in turn reduce reusability. Moreover, CBS developers need to spend more effort on impact analysis and risk assessment of the components

Increase testing effort: component with high complex internal design is more difficult to test and may need extra effort to examine all received interfaces or events.

Increase maintainability: component with high complex internal design might be difficult to understand and it's subjective to potential error-proneness.

2- The relationship among components (the structure design of components)

We use the fowling metrics to characterize the affect of dependency attributes on the structural design of CBS:

Information flow measures the degree of connectivity between interfaces of a CBS. It concern with the reliance relationships among components.

1- Coupling between components

Through our survey of the fundamental concept of coupling literature [1,7,20-25], We found that the coupling attributes has been defined, measured and interpreted in various ways. Xia [22] studied this ambiguity of coupling concept and redefined it relaying on its essence. We adopted his definition here. "Component coupling of m is the impact-dependence of components to m". The impact-dependence of x to y means that when y is modified, x will receive an impact. For example, When changing component X1 in Fig , we only need to consider how component X2 will be affected. Component X2 returns F1 and F2 to component X1. F1 and F2 are out-flowing of component X2 and input-flow of component X1 that will influence component X1 when component X2 is changed. But when X1 is modified, F1 and F2 have no impact on X2. Therefore, the right definition should consider only out flow of X1 for its coupling. Another important source which could influence the change in X1 is the number of distinct component receiving the flows. For example, component that depends on one component is not the same as component that depend on three components by the same number of out flow.

Fig 3. The impact of modification

Accordingly we identified coupling metrics definition as

Interface Coupling (IC) = N ()

Where as

N = number of distinct interfaces receive the out flow.

Component Coupling (Coupling) = N ( )


i = the number of interfaces in a component

N = the number of distinct components receive the out flow.

CBS coupling (CBScoupling ) =

Where as

C= number of component in the system.


A component that has large number of outflow with many destinations has high coupling degree with another having fewer outflows and single destination.

2- Component Information Flow Metrics

We adopted the definition of Ince and Shepperd [8] metric which is considered more sophisticated metrics than the original information flow proposed by Hernery Kafora {{65 Henry,S. 1981; }}

For a component "A" let:

Fan-in =

Fan-out = Outflow+ Write flow

Where as i = number of interfaces in a component


Component Information Flow (CIF) = ( Fan-in + Fan-out)2

The original Henery Kafur [7] metric uses (fan-in * fan-out) to represent the total possible number of flows paths from source to destination. In order to follow property 2 in weyker properties [28]; our metrics adopt plus instead of time for the computation of component complexity.

Impact on quality

Coupling in CBS refers to impact-dependence between components, which focus on how strongly the interfaces are interacting to each others. An interface interact with another interface if and only if they share on or more operation. Coupling connections cause dependencies between components, which, in turn, have an impact on system qualities such as

Increase maintainability: a change of a component may require modifications to its connected component.

Increase testability: an error in one component may cause a failure in a completely different, connected component.

Decrease understandability: component with high coupling operate in large context, developers need to know all services the element relies on, and how to use them.

Decreased reusability: To reuse a component with high coupling in a new context, all the required services must also be made available in the new context.

Thus, a common design principle is to minimize coupling. Coupling metrics are appropriate to identify potential design with high error density. Therefore, coupling measures greatly help to show parts of a design that contain a large number of errors.

[1] Pickard MM, Carter BD, A field study of the relationship of information flow and maintainability of COBOL programs, Information and Software Technology, 37 (1995), PP 195-202.

[2] Shepperd M, Measurement of structure and size of software designs, Information and Software Technology, 34 (1992), PP 756-62.

[3] Li B, A technique to analyze information-flow in object-oriented programs, Information and Software Technology, 45(6) (2003), PP 305-14.

[4] Chandra D, Franz M, Fine-Grained Information Flow Analysis and Enforcement in a Java Virtual Machine, in Computer Security Applications Conference, 2007. ACSAC 2007. Twenty-Third Annual (2007).

[5] Genaim S, Spoto F, Information flow analysis for java bytecode, in Verification, Model Checking, and Abstract Interpretation, Springer (2005).

[6] Li B, Analyzing information-flow in java program based on slicing technique, ACM SIGSOFT Software Engineering Notes, 27(5) (2002), PP 98-103.

[7] Henry S, Kafura D, Software Structure Metrics Based on Information Flow, IEEE Trans. Softw. Eng., 7(5) (1981), PP 510-8.

[8] Ince D,C., Shepperd M,J., An empirical and theoretical analysis of infromation flow-based system design metrics, in 2nd European Software Engineering Conf, Springer Verlag (1989).

[9] Kitchenham BA, Pickard LM, Linkman SJ, An evaluation of some design metrics, Software Engineering Journal, Software Engineering Journal, 5(1) (1990), PP 50-8.

[10] Kitchenham BA, Linkman SJ, Design metrics in practice, Information and Software Technology, 32 (1990), PP 304-10.

[11] Goodman P, Rothstein Associates, (2004).

[12] Cheesman J, Daniels J, UML Components: A Simple process for Specifying Compoent Based Software, Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, 2001,

[13] Abran A, Desharnais J,M., Oligny S et al., The COSMIC Functional Size Measurement Method: Measurement manual, v 3.0.1, (May 2009)

[14] Berardi E, Santillo L, COSMIC-based Project Management in Agile Software Develop-ment and Mapping onto related CMMI-DEV Process Areas,

[15] Abran A, Desharnais J,M., Oligny S et al., The COSMIC Functional Size Measurement Method: Measurement manual, Documentation Overview and Glossary of Terms V.3.0, (May 2009)

[16] Abran A, Desharnais J,M., Oligny S et al., The COSMIC Functional Size Measurement Method, Guideline for sizing business applications software, v 3.0, (May 2008)

[17] Fleisch W, Applying use cases for the requirements validation of component-based real-time software, in Object-Oriented Real-Time Distributed Computing, 1999. (ISORC '99) Proceedings. 2nd IEEE International Symposium on (1999).

[18] Henry S, Kafura D, Software Structure Metrics Based on Information Flow, Software Engineering, IEEE Transactions on, SE-7 (1981), PP 510-8.

[19] Card DN, Agresti WW, Measuring software design complexity, Journal of Systems and Software, 8 (1988), PP 185-97.

[20] Etzkorn LH, Gholston SE, Fortune JL et al., A comparison of cohesion metrics for object-oriented systems, Information and Software Technology, 46 (2004), PP 677-87.

[21] Gui G, Scott PD, Ranking reusability of software components using coupling metrics, Journal of Systems and Software, 80 (2007), PP 1450-9.

[22] Xia F, On the concept of coupling, its modeling and measurement, Journal of Systems and Software, 50 (2000) PP 75-84.

[23] Gui G, Scott PD, Measuring Software Component Reusability by Coupling and Cohesion Metrics, Journal of Computers, 4(9) (2009), PP 797-805.

[24] Khlif W, Zaaboub N, Ben-Abdallah H, Coupling metrics for business process modeling, WSEAS Transactions on Computers, 9(1) (2010), PP 31-41.

[25] Allen EB, Khoshgoftaar TM, Chen Y, Measuring coupling and cohesion of software modules: an information-theory approach, in metrics, Published by the IEEE Computer Society (2001).

[26] Fenton N, Pfleeger SL, Software Metrics: A Rigorous & Practical approach,2nd, International Thomson Publishing, Boston, (1997).

[27] Gencel Ç, Buglione L, Demirors O, Efe P, A Case Study on the Evaluation of COSMIC-FFP and Use Case Points, Proceedings of SMEF, 2006 (2006),

[28] Weyuker EJ, Evaluating Software Complexity Measures, IEEE Trans. Softw. Eng., 14(9) (1988), PP 1357-65.