Briand, L.C., S. Morasca and V.R. Basili, 1996. Property-based software engineering measurement. IEEE Trans. Softw. Eng., 22: 68-86.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....area. Our thesis is that a robust component architecture should consist of highly cohesive and lowly coupled components: the cohesion and coupling of components are measured with respect to the relatedness of elements in each component and the relatedness between components, respectively[1]. Thus, in measuring the robustness of architecture, the notions of elements in components and their relatedness are essential. The understanding of these notions allows us to design a robust architecture by grouping elements into a components according to their relatedness. Our observation ....

L. Briand, S. Morasca, and V. Basili. Property-based software engineering measurement. Transaction on Software Engineering, Jan. 1996.

....are consistent with values predicted by models involving the attribute (e.g. the measured distance from an origin to a point is the square root of the sum of the x and y coordinate values) Real validation is only theoretical, empirical methods can only corroborate the validity of a measure. Briand et al. 96] propose a mathematical framework for the definition of software attributes like complexity, coupling, cohesion, length and size. For each attribute they give a number of properties that a measure for that attribute should satisfy. Therefore they follow the axiomatic approach initiated by ....

L. Briand, S. Morasca, V. Basili, Property-Based Software Engineering Measurement, IEEE Trans. Software Eng. 22(1), 1996, pp. 68-85.

....models, but the descriptions are informal and there seems to be no support for rigorous application of refinement and abstraction techniques. One goal of our research is to develop formal notions of refinement and abstraction where possible. 6.2. Software Measurement and Evaluation Briand et al., [13] identify five major quantifiable software design concepts: size, length, complexity, cohesion, and coupling. Size can be measured in terms of counts of entities, while length implies some kind of distance between entities. Complexity depends on the relationships between entities and is not a ....

L. Briand, S. Morasca, and V. Basili. Property-based software engineering measurement. IEEE Trans. Software Engineering, 22(1):68--85, Jan 1996.

....scales. The discussion of scale types is important for statistical operations. Because many empirical and numerical conditions are not covered by a certain scale type, the consideration of the empirical and numerical conditions is necessary and very important, too. 2) Property based approaches [29,30,31]. Aim to formalize the empirical properties that a generic attribute of software or a system (e.g. the complexity or Data model metrics 5 size) must satisfy in order for it to be used in the analysis of any measurement proposed for that attribute. 2.3. Empirical validation As in other aspects of ....

....Another source of redundancy in an ERD is the existence of redundant relationships. We define the Redundant Relationship metric as the number of relationships that are redundant in the ERD. These metrics were theoretically validated following the property based approach proposed by Briand et al. [30] in [39] and following the measurement theory based framework proposed by Zuse [26] in [15] Genero et al. have carried out empirical validation of these metrics by means: A case study. In [40] it was demonstrated by means of a case study that some of the proposed metrics are heavily ....

L. Briand, S. Morasca and V. Basili, Property-Based Software Engineering Measurement, IEEE Transactions on Software Engineering, 22 (6), 1996, 68-86.

....concatenated entities must be preserved by the mapping to the formal relationship. Note that addition is assumed to be the concatenation operator. Criticism of the Extensive Structure Recent work has questioned the applicability of the extensive structure to object oriented measures [3] 4] [5], 29] and [30] Particularly important is the question: must the measurement of an entity formed by the concatenation of two modules equal the sum of the measurements of the independent modules before concatenation, i.e. let b1, b2, be the formal measures associated with a1, a2; is it necessary ....

Briand, Lionel C., Sandro Morasca, and Victor R. Basili, "Property-Based Software Engineering Measurement", IEEE Transactions on Software Engineering, Vol. 22, No. 1, 1996.

....data . How shall I deal with tools, methods and processes in order to make the measurement automatic This set of questions makes us wish to build a meta system that facilitates the configuration of several measurement programs. 2 Software Measurement Problems Among many others [BSH86] BMB96] FPG94] have called the attention to the lack of experimental evidence to confirm the benefit of the new methods, techniques, tools and processes, which are proposed by various research and development groups, and by organizations that commercialize tools or training. It is thus necessary not ....

.... 96] BD97] ELL 92] HRH 97] HS90] Kok95] OYK96] Rom90] Roy97] TMT 92] which describe the undertaken experiments and the benefits that have been achieved when measurement was applied to the artifacts that were produced during the development process. KPF95] and [BMB96] mention the need for the creation of a software metrics validation framework, i.e. a considerable amount of the proposed metrics contributes little to the real improvement of software development products and processes. Moreover, all of these measurements induce costs. It is thus necessary to be ....

