Extended Cyclomatic Complexity Metric for XML Schemas

Transcription

1 Extended Cyclomatic Complexity Metric for XML Schemas Reem Alshahrani Department of Computer Science, Kent State University, Kent, Ohio, USA Ministry of Higher Education, Riyadh, Saudi Arabia Abstract- Extensible Markup Language (XML) plays an extremely important role in the Web application development process. It is a universal format for data and has been adopted for exchanging information among distributed applications. Because XML documents are usually large, it is necessary to find ways to enhance their ease of use and maintainability by keeping their complexity low. In this research, we propose a revised and improved complexity metric for XML Schema documents (XSD) based on the McCabe complexity metric, which is used to measure cyclomatic complexity. The proposed metric measures complexity according to the complexity of the usage of the XSD components and for binding the XML data into native language. 1 Introduction Accessing the Internet is very important to most people. Web usage continues to grow at an astounding rate, and the amount of data conveyed by the many documents available on the Web has also increased exponentially. While information sharing among different parties connected to the Internet has become pervasive, most companies have started providing Web applications to increase business productivity by making data continuously available. The need for information transmission from one party to another has resulted in the emergence of a standard mechanism for information exchange that can be easily implemented by different domains. Extensible Markup Language (XML) is a meta markup language that was developed by the World Wide Web Consortium. The main purpose of XML is to simplify Standard Generalized Markup Language (SGML) by focusing on a particular problem documents on the Internet. That makes using SGML easier and more straightforward, which makes XML a suitable choice to define document types, to author and manage SGML-defined documents, and to transmit and share documents across the Web. XML has eliminated many of the more complex and human-oriented features of SGML to simplify implementation environments, such as documents and publications. It provides a good combination of simplicity and flexibility and has been rapidly adopted for many other uses. As information sharing in distributed computing environments becomes more widespread, XML becomes more popular as a universal data format for exchanging structured information between distributed Web applications. Because of its highperformance, XML has been gaining general acceptance as a standard for data representation and transmission between distinct applications running on different networks, such as educational services, digital libraries, and e-commerce. Due to the powerful expressive capability of data and documents and XML s flexible nature and ease of use, it has been adopted as a standard mechanism for structuring data and creating effective information retrieval. Intense competition between companies to optimize Web application performance for end-users naturally leads to concerns of quality for these applications. XML metrics can be important for predicting the quality and complexity of Web applications. These metrics play a role in ensuring high-performance for XML documents; their complexity can be determined based on various syntactic and structural aspects. Many researchers have started to define complexity metrics for XML documents. In their research to investigate the complexity of an XML Schema, Lammel, Kitsis, and Remy [6] used several well-known procedural metrics, such as LOC, McCabe, Fan-in and Fan-out, and Depth Inheritance Tree (DIT). Other researchers, like Dilek Basci and Sanjay Misra [7], designed metrics to measure the complexity of an XML schema structure. The present research focuses on defining the quality of the XML Schemas designed for Web applications by extending the McCabe complexity metric (MCC). The old metric [6] focuses on the number of decisions regardless of the complexity of these decisions. An XML Schema has many complex features that noticeably increase the complexity of XML documents. In our new metric, we concentrate on the features that add more complexity for XML documents and that are specifically designed for Web applications. By measuring the complexity and keeping

