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