[Article contains additional citation context not shown here]

L.Briand, S. Morasca, and V.R. Basili. Property-Based Software Engineering Measurement. IEEE Transactions on Software Engineering, 22(1), 1996.

....the metric to be useful, there must be sufficient variation in the measurement of different entities to distinguish among them. Recent work has questioned the applicability of the extensive structure (used to validate metrics on the interval and ratio scales) to object oriented measures [3] 4] [5] [25] In particular, it has been argued that the set theory union structure test can be used. The set theory union structure is a weaker test than the extensive structure test, i.e. the extensive structure dominates the set theory union structure. Then, if the extensive structure fails to ....

L. C. Briand, K. El Eman, and V. R. Basili, "Property-Based software engineering measurements," IEEE Transactions on Software Engineering, 22(1), 1996.

.... binding are concerned, with appropriate changes to rectify existing problematic discontinuities) the six MOOD metrics can be shown to be valid measures within the context of this theoretical framework [2] Proposals concerning the validation of software metrics have been published frequently ([18, 10, 19, 4, 20, 21]) and continue to be debated. The main problems which we encoutered during our theoretical validation stemmed from imprecise definitions of the attributes (and contributing units) to be measured; hopefully such problems will be alleviated as the importance of defining terms pre12 cisely becomes ....

L. C. Briand and S. Morasca, "Property-based software engineering measurement, " IEEE Transactions on Software Engineering, vol. 22, no. 1, pp. 68--85, 1996.

....between certain attributes (usually, relating internal and external attributes) 2. The model must be dimensionally consistent. 3. The metric must not exhibit any unexpected discontinuities. 4. The metric must use units and scale types correctly. Alternative views of metrics validation abound [10, 11, 12, 3]. In particular, there is some controversy concerning the use of scale types, and admissible statistical operations. Such issues are beyond the scope of this paper; we merely note that there is general consensus on the need to validate metrics, and draw attention to the approach adopted here. The ....

.... and developers of systems, giving them an evaluation of a system at the class level [3] despite the fact that their correctness from a measurement theory perspective [1, 24] continues to be debated [25, 26, 27] Indeed, the validation of software metrics also continues to invoke controversy [2, 3, 12, 28, 29]. The MOOD metrics, on the other hand, could be of use to project managers, as the metrics operate at a systems level, providing an overall assessment of a system. However, their utility will continue to be questioned until a sufficient number of empirical validations have been performed at a ....

L. Briand, S. Morasca, and V. R. Basili, "Property-based software engineering measurement," IEEE Transactions on Software Engineering, vol. 22, no. 1, pp. 68--85, 1996.

