webMethods Estimation

[ank4acc]

Anyone has any idea----how to calculate the size in webMethods, like for any other programming language we used to have “LOC”(Lines of Code)Mechanism. Here how will we do the size calculation and if possible what are the esssentials steps need to be taken care of?

Regards,

[saurabhm]

You can do that via “Number of Flow Steps” mechanism. Though let me warn you that its not a easy approach.

[cjcable]

You could also check the size of the package by looking at the zip file in the replicate/outbound directory of the IntegrationServer…

[wMusers.Com1 (wMusers.Com)]

I’m not sure that the size of a package is useful as the \pub folder in a package could contain lots of large documents and the Flow services in the package could contain lots of unused services or large blocks of disabled statements.

Metrics like lines of code seldom measure what management is really attempting to get at (well designed, well tested functionality created per person per unit of time).

Mark

[sonam]

If you’ve got UNIX, or Unix shell tools installed, you could try this shell command to estimate LOC for a Flow service:

grep "<MAP MODE=\"STANDALONE\"\|<INVOKE \|<BRANCH \|<LOOP \|<EXIT \|<REPEAT \|<SEQUENCE " flow.xml | grep -v "DISABLED=\"true\""  | wc -l

This command applies to ‘flow.xml’ files under the package ‘ns’ folder. It basically counts each non-disabled FLOW statement as 1 line of code. Each standalone MAP step only counts as 1 LOC, irrespective of the number of connectors between the input and output (i.e. it does not treat each connector as a distinct assignment statement)

Adding '<MAPINVOKE ’ to the grep pattern above counts transformers within MAP steps, and adding '<MAPCOPY ’ counts all explicit connectors (I think…)

DSP and template files would be probably estimated by counting lines in each HTML or DSP file under the ‘pub’ folder. Java services can be estimated by base64-decoding the content of ‘’ within the java.frag files, then line-counting the decoded java fragment.

[Percio_Castro]

Adding to Sonam’s post:

If you run IS on Windows but you’d still like to run the command suggested by Sonam, you can try these utilities: [URL=“http://unxutils.sourceforge.net/”]http://unxutils.sourceforge.net/[/URL]

I use some of the commands frequently (ex. tail, grep, cut, wc) and they work great.

• Percio

[reamon]

I seriously question the value of any LOC type of measurement.

[sonam]

Thanks for adding Percio. Adding info on my preferred Unix-on-Windows environment: it’s cygwin ([url]http://cygwin.com/[/url])

Rob - You could be right.

[saurabhm]

I do, to somewhat degree, agree with Rob/Mark; But with some SEI/CMM Level 4/5 companies/projects you don’t have a choice but to do estimates for every project; “LOC” is the frequently used metric for estimation - and hence people try to extend this for webMethods FLOW services.

I (and am sure many developers) hate when @ certain quality conscious companies/projects, to even make a single line of change you have to go through five different quality process documents.

Thanks to Sonam for suggesting an easier way to calculate number of flow steps unix-script style.

[reamon]

Good points Saurabh. Companies do indeed use LOC as one data point in a larger set of data points to assist in their estimating efforts. I don’t know that I’ll ever agree that LOC is all that useful, though.

I’m reminded of a saying, though I can’t remember who to attribute it to: “Measuring software by counting lines of code is like measuring hardware by weight.” Interesting but not typically useful. I believe there are other estimation techniques that are better predictors.

Anyway, my kudos to Sonam for providing an approach to get the LOC.

[sonam]

Thanks guys.

Here’s another one-liner that calculates “effective LOC” of flow services in an IS instance. To run it, go to the /packages directory, and use ‘find’ with a wildcard pattern to identify the non-WM packages of interest.

This example counts LOCs of flows in all packages beginning with ‘DD…’:

find DD* -name "flow.xml" | xargs -n1 grep "<MAP MODE=\"STANDALONE\"\|<INVOKE \|<BRANCH \|<LOOP \|<EXIT \|<REPEAT \|<SEQUENCE \|<MAPINVOKE \|<MAPCOPY " | grep -v "DISABLED=\"true\""   | wc -l

Note, contrasted with my earlier post, this code counts each transformer (MAPINVOKE) and explicit connector (MAPCOPY) towards the LOC. This is because each transformer is effectively a subroutine invoke, and each explicit connector is an assignment statement.

Precisely counting Java LOC requires a more involved script - it’s easier to count the java.frag files and assume an average LOC per file.
Counting DSPs and HTML templates should be easy - just modify the statement above to search for suitable files and linecount the contents.

[saurabhm]

You can count the Java LOC by counting number of lines in the *.java files under package/code/source

You dont need anything complex as in going to java.frag files or am I missing something here? Remember this is for estimation purposes only!!

[sonam]

Thanks. I missed out on the consolidated Java files under /code/source/.

Just I had a look - there is one problem though with line-counting these files. IS inserts autogenerated code. The main issue is comments - IS recurses down a service’s input/output data structures and adds one comment for each each node. For eg:

                // --- <<B2B-START(updateList)>> ---
                // @subtype unknown
                // @sigtype java 3.5
                // [i] record:0:required packages
                // [i] - field:0:required name
                // [i] - field:0:required enabled
                // [i] - field:0:required loadok
                // [i] field:0:required servers
                // [i] record:1:required in
...

A simple Java service with a complex datastructure would get “bulked-up” by this.

A approximation around this could be using an LOC counting tool, and getting it to exclude comments.

[saurabhm]

And actually, wikipedia entry goes over this in the “Measuring SLOC” section…

There are two major types of SLOC measures: physical SLOC and logical SLOC. Specific definitions of these two measures vary, but the most common definition of physical SLOC is a count of lines in the text of the program’s source code including comment lines. Blanks lines are also included unless the lines of code in a section consists of more than 25% blank lines. In this case blank lines in excess of 25% are not counted toward lines of code.

Logical SLOC measures attempt to measure the number of “statements”, but their specific definitions are tied to specific computer languages (one simple logical SLOC measure for C-like languages is the number of statement-terminating semicolons). It is much easier to create tools that measure physical SLOC, and physical SLOC definitions are easier to explain. However, physical SLOC measures are sensitive to logically irrelevant formatting and style conventions, while logical SLOC is less sensitive to formatting and style conventions. Unfortunately, SLOC measures are often stated without giving their definition, and logical SLOC can often be significantly different from physical SLOC.

Consider this snippet of C code as an example of the ambiguity encountered when determining SLOC:

for (i=0; i<100; ++i) printf(“hello”); /* How many lines of code is this? */

In this example we have:

* 1 Physical Lines of Code LOC
* 2 Logical Line of Code lLOC (for statement and printf statement)
* 1 Comment Line

Depending on the programmer and/or coding standards, the above “line of code” could be, and usually is, written on many separate lines:

for (i=0; i<100; ++i)
{
printf(“hello”);
} /* Now how many lines of code is this? */

In this example we have:

* 4 Physical Lines of Code LOC (Is placing braces work to be estimated?)
* 2 Logical Line of Code lLOC (What about all the work writing non-statement lines?)
* 1 Comment Line (Tools must account for all code and comments regardless of comment placement.)

Even the “logical” and “physical” SLOC values can have a large number of varying definitions. Robert E. Park (while at the Software Engineering Institute) et al. developed a framework for defining SLOC values, to enable people to carefully explain and define the SLOC measure used in a project. For example, most software systems reuse code, and determining which (if any) reused code to include is important when reporting a measure.

[sonam]

That’s a good reference - I read that same Wikipedia entry before posting.

My ‘strip-out comments’ idea is useful for Java services with complex input/outputs as IS seems to recurse down the input/output structures and autogenerate one comment per node.