2 it low, the ease of use and the maintainability of the Web applications may be improved. When discussing the effectiveness of software, it is often discussed in the context of principles about the complexity of achieving increased functionality. We suggest certain changes to the XML McCabe Complexity Metric that are geared toward use with web-based software that implements XML documents. We propose a weighted complexity measure that gauges the level of complexity based on certain decision schemas. Thus, the aim of our metric is to add greater complexity values to schemas that are highly interdependent or cyclic. This proposed metric is important because of the widespread use of XML on the web. Also, the original XML MCC measure did not include weights for complexities that spanned successive iterations of variables in a system. Thus, it was not sufficiently sensitive for data models manipulated in XML. This paper is organized as follows: first, major concepts about XML Schema are briefly discussed. For readers who are not familiar with XML, we recommend looking at [5]. Next, the implementation of XML McCabe Complexity metric is explained. Then, the importance of this study is discussed with a justification for these changes. At the end, a prediction of the results is proffered followed by the theoretical validation for the proposed metric. 2 XML Schema 2.1 XML Structure Many schema languages are used to describe the structure of an XML document, such as Document Type Definitions (DTDs), XML Schema Definition (XSD), or RELAX NG. These schemas' languages are expressed in terms of constraints on the structure. In this research, we chose to study XSD because it is richer and more powerful than DTD in describing XML languages. XSDs have a rich data typing system and allow for more detailed constraints on XML documents. For example, XSDs can describe structural relationships and data types that cannot be expressed using DTDs. XSDs support namespaces and are extensible for future additions. These features make XSD a widely used language for Web applications. XSDs should be properly designed to improve the ease of use and the maintainability of the Web applications by keeping their complexity low. Thus, it is useful and important to find ways to measure the complexity of XSD. 3 New Extended Cyclomatic Complexity Metric for XML Schema 3.1 Cyclomatic Complexity for XML Schema In this research, we will focus on cyclomatic complexity, which was developed by Thomas J. McCabe, Sr. in By assigning numerical values to the complexity using MCC, developers may be able to evaluate the ease of use, maintainability, and quality of the XSD. This idea was proposed and developed by Lammel, Kitsis, and Remy [6]. In this paper, we extend their work by revising and improving their metric. McCabe proposed that the complexity of a program can be determined by the complexity of the control graph, and he measured this complexity by computing the number independent control paths in the program [11]. In practice, the cyclomatic complexity (CC) of a graph (G) may be computed according to the following formula: CC(G) = #(edges)- # (nodes) + 1 For a program with control flow graph G, CC(G) is also equal to the number of binary decisions in the program plus one. In [6], this method for calculating CC(G) motivates the use of MCC to calculate the complexity of XLM Schemas, and we build on [6] to develop a revised metric for calculating the complexity of XLM Schemas. In [6], Lammel, Kitsis, and Remy explain how to apply MCC to XML Schemas, using an existing work to adopt MCC for context-free grammars. XML Schemas may be considered grammars, which means that MCC can be applied to them, and this is done by counting decisions. That is, the number of decisions in an XML schema is used to calculate the MCC of the schema. Lammel, Kitsis, and Remy postulated that the decision nodes in XSD include choices, element references to substitution groups, type references to types that are extended or restricted, occurrence constraints, the multiplicity of root element declarations, and nillable elements. These decisions are explained in [6] and we give the following summaries Choices The XSD choice element is one of the model groups. It allows only one of the child elements in the <choice> declaration to be present within the containing element. The choice-model group with n branches contributes n to a schema s MCC Element References to Substitution Groups If h is the name of the head of a substitution group with n > 0 non-abstract participants, potentially counting h itself (if it is non-abstract), then each