....research up to the present day. This works includes defining metrics that are relevant to new paradigms such as object oriented languages [14, 31] The subject area has also benefited from work that has established some theoretical underpinnings for software metrics. This work (exemplified by [12,18,52]) is concerned with improving the level of rigour in the discipline as a whole. For example, there has been considerable work in establishing a measurement theory basis for software metrics activities. While software metrics as a subject has been dominated by component 1 (defining specific ....

Briand LC, Morasca S, Basili VR, Property-based software engineering measurement, IEEE Transactions on Software Engineering, 22(1), 68-85, 1996.

.... the length of the test suite [PDKO93] are not always possible to apply, they require some assumptions on the specifications as for example the determinism, the completeness, and the minimality [KADC96a] To overcome this problem, we propose to use an abstract model based on mathematical relations [TARS41, SAND80, MILI90 and CBSM96] that allows a simple testability evaluation. The proposed model allows to analyze the testability without any assumptions on the specification. It can be used at different levels of abstraction depending on the available information of the specification. To illustrate our model and the associated ....

Lionel Briand and Sandro Morasca, Property-Based Software Engineering Measurement, IEEE Trans. on Soft. Eng.. Vol. 22, No. 1, January 1996.

....related to software are not easily understood. Most of the time it is not known how these systems really look like [19] Attributes like size, complexity and functionality are very general concepts that lack formal definitions, mainly because there exists little theory in software engineering [1]. Nonetheless, a lot of research was conducted to measure these concepts. However, if it is not known how the attributes are defined, you cannot develop valid measures for them. Using the formal measurement basis developed in this paper, internal attributes of M.E.R.O.DE. business object types and ....

Briand L., S. Morasca and V. Basili, `PropertyBased Software Engineering Measurement', IEEE Transactions on Software Engineering, Vol. 22, No. 1, 1996, pp. 68-68.

....the distance from a,e to a ,e . AOWSM97 10 semantics of the measures is determined since they satisfy a number of well defined axioms. The measurement approach outlined here is therefore similar to other property based measurement frameworks that are based on Measurement Theory 11 (e.g. [2]) or Belief Function Theory (e.g. 16] As long as functions satisfy the (pseudo )metric axioms, they can be used as business requirements complexity measures. The functions d alph and d seq proposed here, are examples of such functions. Note that the complexity of the business requirements is ....

Briand L.C., S. Morasca and V.R. Basili, `Property-Based Software Engineering Measurement', IEEE Transactions on Software Engineering, Vol. 22, No. 1, 1996, pp. 68-86.

....and Mehra [Ott95] extend the earlier work of Bieman and Ott that uses program slices to measure connectedness of class slices. Ott is currently pursuing this line of investigation. 2.3. 2 Module Interactions of Briand, Morasca, and Basili Briand, Morasca, and Basili define cohesion in design terms [Briand94, Briand96]. They view the elements of the module as its exported features, and a module as an abstract data type (ADT) An exported feature A interacts with feature B if the change of one of A s definitions or uses may require a change in one of B s definitions or uses. A single procedure may export ....

....suffered from a lack of basis in scientific measurement technique, or a misunderstanding of its application. The contributions of [Baker90] Fenton91] Fenton94] Melton90] Kitchenham95] Zuse91] have placed software measurement on a proper mathematical foundation. The work of [Bieman94] Hitz95] [Briand96] are examples of modern software measures firmly grounded in measurement theory. We wish to apply the same rigor to the BiemanKang cohesion measure. The design of a measure should start with an understanding the entity being studied [Fenton94] The entity in this research is a Java class. Next, ....

Lionel Briand, Sandro Moasca, Victor Basili. "Property-Based Software Engineering Measurement. " IEEE Transactions on Software Engineering, vol 22 no 1, January 1996.

....been plagued by problems of defining measures, collecting consistent and useful data cost effectively, performing analyses, interpreting results and putting these to good use. Hundreds of measures have been defined in the literature but few have been accepted in academia and even less in industry [Briand96]. Further confusion arises over whether measurements are taken to analyse the past, monitor the present, or predict the future. The last few years has seen a watershed in software measurement research with the recognition of the need for a more disciplined and scientific approach. This work is ....

L. C. Briand, S. Morasca, and V. R. Basili, "Property-Based Software Engineering Measurement," IEEE Transactions on Software Engineering, vol. 22, no. 1, pp. 68-85, January, 1996.

....class variables. 7 Note that this assumption is also made in related work (cf. section 5) III. A DISTANCE BASED APPROACH TO SOFTWARE PRODUCT SIZE MEASUREMENT A number of formal software product measurement approaches (e.g. Zuse and Bollmann [25] Grubstake MOM [11, 13] axiomatic approaches [5, 8, 10, 18, 20, 22, 23]) focus on the structure measurement of program abstractions. Other (axiomatic) approaches specific to object oriented software measurement require the definition of binary concatenation operations on measurement objects [24] While such operations can be defined on the syntax of measurement ....

....measurement object. Since the reference measurement object is used as an argument in the metric function, the same function can be used to measure alternative attribute definitions. Other work related to our research is the axiomatic approach to size measurement 17 of Briand, Morasca and Basili [5]. For a generic representation of a software system S = E,R , where E is a set of elements and R is a set of relations on E, a set of axioms 18 is presented that must be satisfied by size measures. Although the axiomatic size definition of Briand, Morasca and Basili is similar to our and ....

[Article contains additional citation context not shown here]

L.C. Briand, S. Morasca and V.R. Basili, `PropertyBased Software Engineering Measurement', IEEE Transactions on Software Engineering, Vol. 22, No. 1, 1996, pp. 68-86.

....set of subjective, but experienced, viewpoints on the concept of coupling. However, showing the invariance of the coupling properties for our measures is not the same as formally proving that they are valid. The coupling properties of Briand et al. were proposed in [6] and further refined in [7] and [19] These coupling and other concept (i.e. size, length, complexity, cohesion) properties have been used to analytically assess high level design measures [5] measures for Petri Net based specifications of concurrent software [18] and measures for object relational databases [20] The ....

L.C. Briand, S. Morasca and V.R. Basili, `Response to: Comments on "Property-Based Software Engineering Measurement": Refining the Additivity Properties', IEEE Transactions on Software Engineering, Vol. 23, No. 3, March 1997, pp. 196-197.

