Как вы измеряете/оцениваете объем усилий по программированию XML?

Чтобы установить сцену - я работаю в одной из тех отраслей, которые любят оценивать и отслеживать практически все. Одна из наших ключевых метрик — SLOC (исходные строки кода — декларативные и исполняемые операторы). Мы используем его для оценки размера и стоимости проекта, планирования проекта и многого другого. Мы пытаемся использовать его для сравнения яблок с яблоками (т. е. мы не сравниваем SLOC на одном языке/домене с SLOC на другом языке/домене). ПРИМЕЧАНИЕ. Мы не оцениваем отдельных разработчиков по этому показателю и не называем что-то неправильным или плохим только потому, что SLOC отличается от ожидаемого. Мы да, однако считаем, что в проекте больше SLOC, а значит, больше ошибок.

Совсем недавно я начал работать над проектами, которые используют библиотеки вместо компонентов, которые в противном случае были бы написаны вручную — например, JSF вместо JSP, Hibernate вместо JDBC и т. д. Итак... вместо написания строк кода , наша команда разрабатывает XML-файлы. Сопоставления XML все еще требуют усилий, и все еще существует нечеткая корреляция сложности — наличие в 100 раз большего количества этих XML-файлов конфигурации в данном проекте может означать, что для создания требуется больше усилий и может быть более сложным для отладки, чем проект с только 1/100 файлов XML.

Итак... есть ли у кого-нибудь предложения по измерению размера этих файлов конфигурации XML? # элементов? # элементы + # атрибуты? что-то другое?


xml estimation jakarta-ee
person bethlakshmi    schedule 28.01.2009    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Интересный вопрос. Единственная метрика, о которой я знаю (помимо подсчета узлов и атрибутов, как вы предлагаете), называется метрикой сложности структурированного документа.

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

Это лучшая ссылка, которую я могу найти в настоящее время (прошло некоторое время). Я также нашел этот небольшой инструмент, который, по-видимому, рассчитает его для вас (могут быть и другие):

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

Помимо этого, я боюсь, что мой единственный совет будет состоять в том, чтобы просто выбрать пару метрик для отслеживания, которые кажутся разумными, и переоценить их, чтобы определить, действительно ли они имеют тенденцию к усилиям, прилагаемым к каждому документу...

person Brian B.    schedule 30.01.2009

arrow_upward
0
arrow_downward

Позвольте мне начать с того, что оценивать проект по таким критериям так же глупо, как оценивать программиста по тому же принципу. Я знаю, что есть исследования, которые показывают, что существует четкая корреляция между количеством строк кода и количеством дефектов кода. На мой взгляд, это просто вопрос увеличения масштаба.

Сказав это, если ваши повелители... ошибаются... Я имею в виду, что руководство требует от вас что-то придумать, вот несколько относительно простых измерений:

  • Общее количество узлов
  • Количество типов узлов
  • Средние атрибуты на узел
  • Наибольший уровень вложенности
person EBGreen    schedule 28.01.2009
comment
Дело не столько в том, что мы требуются, сколько в том, что я не хочу, чтобы усилия по разработке XML-конфигурации остались незамеченными. Теоретически XML-файлы избавляют нас от некоторой степени сложности, но они все равно требуют работы. - person bethlakshmi; 29.01.2009

arrow_upward
0
arrow_downward

Ну, если вы просто сопоставляете схему со структурой с точки зрения ваших основных операций, сообщений и типов 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>

... приравнивается к классу Customer как таковому...

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

Таким образом, вы можете продолжать использовать текущие тесты для SLOC только в относительном масштабе.

Проблема заключается в том, что написание XML-схемы на самом деле не допускает таких больших вариаций LOC, как написание программ на Java или C#. Программист может написать класс C# миллионом различных способов, тогда как определение схемы гораздо более структурировано и позволяет изменять только длину операции, сообщения и имена переменных. Поэтому, если вы сейчас пишете только XML вместо Java или C#, вы можете подумать, что ваша метрика SLOC будет содержать гораздо меньше воды, чем раньше, с точки зрения определения размера проекта и ошибок.

person matt_dev    schedule 28.01.2009
comment
Чтобы было ясно, меня беспокоит не сложность специально разработанных схем. Это повторное использование схем, определенных продуктами с открытым исходным кодом. Сложность схемы отличается от сложности того, как мы ее используем. - person bethlakshmi; 29.01.2009