3 element reference to h contributes n to a schema s MCC Type Reference If t is the name of a user-defined (as opposed to primitive) type with n > 0 non-abstract subtypes (including derived types and t itself if it is nonabstract), then each type reference to t contributes n to a schema s MCC Occurrence Constraints In MCC, if the minoccurs and maxoccurs attributes for a particle schema component have distinct values, then the component attribute contributes 1 to a schema s MCC. However,if they are the same then this component attribute does not add complexity to the schema. The default value for each one is 1 but if they have different values they will contribute 1 to the schema's MCC. <!-- The following element carries an occurrence constraint. --> <xs:element name= branch2 type= xs:int maxoccurs= unbounded /> <!-- There is a reference to a substitution group. --> <xs:element ref= foo /> </xs:choice> </xs:extension> </xs:complexcontent> </xs:complextype> </xs:schema> Figure 3: MCC for XSD [6] The Multiplicity of Root Element Declarations Root elements are declared in the context of the schema, not within the context of a particular type. The <schema> element is the root element of every XML Schema. The number of root-element declarations is added to a schema s MCC Nillable Elements Each nillable attribute with value true contributes 1 to a schema s MCC. These decisions are illustrated in Figure 3: <?xml version= 1.0 encoding= utf-8?> <!-- McCabe complexity is > <xs:schema xmlns:xs= > <!-- Two root-element declarations --> <!-- The first one references a base type. --> <xs:element name= foo type= type1 /> <!-- The second one references to substitution or derived type. --> <xs:element name= bar substitutiongroup= foo type= type2 /> <xs:complextype name= type1 /> <xs:complextype name= type2 > <xs:complexcontent> <xs:extension base= type1 > <!-- A choice with three branches --> <xs:choice> <!-- The following element is nillable. --> <xs:element name= branch1 type= xs:int nillable= true /> Figure 4: Tree representation for the previous schema Lammel et al used a simple method, which is obtaining a single ordinal number totaling all decisions for each schema to determine the structural complexity of a schema as previously described. Thus, the MCC for XSD captures the subtype polymorphism induced complexity, which increases with the number of subtypes. The tree representation of the schema in Figure 3 shows that each edge in the tree considered as a decision that contributes 1 to the complexity number of the schema except the dotted edge which represents the default root element for the schema. 4 Proposed Modifications for MCC MCC measures a schema s complexity by counting the number of decisions in the schema but that does not provide sufficient information about complexity values of these decisions. The data complexity of each independent element is also important, and this is missing in MCC for XSD language. Our new and important assumption or observation is that using basic concepts and features makes the schema easier to understand, i.e., less complex. For instance, using an attribute group can improve the readability of schemas and assist in the

4 process of updating them because an attribute group can be defined and edited in one place and referenced in multiple definitions and declarations. Other attributes need to be redefined in case of any modification of the reference, such as derivation by restriction, which is more difficult for the schema designer. The more advanced the features are, the more complex the resulting schema will be. For this reason, in this part of the research, we will discuss the most important concepts that contribute to the complexity of XML Schemas. These features are explained below in detail. 4.1 XML Schema xsd:any Element and xs:anyattribute The xsd:any element and xs:anyattribute provide the ability to extend the XML document with elements or attributes that are not specified by the schema. These features turn the XML Schema into an open content schema. With the xsd:any element, we have complete control over how much extensibility we want to allow and where. For example, suppose that we want to enable there to be at most two new elements at the top of Store's content model (see Figure 5). <xsd:complextype name="storetype"> <xsd:choice> <xsd:any namespace="##any" minoccurs="0" maxoccurs="2"/> <xsd:element name="item" type="xsd:string"/> <xsd:element name="seller" type="xsd:string"/> <xsd:element name="quantity" type="xsd:gyear"/> <xsd:element name="retailprice" type="xsd:string"/> </xsd:choice> </xsd:complextype> Figure 5: Using xsd:any element as a child in the xsd:choice element In Figure 5, the xsd:any element has been placed at the top of the xsd:choice element, and it is set to maxoccurs="2". In instance documents, the <Store> content will always end with <Item>, <Seller>, <Quantity>, and <RetailPrice>. Prior to that, two wellformed XML elements may occur. Using xsd:any element is essential for many designers because it provides more flexibility. It turns instance documents from static structures into dynamic data objects. In practical use, this element increases the complexity of dynamic access to XML documents. The xsd:any element lets one create complextype definitions in the schema without defining the exact structure of certain parts of that complex type. When the XML Schema exists as a part of a Web service, language binding for the mapping of xsd:any element will be used. This process may not be easily done with those elements that increase the complexity. The document will be more difficult to understand and to maintain. For instance, assume that XML elements that occur in a Simple Object Access Protocol (SOAP) message should be mapped into Java objects. There are rules to determine how to map simple and complex types. If there is an xsd:any element in the XML Schema, the programmer has to be concerned with type mapping and serialization and deserialization of data. That is, the programmer will have to know how to parse an XML element and turn it into the appropriate Java object, and vice versa. As a result of the complexity that may be caused by xsd:any element, we will add weight to the xsd:choice decision if it has xsd:any element. Table 1 shows different tools used for mapping and binding XML documents from XML Schema into object oriented classes or relational tables to be used in data exchange. Table 1: Shows the supporting levels of xsd:any element in different languages Tool Supporting Level.NET Framework Partially supported Java WSDP Recently supported with additional code Siebel Support Level Partially supported 4.2 XML Schema xs:redefine Element The redefine element redefines simple and complex types, groups, and attribute groups from an external schema. <xs:redefine schemalocation="dcterms-elem.xsd"> <xs:simpletype name="agentscheme"> <xs:restriction base="agentscheme"> <xs:enumeration value="overheid:city"/> <xs:enumeration value="overheid:province"/>... </xs:restriction> </xs:simpletype> </xs:redefine> Figure 6: Example of using xs:redefine element as a root element The XSD language provides an element for updating a type definition in a process whereby the type is effectively derived from itself. The xs:redefine that is used for redefining performs two tasks. The first is that it acts as an xs:include element by bringing in declarations and definitions from another schema