....figure 3) The instance variable v may be referenced by the methods of X. In section 2 a number of static coupling measures are defined for MERODE domain object classes. Next, in section 3 these measures are analysed using the well known set of coupling properties of Briand, Morasca and Basili [6]. The main goal of this analytical evaluation is to check whether the measures correspond to the concept of coupling such as understood by these experienced software engineering researchers associated (or previously associated) with the Software Engineering Laboratory (SEL) If enough evidence of ....

....X (i.e. abstraction) We therefore choose to measure both types of static coupling using separate measures. The static coupling between an object class and its environment (i.e. the other object classes in the model) may be evaluated from an inbound importing or an outbound exporting perspective [6, 16]. Whereas the former refers to the incoming static coupling relationships, the latter type of static coupling refers to the outgoing relationships. To avoid the double counting of coupling relationships (from a system point of view) a measure of class coupling must be defined from a specific ....

[Article contains additional citation context not shown here]

L.C. Briand, S. Morasca and V.R. Basili, `Property-Based Software Engineering Measurement', IEEE Transactions on Software Engineering, Vol. 22, No. 1, January 1996, pp. 6886.

....activity for the development environment. The two case studies focus on the high level design and specification phase, respectively, to illustrate the applicability of the approach to other phases than coding. We advocate the need for a formal definition of the mathematical properties of measures [18]. However, the definition of a measure is itself a very human intensive activity, which cannot be described and analyzed in a fully formal way. We expect GQM MEDEA to be refined and tailored to fit the needs of different application contexts, as we gain experience in applying it. Our framework ....

....A prediction made through an association is less informative than one carried out via a linear correlation, but it is less demanding in terms of the hypotheses on the underlying measure definition and precision. We provide properties that are, in our opinion, generic for size measures [18]. 3 Our properties are defined based on an abstract graph theoretic model since we may want to use them on all artifacts produced during software development. We do not intend to define sets of generic properties that should hold for single valued measures that capture all aspects of size. Like ....

[Article contains additional citation context not shown here]

L. Briand, S. Morasca, and V.R. Basili, "Property-Based Software Engineering Measurement," IEEE Trans. Software Eng., vol. 22, no. 1, Jan. 1996.

....of the hypotheses were supported by the empirical results, while others were not. In this paper, due to space constraints, we only report those hypotheses and measures that were supported by the empirical results. Specifically, we introduce and theoretically validate, based on the properties of [12], a family of measures for cohesion and coupling of high level object based software designs. 1. Object based systems differ from object oriented systems in that inheritance is not allowed. 0098 5589 99 10.00 1999 IEEE ################ #2 L.C. Briand is with the Fraunhofer Institute for ....

....cohesion, coupling, are hardly ever defined in a precise and unambiguous way, if they are defined at all. However, approaches have appeared in the recent literature to provide these attributes with less fuzzy and ambiguous definitions, using mathematical properties to characterize them [42] [12]. In our study, we have used an instantiation of the property based approach of [12] for our object based Ada context, to provide theoretical support for the definition of our measures of cohesion and coupling based on data declaration dependency links. These properties allow us to ....

[Article contains additional citation context not shown here]

L.C. Briand, S. Morasca, and V.R. Basili, "Property-Based Software Engineering Measurement," IEEE Trans. Software Eng., vol. 22, no. 1, pp. 68-86, Jan. 1996.

....artifact, each attribute is associated with a set of properties that its measure should satisfy. A few sets of properties have been defined [8, 9] which address single software attributes, e.g. complexity, or general properties for software measures [10] Here, we summarize the proposal of [11] because it addresses several different software product attributes. The proposal is based on a graph theoretic model of a software artifact, which is seen as a set of elements linked by relationships. The idea is to characterize the properties for the measures of a given software attribute via a ....

L. C. Briand, S. Morasca and V. R. Basili, Property-based software engineering measurement," IEEE Trans. Software Eng. 22 (1996) 68-86.

....design properties such as coupling or complexity are widely considered to be indicators of external system quality attributes, such as reliability or maintainability. Many measures taking structural properties of object oriented systems into account were proposed in the literature [1] 8][6]. A number of case studies have provided empirical evidence that by using regression analysis techniques, highly accurate prediction models for class faultproneness can be built from existing OO design measures [4] 5] The accuracy of the prediction models in these studies is usually quantified by ....

L. Briand, S. Morasca, V. Basili, "Property-Based Software Engineering Measurement", IEEE Transactions of Software Engineering, 22 (1), 68-86, 1996.

....variables (e.g. size, amount of reuse) and dependent variables (e.g. productivity, defect density) We intend to make the underlying assumptions and models clear, so a precise terminology is used in the rest of the article. A thorough and formal discussion of these issues can be found in [10]. The size of a system S is a function Size(S) characterized by several properties, including the following: Size cannot be negative (property Size.1) We expect size to be null when a system does not contain any component (property Size.2) More important, when components do not have ....

..... We expect size to be null when a system does not contain any component (property Size.2) More important, when components do not have elements in common, we expect Size to be additive (property Size.3) From these simple properties, other properties can be derived, as discussed in [10]. Let us assume an operator called Components, which, when applied to a system S, gives the distinct components of S, so that: Components(S) C 1 , C n , such that if C i =C j then i=j, where i, j=1, n. 106 October 1996 Vol. 39, No. 10 COMMUNICATIONS OF THE ACM Rework seems ....

Briand, L., Morasca, S., and Basili, V. Property-based software engineering measurement. IEEE Trans. Software Eng. 22, 1 (Jan. 1996), 68--86.

No context found.

Briand, L., Morasca, S. and Basili, V.R. (1996b). "Property-based Software Engineering Measurement". IEEE Transactions on Software Engineering, Vol. 22, No. 1, pp. 68-85.

....correlated to size, which may explain this unexpected relationship to fault proneness. All other measures (LCOM4, LCOM5, Coh, Co, TCC) are not significant predictors. This includes all normalized cohesion measures, except LCC. We consider normalization a necessary property of a cohesion measure [9], but it appears not to be effective from a prediction point of view. ISERN 98 29 Version 2 21 Comparison to UMD systems From the cohesion measures found significant in the LALO system, LCOM3 and ICH were also significant in the UMD systems. Coh was significant in the UMD systems, but not in ....

....address the question to which degree the coupling, cohesion, and inheritance measures used in this study measure the concepts they purport to measures. In [7] and [8] the coupling and cohesion measures were theoretically validated against properties for coupling and cohesion measures proposed in [9]. These properties are one of the more recent proposals to characterize coupling and cohesion in a reasonably intuitive but rigorous manner. The properties are considered necessary but not sufficient, as a measure that fulfills all properties is not guaranteed to make sense or be useful. Of the ....

L. Briand, S. Morasca, V. Basili, "Property-Based Software Engineering Measurement", IEEE Transactions of Software Engineering, 22 (1), 68-86, 1996.

..... We have a good understanding of the theoretical properties of measures for these attributes. This helps determine that a proposed coupling measure, for instance, is actually measuring what it purports to measure. For the selected internal quality attributes, operational, formal definitions exist [BMB96], against which proposed measures of these attributes can be checked. Furthermore, for each of these internal quality attributes, measures were identified that . can be collected automatically from source code, are applicable to C and Java and the different communication technologies ....

L. Briand, S. Morasca, V. Basili, "Property-Based Software Engineering Measurement." IEEE Transactions on Software Engineering, 22 (1), 1996, p. 68-86

No context found.

Briand, J., Morasca, S., Basili, V., 1996b. Property-Based Software Engineering Measurement. IEEE Transactions of Software Engineering, 22 (1), 68-86.

....design properties such as coupling or complexity are widely considered to be indicators of external system quality attributes, such as reliability or maintainability. Many measures taking structural properties of object oriented systems into account were proposed in the literature [1] 8][6]. A number of case studies have provided empirical evidence that by using regression analysis techniques, highly accurate prediction models for class faultproneness can be built from existing OO design measures [4] 5] The accuracy of the prediction models in these studies is usually quantified by ....

L. Briand, S. Morasca, V. Basili, "Property-Based Software Engineering Measurement", IEEE Transactions of Software Engineering, 22 (1), 68-86, 1996.

....has shown that the cost of such a continuous software process improvement mechanism can be kept under a reasonable percentage of the development cost. This paper is in large part based on the SEL experience and a few other process improvement experiences in which the authors were involved (Briand et al. 1994; 1995; El Emam and Madhavji 1995a; 1995b) This paper is structured according to the phases of a process improvement activity as we see it. Although these phases are presented sequentially, in most cases they are overlapping. We try not to focus exclusively on technical issues but to provide a ....

....of process models. Some of this method s main steps that are most relevant here are: understanding the organizational environment, defining the objectives of the modeling exercise, planning the elicitation strategy, developing the process model, and validating the process model. Similarly, Briand et al. 1994; 1995) have described their acquisition process for collecting information suitable for the construction of models. The steps in the acquisition process include: determining the hierarchical structure in the organization, determining the roles covered by the positions in the hierarchy, and ....

[Article contains additional citation context not shown here]

L. Briand, S. Morasca, V. Basili (1994). "Property-Based Software Engineering Measurement", CS-TR-3368, University of Maryland, College Park, MD, 20742, November 1994.

....the hypotheses underlying measure definition and precision. Therefore, depending on the needs of the application case, one may choose to define measures at different levels of measurement. 5.1. 2 Examples Here, we provide properties that are, in our opinion, generic for measures related to size [BMB96] 1 . Our properties are defined based on an abstract graph theoretic model, since we may want to use them on all artifacts produced during software development. We would like to point out that we do not intend to define sets of generic properties that should hold for 1 For brevity, we do not ....

....are defined based on an abstract graph theoretic model, since we may want to use them on all artifacts produced during software development. We would like to point out that we do not intend to define sets of generic properties that should hold for 1 For brevity, we do not show the properties of [BMB96] related to coupling. Also, the reader is referred to [BMB96] for a thorough discussion of these properties and their comparison with those existing in the literature. U. of Maryland, CS TR 3343, Version 2 14 single valued measures which capture all aspects of size. Like in [FP96] we do not ....

[Article contains additional citation context not shown here]

L. Briand, S. Morasca, V. Basili, "Property-based Software Engineering Measurement," IEEE Trans. Software Eng., 22 (1), January, 1996.

....dependent variables used in this study, i.e. size, reuse, effort, productivity, defect density. We intend to make the underlying assumptions and models clear so that a precise terminology can be used in the remainder of the paper. A thorough and formal discussion of these issues can be found in [10]. 2.4.1 Size The size of a system S is a function Size(S) that is characterized by the properties: Size cannot be negative (property Size.1) and we expect it to be null when a system does not contain any component (property Size.2) More importantly, when components do not have elements in ....

.... Size.1) and we expect it to be null when a system does not contain any component (property Size.2) More importantly, when components do not have elements in common, we expect Size to be additive (property Size.3) From these simple properties, other properties can be derived as discussed in [10]. Let us assume an operator called Components which when applied to a system S, gives the distinct components of the system S, such that: Components(S) C1 , Cn , such that if C i =C j then i=j, where i, j=1, n . The size of a system S is given by the following function: Size(S) c ....

L. Briand, S. Morasca, and V. Basili: "Property Based Software Engineering Measurement." In IEEE Transactions on Software Engineering, SE-22(1):68-86, January 1996.

No context found.

L. Briand, S. Morasca, and V. Basili, "Property-Based Software Engineering Measurement", IEEE Transactions on Software Engineering, 22 (1), pages 68-86, January, 1996.

....( M OVR c ( c m M I c ( ICH SS ( ICH c ( c SS = CI c ( Max c ( ISERN 97 05 19 4.3. 3 Theoretical validation In this section, we theoretically validate the cohesion measures in Table 1 with respect to four cohesion properties defined by Briand et al. [BMB96]. The motivation behind defining such properties is that a measure must be supported by some underlying theory if it is not, then the usefulness of that measure is questionable. The four cohesion properties defined by Briand et al. are one of the more recent proposals to characterize cohesion in ....

....and methods to classes, how to account for polymorphism. 5. How to account for access methods and constructors. These criteria are necessary to consider when specifying a cohesion measure. However, they are not sufficient, as other aspects such as properties of measures (e.g. those proposed in [BMB96]) and results from empirical validation studies have to be considered too. The influence of these aspects is not addressed here. We now describe each of the criteria in the order given above. 5.1 Framework criteria 5.1.1 Type of connection By type of connection we mean the mechanism that makes a ....

L. Briand, S. Morasca, V. Basili, "Property-Based Software Engineering Measurement", IEEE Transactions of Software Engineering 22 (1), 68-86, 1996.

No context found.

L. Briand, S. Morasca, V. Basili, "Property-based Software Engineering Measurement," CS-TR 3368, UMIACS-TR 94-119, University of Maryland, College Park

....of the hypotheses were supported by the empirical results, while others were not. In this paper, due to space constraints, we only report those hypotheses and measures that were supported by the empirical results. Specifically, we introduce and theoretically validate, based on the properties of [BMB96], a family of measures for cohesion and coupling of high level object based software designs. Our measures focus and are based on one specific facet of cohesion and coupling, i.e. that related to declaration links among data and subroutines appearing in highlevel design module interfaces. ....

....cohesion, coupling) are hardly ever defined in a precise and unambiguous way, if they are defined at all. However, approaches have appeared in the recent literature to provide these attributes with less fuzzy and ambiguous definitions, using mathematical properties to characterize them [W88] [BMB96]. In our study, we have used an instantiation of the property based approach of [BMB96] for our object based Ada context, to provide theoretical support for the definition of our measures of cohesion and coupling based on data declaration 5 dependency links. These properties allow us to ....

[Article contains additional citation context not shown here]

L. Briand, S. Morasca, V. Basili, "Property-Based Software Engineering Measurement", IEEE Trans. Software Eng., 22 (1), January 1996, pp. 68 - 86.

....dimensions: the measures contributing to the variance of each PC are either all normalized or non normalized. No dimension includes both normalized and non normalized measures. Although it is still unclear whether cohesion measures should be normalized to reflect variations in size across classes [BMB96] it is definitely a decision which has an impact on the structural property captured by the measures. The results also indicate that the types of connections within a class that are counted by the measures make a difference. The dimensions of PC2 and PC4 are defined by normalized measures, ....

....decreases. The only exception to this is ICH, where the positive coefficient suggests that fault proneness increases with cohesion. Again, this indicates that ICH is very likely not a cohesion measure. In fact, ICH can be shown to fulfill the properties for complexity measures defined in [BMB96] We can then interpret this result that the higher the complexity of a class, the more fault prone it is. Only the measures LCOM3, Coh, and ICH are significant at a=0.05. ICH is very significant (p=0.0002) but unlikely to measure cohesion. Overall, these results only weakly support our ....

[Article contains additional citation context not shown here]

L. Briand, S. Morasca, V. Basili, "Property-Based Software Engineering Measurement", IEEE Transactions of Software Engineering, 22 (1), 68-86, 1996.

....methods, and representations currently used in the field of software architecture, and integrate these into an operational framework. Among other things, such a framework should integrate the scenariobasedanalysis principles of SAAM [KABC96] and the quality measurement framework laid down in [BMB96, BDW 96, 97]. Elements of psychometrics (for subjective measurement of architectural attributes) and multi criteria decision making (for risk mitigation related to various quality attributes objectives) will also be utilized. The SEI PLS program and the IESE QPE department provide complementary expertise in ....

L. Briand, S. Morasca, V. Basili, "Property-Based Software Engineering Measurement", IEEE Transactions on Software Engineering, Vol. 22, No. 1, 68-86, 1996.

....methods . The measures for method method interaction by Briand et al. are counts of static method invocations only [BDM96] 4.3. 9 Theoretical validation In this section, we theoretically validate the coupling measures in Table 2 with respect to five coupling properties defined by Briand et al. [BMB96]. The motivation behind defining such properties is that a measure must be supported by some underlying theory if it is not, then the usefulness of that measure is questionable. The five coupling properties defined by Briand et al. are one of the more recent proposals to characterize coupling in ....

....coupling, and how to account for polymorphism, and how to assign attributes and methods to classes. These criteria are necessary to consider when specifying a coupling measure. However, they are not sufficient, as other aspects such as properties of measures (e.g. those proposed in [BMB96]) and results from empirical validation studies have to be considered too. The influence of these aspects is not addressed here. We now describe each of the criteria in the order given above. 5.1 Framework criteria 5.1.1 Type of connection Choosing a type of connection implies choosing the ....

L. Briand, S. Morasca, V. Basili, "Property-Based Software Engineering Measurement", IEEE Transactions of Software Engineering, 22 (1), 68-86, 1996.

....are not significant predictors. All measures of PC2 are significant: LCOM1, LCOM2, and ICH. Two of these measures, LCOM1 and ICH are correlated to size. None of the measures in PC1 is significant. This PC contains normalized measures, which we consider a necessary property of a cohesion measure [8], but which appears not to be effective from a prediction point of view. In PC3 (connectivity) only LCOM3 is significant at a = 0.05 (in the expected direction) Variants of the same measure that lie in the same PC also have similar results for univariate analysis. Both LCOM5 and Coh of PC1 are ....

....address the question to which degree the coupling, cohesion, and inheritance measures used in this study measure the concepts they purport to measures. In [6] and [7] the coupling and cohesion measures were theoretically validated against properties for coupling and cohesion measures proposed in [8]. These properties are one of the more recent proposals to characterize coupling and cohesion in a reasonably intuitive but rigorous manner. The properties are considered necessary but not sufficient, as a measure that fulfills all properties is not guaranteed to make sense or be useful. Of the ....

L. Briand, S. Morasca, V. Basili, "Property-Based Software Engineering Measurement", IEEE Transactions of Software Engineering, 22 (1), 68-86, 1996.

....method for the theoretical and empirical validation of measures of internal software product attributes and provide guidelines for its application. In this method, we also integrate many of the relevant existing concepts for validation (e.g. measurement theory [F91] Z91] properties of measures [BMB96], and GQM [BR88] To briefly summarize our method, below are its four main steps: 2 Theories may be more or less straightforward and may look more or less obvious. Some theories may no longer require to be empirically demonstrated. As a very simple example, the size of a compiled program is an ....

....is trying to measure is crucial in deriving valid and useful measures. However, confusion in terminology and lack of consensus in the software engineering community make it more difficult to formalize empirical relational systems. Complexity is a good example of confusion in software engineering [BMB96]. We therefore believe it is important that software measurement researchers agree on a basic set of properties that the empirical relational systems of common internal attributes (i.e. complexity, coupling, etc. should have. This will help software engineering researchers and practitioners (1) ....

[Article contains additional citation context not shown here]

L. Briand, S. Morasca, and V. Basili: "Property Based Software Engineering Measurement." In IEEE Transactions on Software Engineering, 22(1), January 1996. -

....measurement is to become a scientific discipline, the meaning of these concepts must be made clear and unambiguous, and similarities and differences between measurement concepts must be pointed out. Measurement Theory, if properly applied, is one of the most precious tools in this task. In [BMB94], we proposed a set of properties to characterize size, complexity, cohesion, coupling, and length. Our goal was not to provide the sets of properties for each of those concepts, but to point out the need for a clear separation between them. Measurement concepts that are different in nature ....

L. Briand, S. Morasca, and V. Basili: "Property Based Software Engineering Measurement." Technical Report, CS-TR-119, University of Maryland, November 1994.

No context found.

L. Briand, S. Morasca, and V. Basili: "Property Based Software Engineering Measurement." Technical Report, CS-TR-3368, University of Maryland, December 1994. Submitted for publication.

No context found.

Briand, L.C., S. Morasca and V.R. Basili, 1996. Property-based software engineering measurement. IEEE Trans. Softw. Eng., 22: 68-86.

No context found.

# L.C. Briand, S. Morasca, and V. Basili, "Property-Based Software Engineering Measurement," IEEE Trans. Software Eng., vol. 22, pp. 68-86, 1996.

No context found.

L. Briand, S. Morasco, V. Basili. Property-Based Software Engineering Measurement. IEEE Transaction on Software Engineering, vol. 22, no. 1, January 1996.

No context found.

L. C. Briand, S. Morasca, and V. R. Basili, "Property-Based Software Engineering Measurement," IEEE Transactions on Software Engineering, vol. 22, pp. 68-86, 1996.

No context found.

L. C. Briand, S. Morasca and V. Basili. Property-Based Software Engineering Measurement. IEEE Transactions on Software Engineering, Vol.22, No.1, pp.68-86, 1996.

No context found.

Briand, L.C., Morasca, S. and Basili, V., "Property-based software engineering measurement", IEEE Transactions on Software Engineering., 1996, 22(1) pp. 68-85

No context found.

L.C. Briand, S. Morasca and V. Basili. Propertybased software engineering measurement. IEEE Transactions on Software Engineering. 22(1). 68-85, 1996.

No context found.

L.C. Briand, S.Morasca, V.R. Basili. Property-Based Software Engineering Measurement. IEEE Transactions on Software Engineering, 22(1), January 1996

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC