Complexity metrics for coupling/complectedness/entanglement

[Phil Booth]

So I've started to think [1] about ways to measure possible indicators of coupling between objects/modules in JS. My initial ideas, both quite crude, are to analyse calls to the CommonJS and AMD `require` functions and to check for access to properties that are (possibly indirectly) rooted in the global object.

I haven't got any further than that so far, just wanted to check if anyone else has thoughts about it or is working / has worked on this topic themselves. Anyone?

[1] https://github.com/philbooth/complexityReport.js/issues/20

[Patrick Mueller]

I would be surprised to find many folks are plopping stuff on the global object, when using modules.

Anyway, if you didn't realize it, you can in theory do some analysis of which modules require which other modules, in node, using the module.children and module.parent properties [1].  I don't remember exactly why, but the last time I played with these, I didn't get all the information I was expecting.  Maybe it was built-in modules didn't get reported or something?

[1] http://nodejs.org/api/modules.html#modules_the_module_object

--
Patrick Mueller
http://muellerware.org

[Phil Booth]

Thanks for those `module` properties, I was unfamiliar with them.

A bit more context though, as I realise my last message was rather terse. This is a static analysis gig, I'm walking ASTs from Esprima and would like to cater for node, browser and the various browser build environments (browserify and so on). So the mechanics of measurement are not tricky, in and of themselves, rather I'm trying to figure out what things I should be trying to measure. I'm relying on syntax trees, not runtime information.

Ultimately, it's about recognisng the importing of "foreign" symbols into a module, in any way that different JS platforms may permit that to happen. It wasn't clear to me before but it is more so now, I have `require` and platform-flavoured global but not much else, right? If I can analyse those two correctly, hopefully I have a reasonable idea about module dependencies inside of a static checker...?

--
--
http://clausreinke.github.com/js-tools/resources.html - tool information
http://groups.google.com/group/js-tools - mailing list information
 
---
You received this message because you are subscribed to the Google Groups "js-tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to js-tools+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Zach Carter]

Although not strictly JavaScript related, you'll probably find useful information in this paper: http://almossawi.com/firefox/prose/

[Cheney, Edward A SFC MIL USA FORSCOM]

UNCLASSIFIED
Phil,

I would not imagine there is any additional complexity, at least as far as code analysis, that is not already measured by cyclomatic complexity. The challenge in this case is how to perform the analysis upon module code that likely resides in different files. Although there is likely no difference in complexity analysis there may be some amount of trivial performance degradation if there are two many large modules imported into a single project due to perceived lag of IO operations on initial compilation since modern JS is dynamically compiled on load opposed to many other languages that are statically compiled.

Also, any modules not optimized for compilation could dramatically slow execution of a major portion of your application and possibly without regard to depth of scope where the module is included.

Austin

On 07/25/13, Phil Booth
wrote:

> So I've started to think [1] about ways to measure possible indicators of coupling between objects/modules in JS. My initial ideas, both quite crude, are to analyse calls to the CommonJS and AMD `require` functions and to check for access to properties that are (possibly indirectly) rooted in the global object.
>
> I haven't got any further than that so far, just wanted to check if anyone else has thoughts about it or is working / has worked on this topic themselves. Anyone?
>
>
> [1] https://github.com/philbooth/complexityReport.js/issues/20
>
>
>
>
>

> --
> --
> http://clausreinke.github.com/js-tools/resources.html(blockedhttp://clausreinke.github.com/js-tools/resources.html) - tool information
> http://groups.google.com/group/js-tools(blockedhttp://groups.google.com/group/js-tools) - mailing list information

>
> ---
> You received this message because you are subscribed to the Google Groups "js-tools" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to js-tools+u...@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out(blockedhttps://groups.google.com/groups/opt_out).
UNCLASSIFIED

[Phil Booth]

Thanks Zach, that is an exceptionally good write up. First-order density is definitely something I am going to measure now, and I'll also have a look into propagation cost although that may be a little bit trickier.

Those visualizations are brilliant too. Glad to have found those now, purely as a user!

--
--
http://clausreinke.github.com/js-tools/resources.html - tool information

http://groups.google.com/group/js-tools - mailing list information

 
---
You received this message because you are subscribed to the Google Groups "js-tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to js-tools+u...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Phil Booth]

Just in case anyone else is interested, I've now finished implementing these entanglement metrics in complexity-report [1].

Briefly, the approach I took was to statically analyse calls to CommonJS and AMD require within a project and then construct design structure matrices (DSMs). From those DSMs, three metrics are calculated:

* first-order density, the percentage of all possible internal dependencies that are actually realised in the project;

* change cost, the percentage of modules affected, on average, when one module in the project is changed;

* core size, the percentage of modules that are both widely depended on and themselves depend on other modules.

If you're interested in the research behind these metrics, there are two excellent papers at [2] and [3], which are referenced by the Firefox complexity analysis [4] that Zach pointed me at elsewhere in this thread (thanks again for that btw).

Cheers,

Phil.

[1] https://github.com/philbooth/complexity-report

[2] http://sdm.mit.edu/docs/akaikine_thesis.pdf

[3] http://www.people.hbs.edu/cbaldwin/DR2/MRBDesignStructure17thSep1.pdf

[4] http://almossawi.com/firefox/prose