代码之家 › 专栏 › 技术社区 › bethlakshmi

您如何衡量/估计XML编程工作量的大小?

estimation java-ee xml

8

bethlakshmi · 技术社区 · 16 年前

为了设定场景,我在一个喜欢估计和跟踪几乎所有事情的行业工作。我们的一个关键指标是SLOC(源代码行-声明性和可执行语句)。我们将其用于项目规模和成本估算、项目规划和许多其他事情。我们试图用它来比较苹果(即,我们不会将一种语言/领域中的SLOC与另一种语言或领域中的SlotC进行比较)。笔记 :我们不会根据这个指标来评估单个开发人员,也不会仅仅因为SLOC与预期不同而称之为错误或糟糕。我们做然而,考虑到一个项目有更多的SLOC,也可能有更多的bug。

最近,我开始从事使用库来代替手工编码的组件的项目,例如JSF而不是JSP,Hibernate而不是JDBC等。因此,我们的团队正在开发XML文件,而不是编写代码行。XML映射仍然需要付出努力,而且复杂性之间仍然存在模糊的相关性——在给定的项目中,这些XML配置文件的数量增加了100倍,这可能意味着创建这些文件需要付出更多的努力,调试起来也可能比只有1/100个XML文件的项目更复杂。

那么……有人对测量这些XML配置文件的大小有什么建议吗?元素数量?#元素+#属性?还有别的吗?

3 回复 | 直到 16 年前

1

3

Brian B. 16 年前

有趣的问题。我所知道的唯一指标(除了像你建议的那样只计算节点和属性)是结构化文档复杂性指标。

http://www.oreillynet.com/xml/blog/2006/05/metrics_for_xml_projects_5_str_1.html

这是我目前能找到的最好的链接(已经有一段时间了)。我还发现了这个小工具,它显然会为你计算(可能还有其他工具):

http://schematron.com/resources/documentcomplexitymetric.html

除此之外,恐怕我唯一的建议是选择几个看似合理的指标进行跟踪,并重新评估它们,以确定它们是否真的与应用于每个文档的努力有关。..

2

0

EBGreen 16 年前

首先,让我说,根据这样的标准评估一个项目和根据同样的标准评估程序员一样愚蠢。我知道有研究表明,代码行数和代码缺陷数之间存在明显的相关性。在我看来,这只是一个规模扩大的问题。

话虽如此,如果你的领主。..呃。..我的意思是管理层要求你想出一些东西——这里有一些相对容易的衡量标准:

节点总数
节点类型数量
每个节点的平均属性
最大程度的筑巢

3

0

matt_dev 16 年前

好吧,如果您只是根据基本的SOAP/WSDL操作、消息和类型将模式映射到结构,那么您可能只需将这些方面中的每一个与其各自的方法、消息和类等同起来。

例如。..客户模式如下:

  <?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:tns="http://tempuri.org" 
           targetNamespace="http://tempuri.org"
           xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="Customer">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="FirstName" type="xs:string" />
        <xs:element name="LastName" type="tns:LastNameType" />
      </xs:sequence>
      <xs:attribute name="CustID" type="xs:positiveInteger"
                    use="required" />
    </xs:complexType>
  </xs:element>
  <xs:simpleType name="LastNameType">
    <xs:restriction base="xs:string">
      <xs:maxLength value="20"/>
    </xs:restriction>
  </xs:simpleType>
</xs:schema>

…相当于客户类别。..

public class Customer
{
    public string FirstName{}
    public string LastName{get;set;}
    etc...
}

这样,您就可以在相对规模上继续使用当前的SLOC基准测试。

这样做的问题是,编写XML模式并不像编写Java或C#程序那样真正允许LOC的巨大变化。程序员可以用一百万种不同的方式编写C#类,其中模式定义的结构化程度要高得多,并且只允许操作、消息和变量名的长度变化。因此,如果你现在只是编写XML而不是Java或C#,那么你可能想考虑一下,在确定项目规模和bug方面,你的SLOC指标将比以前少得多。