5 documents and making them available as part of the current target namespace. The declarations and types in the schema must be from a schema with the same target namespace or one that has no namespace. Secondly, types can be redefined similar to type derivation, with the new definition replacing the old one. By using xs:redefine, schema instances can include group or type definitions from schema documents and then pervasively change these definitions. Redefinition affects type or group definitions in the including schema and those in the included schema as well, which is why it is considered pervasive. All references to the original type or group in both schemas refer to the redefined type, while the original definition is overshadowed. This leads to a problem with the schema because redefined types can unfavorably interact with derived types and cause conflicts. A common conflict is when a derived type uses an extension to add an element or attribute to a type's content model; a redefinition also adds a similarly named element or attribute to the content model. Redefining elements can produce unexpected results, such as ill-formed definitions, on other type definitions that are based on the redefined definitions. The.NET Framework and Java Web Services Developer Pack (Java WSDP) do not provide binding support for the xs:redefine element. Application developers have to manually create these artifacts. For these reasons, an element with xs:redefine is assigned extra weight for that element because of the high level of complexity caused by its features. Table 2: Shows the supporting levels of xs:redefine in different languages. Tool Supporting Level.NET Framework Ignored Java WSDP Ignored Siebel Support Level Ignored 4.3 Derivation By Restriction in Complex Types Restriction of complex types means creating a derived complex type whose content model is a subset of the base type. Derivation by restriction in complex types is considered to be the most difficult derivation to understand. It does not map to the concepts in object oriented programming (OOP) or relational database theory, which are primary consumers and sources of XML data. One issue in using this derivation arises from the way restrictions are declared. When deriving a complex type from another complex type by restriction, its content model must be duplicated and refined. This duplication can replicate definitions, possibly down a long derivation chain, so any modification to a derived type must be manually propagated down the derivation tree. As previously mentioned, using derivation by restriction in complex types is incompatible with the notion of derivation in an object oriented sense. Certain aspects of derivation by restriction do not map well to tables in a relational database, and XML Schemas that use derivation by restriction are more difficult to model as classes in an OOP language. This causes mismatch, which occurs when trying to map the contents of an XML document into a relational database or convert an XML document into an instance of an OOP class. This feature is one of the most complex features in the XML Schema. It often causes bugs during the mapping process. It can be seen why this feature should warrant additional weight when computing the complexity of an XML Schema. Table 3: Shows the supporting levels of complex type derivation by restriction in different languages. Tool Supporting Level.NET Framework Partially supported Java WSDP Partially supported with bugs Siebel Support Level Partially supported with bugs The result of the previous discussion is that counting the schema decisions but neglecting the internal architecture of the decisions does not adequately capture the complexity of a given schema. In other words, two schemas having the same number of decisions may have much different complexities since the internal structures may be different. These difference complexities can, however, be measured by using the new metric which is defined in the next section. 5 Extended McCabe Complexity Metric 5.1 Implementing the Modifications We have explained how Lammel, Kitsis, and Remy apply the McCabe complexity metric to an XML Schema when all decisions are assumed to be equally complex. However, it is not the case that all decisions are equally complex. We examine complex decisions, and we assign weights to types of decisions based on their complexity. In this manner we arrive at a new and improved metric which is an extension of the McCabe Complexity Metric for XML Schemas. The complexity caused by using these features increases the complexity of the programs that are written to manipulate the data in the schema. If one of

