Re: Motivation behind the web application viewer (WAVI) project

From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Newsgroups	comp.lang.javascript
Subject	Re: Motivation behind the web application viewer (WAVI) project
Date	2015-02-22 12:40 +0100
Organization	PointedEars Software (PES)
Message-ID	<7965525.oLVIOeD0SW@PointedEars.de> (permalink)
References	<52bd14fc-df31-4274-994a-6549ccf8a7d0@googlegroups.com>

Show all headers | View raw

bakunin95 wrote:
^^^^^^^^^
Please post to Usenet using your real name (and preferably not using the 
borked, spam-injecting, troll-infested Google Groups).

> Web applications pose unique challenges when it comes to understanding and
> maintaining their heterogeneous structures, which often involve complex
> interactions between elements from different languages. Accurate and
> up-to-date documentation is rarely available and this calls for the
> proposal of reverse engineering approaches for the recovery and
> representation of such structures. The proposed blog presents our ongoing
> work on Web Application Viewer (WAVI), a tool able to reverse engineer a
> web application's structure.
> 
> https://blogwavi.wordpress.com/

There are no classes in these languages, and they use dynamic type-checking, 
which is *also* why your class diagrams are wrong.

First of all, they have nothing to do with what class diagrams in UML (2) 
should look like.  For example,

,----------------------------------------------------------.
|                       «JavaScript»                       |
|            react/core/ReactInstanceHandles.js            |   
|----------------------------------------------------------|
| string SEPARATOR:                                        |
| number MAX_TREE_DEPTH:100                                |
|----------------------------------------------------------|
| getFirstCommonAncestorID(oneID,twoID)                    |
| getParentID(id)                                          |
| isAncestorIDOf(ancestorID,destinationID)                 |
| getReactRootIDString(index)                              |
| traverseParentPath(start,stop,cb,arg,skipFirst,skipLast) |
| isBoundary(id,index)                                     |
| isValid(id)                                              |
`----------------------------------------------------------'

should be at least

,----------------------------------------------------------------.
|                    ReactInstanceHandles¹                       |   
|----------------------------------------------------------------|
| +MAX_TREE_DEPTH : number = 100                                 |
| +SEPARATOR : string                                            |
|----------------------------------------------------------------|
| +getFirstCommonAncestorID(oneID, twoID)                        |
| +getParentID(id)                                               |
| +getReactRootIDString(index)                                   |
| +isAncestorIDOf(ancestorID, destinationID)                     |
| +isBoundary(id,index)                                          |
| +isValid(id)                                                   |
| +traverseParentPath(start, stop, cb, arg, skipFirst, skipLast) |
`----------------------------------------------------------------'

From top to bottom:

AFAIK, the text in guillemets (or double less-than and greater-than signs, 
for compatibility) is to indicate either whether the class is an interface, 
is abstract, is a non-abstract class that can be instantiated, or which 
function (like «Controller») a class has in the application framework.  I am 
not aware of a notation in which the programming language features in a 
class diagram; so if you think it is worthwhile to show that, you should 
find another way that does not conflict with UML.  (But consider that 
“JavaScript” is still imprecise.)

Properties and methods should be sorted by visibility, then by identifier, 
each to ease finding them in the diagram; source code order has to be 
irrelevant.  Therefore, the type, if any, (and initial value, if a 
property), *follows* the identifier.  Property and method visibility should 
be indicated by prefixes to the identifier (here: “+” for public).

Further differentiation whether a property or method is inherited or not (a 
distinction that does not exist in class-based inheritance, therefore not a 
notation defined in standard UML class diagrams, AFAIK) would be agreeable.

Using space to separate formal parameters in parameter lists increases 
readability (in code as well as diagrams).  You do not have to specify the 
entire parameter list: you can use ellipsis (“…”), or three dots for 
compatibility, to show that it is too long for the diagram, therefore 
incompletely represented.  [That said, functions and methods with more than 
a handful of formal parameters each are usually a design mistake; functions 
and methods can be passed an argument of an object type whose properties 
provide the values instead, so that parameter order is no longer and issue.]

Also, it is wrong to count local variables as properties per se:

,------------------------------------.
|            «JavaScript»            |
|     react/utils/PooledClass.js     |
|------------------------------------|
| number DEFAULT_POOL_SIZE: 10       |
| var DEFAULT_POOLER                 |
|------------------------------------|
| fiveArgumentPooler(a1,a2,a3,a4,a5) |
| […]                                |
`------------------------------------'

should be at least:

,-------------------------------------.
|            PooledClass¹             |
|-------------------------------------|
| +DEFAULT_POOL_SIZE : number = 10    |
| -DEFAULT_POOLER : number            |
|-------------------------------------|
| +addPoolingTo(CopyConstructor)      |
| […]                                 |
`-------------------------------------'

First of all, “var” is _not_ a type such as “string”.  Variables and 
properties in ECMAScript implementations, except that of the Edition 4 draft 
if you declare their type, do not have a specific type at compile time 
(which is when code analyzers run) except when they are explicitly 
initialized with a literal that has no references in it.  The languages in 
question use dynamic type-checking (sometimes mislabeled “loose typing”), 
which means that the type of a variable or property is determined *at 
runtime from the current value* (if there never was an explicit assignment, 
the variable’s value is “undefined”, the sole value of the Undefined type).

Now, you *could* assume that the first value explicitly assigned to a 
variable or property is its type (and usually that is done by code 
analyzers), but it does not mean that it cannot assume a value of a 
different type.  If necessary, implicit type conversion is performed in 
operations, and property setters can modify the type of a value assigned to 
a property if the assigned value’s type does not fit the data model.

Second, you *could* consider a local variable a *private* property (hence 
the leading “-” here) *iff* there was a publicly accessible method that 
accessed it.  Such a method would be considered “privileged” because only it 
has access to that variable as a closure via the scope chain.  On the other 
hand, local variables are never visible to the caller; they are an 
implementation detail that does not usually feature in class diagrams.  
There should be at least an option in the generator that needs to be enabled 
explicitly for them to be displayed at all.

Third, there are inconsistencies like

| string PREVENT_DURATION:string
| string tapping:false

This should be at least

| +PREVENT_DURATION : string
| +tapping : string = false

but you can see that this is still wrong because the type specification and 
the assigned value does not match (the type of “false” is boolean, not 
string), which is because of dynamic type-checking.  Either you need to 
decide which value is the one that determines the type of the property (I 
suggest the first one, but that is _not_ necessarily in source code order), 
or if there are multiple possibilities you can list each detected type, or 
you need to omit the type specification.

This description of mistakes is not meant to be exhaustive.  While I 
understand your motivation and commend your efforts, I must strongly 
recommend that you read the FAQ and the references therein, and this 
newsgroup, and learn the language*s* from the ground up; then carefully read 
<https://en.wikipedia.org/wiki/Class_diagram> and the references therein, 
and start over.  I find it highly unlikely that the diagrams as they are 
generated now could be useful to anyone.

_______
¹ These are educated guesses; it is not obvious whether the filename has
  anything to do with a custom object type defined in the file; it could
  (although usually should not) just be a collection of global variables
  with global functions.  There is no built-in concept of namespaces in
  these languages.
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail

Thread

Motivation behind the web application viewer (WAVI) project bakunin95 <jocl06@hotmail.com> - 2015-02-21 16:56 -0800
  Re: Motivation behind the web application viewer (WAVI) project Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-22 12:40 +0100
    Re: Motivation behind the web application viewer (WAVI) project bakunin95 <jocl06@hotmail.com> - 2015-02-22 06:37 -0800
      Re: Motivation behind the web application viewer (WAVI) project Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-22 19:29 +0100
        Re: Motivation behind the web application viewer (WAVI) project John Harris <niam@jghnorth.org.uk.invalid> - 2015-02-23 10:20 +0000
          Re: Motivation behind the web application viewer (WAVI) project Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-23 15:17 +0100
            Re: Motivation behind the web application viewer (WAVI) project John Harris <niam@jghnorth.org.uk.invalid> - 2015-02-24 09:58 +0000
              Re: Motivation behind the web application viewer (WAVI) project Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-26 11:29 +0100
                Re: Motivation behind the web application viewer (WAVI) project John Harris <niam@jghnorth.org.uk.invalid> - 2015-02-26 19:26 +0000
                Re: Motivation behind the web application viewer (WAVI) project Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-27 05:48 +0100
                Re: Motivation behind the web application viewer (WAVI) project John Harris <niam@jghnorth.org.uk.invalid> - 2015-02-27 10:26 +0000

csiph-web