6 these features appears in one of the previous decisions, we will assign it a specific weight. By adding weights to these decisions, we make the MCC number more reliable in measuring the ease of use and the maintainability of XML Schemas. The complexity metric of Lammel et al is expressed as: MCC(XSD)= D (1) where D= the decisions As previously explained, the complex features of the XML Schema can affect the schema and add complexity for the schema at different levels. Based on this study, D1, D2, and D3 are decision groups in that the decision types which will be in D1 are considered less complex than those in D2, and those in D2 are considered less complex than those in D3 as described below: D 1, decisions D 2, if decision includes xsd:any element or xs:anyattribute D 3, if one of the schema elements is declared by using xs:redefine or derived by restriction We can calculate the complexity of the XML Schema using the extended McCabe cyclomatic complexity metric using the following function: EMCC(XSD) = D D D 3 (2) The proposed metric measures the complexity using the number of the decisions with a specific weight for each decision. The values of these weights depend on the complexity level of each complex feature. Thus, the xsd:any element and xs:anyattribute will be assigned a weight of 2. The reason is the complexity of these features is not related to any other element in the schema since there is no reference or derivation related to this feature. Thus, this feature will affect the attribute itself but not any other attribute in the schema. On the other hand, the other features (xs:redefine and derivation by restriction in complex types) will be assigned a weight of 3. The complexity added by these two features affects other components in the schema. As explained earlier, the xs:redefine element modifies another components of another schema and restriction by derivation in complex types affects other complex types and increase the inheritance depth. For the tree representation for the schema, for Lammel et al we will have a weight of one of each edge. However, for EMCC these weights are modified based on the features complexity. In the new resulting tree, where every edge has a weight of 1, 2 or 3, we simply add all that weights up. These weights help to determine the actual complexity of a given schema according to the number of decisions and the structure of the schema. That makes the resulting complexity number more reliable by specifying the complexity of the structure. Nevertheless, there is a good justification, as given in the paper, for the proposed weights, but it is also clear that future research may justify modifying the weights. 6 Validating the Proposed Metric The theoretical validation of a proposed metric helps justify the use and value of complexity metrics. We use the description of properties of Briand et al [8]. In this section we will validate if our proposed metric satisfies the five properties of a complexity metric. The elements of E are the default root element for an XML schema, XML schema decisions, and leaves. More exactly, the leaves are the possible final or non-choice outcomes from the decisions. For example, if we have the leaf node nillable, this leaf will be instantiated with a true or false. The relationships or arcs, which are the elements of R, represent choices which need to be made. Thus, arcs only come from choice nodes. There may be choice nodes with only one arc coming from them. For example, if the choice is nillable, then only one arc will come from this node. It should be noted that by convention no edge comes from the default root element. Given a system S = (E,R),where E= elements and R= relationships ( edges), the MCC for an XML schema is the number of edges in S. We want to verify the five properties for complexity metrics given in [8]. Property Complexity 1 Non-negativity: The complexity of a system S = <E, R> is non-negative if: EMCC(S)! 0 Since our metric counts the number of edges in S, then our metric always returns 0 or a positive value. Property Complexity 2 Null Value: The complexity of a system S = <E, R> is null if R is empty. R=! " EMCC(S)= 0 If R is empty, then our metric returns the value 0. Property Complexity 3 Symmetry: The complexity of a system S = <E, R> does not depend on the convention chosen to represent the relationships between its elements: ( S = E, R ands!1 = E, R!1 ) " EMCC(S) = EMCC(S!1 )

7 Since R and R -1 have the same number of elements, then our metric returns the same answer for S and S -1. Since Properties 4 and 5 involve modules, we define a module of S to be any subgraph of S. Let T be a subgraph of S; let ET be the elements in T; and let R T be the relationships in T. Then EMCC(T) is the number of relationships in R T, i.e., EMCC(T)= R T. Property Complexity 4 Module Monotonicity: The complexity of a system S = <E, R> is no less than the sum of the complexities of any two of its modules with no relationships in common: (S = E,R and m1= E m1,r m1 and m2 = E m2,r m2 and m1! m2 " S and R m1 # R m2 = $) ( ) % EMCC(S) & EMCC(m1) + EMCC m2 Let U and V be two modules in S such that R U and R V have no relationships in common. Since every relation that is in R U or in R V is also in R and since no relationship is in both R U and R V, then clearly EMCC(U) + EMCC(V) EMCC(S). In fact, EMCC(S) may be much larger than EMCC(U) + EMCC(V) because R may contain many relationships which are in neither R U nor R V. Property Complexity 5 Disjoint Module Additively: The complexity of a system S = <E, R> composed of two disjoint modules m1, m2, is equal to the sum of the complexities of the two modules: (S = E, R and S = m1! m2 and m1 " m2 = #) $ EMCC(S) = EMCC(m1) + EMCC(m2) Let U and V be two modules in S such that R U and R V have no relationships in common. Since every relation that is in R U or in R V is also in R and since no relationship is in both R U and R V, then clearly EMCC(U) + EMCC(V) EMCC(S). In fact, MCC(S) may be much larger than EMCC(U)+EMCC(V) because R may contain many relationships which are in neither R U nor R V. 7 Summary Extensible Markup Language (XML) is a universal format for data and has been adopted for exchanging information among distributed applications. This research proposes a new complexity metric for XML Schema documents (XSD) based on the McCabe complexity metric (MCC), which is used to measure cyclomatic complexity and on the work of Lammel, Kitsis, and Remy, who showed how the McCabe metric could be applied to XML schemas. Many schema languages are used to describe the structure of an XML document. XSD was chosen for the study because it is richer and more powerful than others. The XML Schema is the structural representation of an XML document. MCC is used to measure the complexity of ordinary programs and needs to be adapted to XSD. Our new metric measures the complexity using the number of the decisions with a specific weight for each decision. Thus, the xsd:any element or xs:anyattribute is assigned a weight of 2, and the other features (xs:redefine and derivation by restriction in complex types) are assigned a weight of 3. These weights help to determine the actual complexity of a given schema according to the number of decisions and the structure of the schema. This means that the resulting complexity number is more sensitive to the complexity of different parts of the structure. The proposed metric is validated based on five complexity properties. 8 Acknowledgement I am extremely grateful to Prof. Austin Melton for his support and suggestions throughout the research and writing for this paper. 9 References [1] [2] [3] [4] [5] [6] R. Lammel, S. Kitsis, and D. Remy, Analysis of XML schema usage, Proceedings of XML, [7] D. Basci and S. Misra, Complexity metric for XML schema document, Proceedings of the 5th International Workshop on SOA and Web Practices, [8] L. C. Briand, S. Morasca, and V. R. Basily, Property based software engineering measurement, IEEE Transactions on Software Engineering, Vol. 22, [9] E. van der Vlist, XML Schema, O Reilly Publication, Sebastopol, [10] T.J. McCabe and C.W. Butler. Design complexity measurement and testing. Communications of the ACM, 32: , 1989.