rju / architecture-evaluation-tool

Hypergraph static code analysis based on metrics defined by Edward B. Allen (2007); Measuring size, complexity, and coupling of hypergraph abstractions of software: An information-theory approach
5 stars 5 forks source link

Minimal Example #11

Open layornos opened 4 years ago

layornos commented 4 years ago

Is there any minimal example (for java?) which demonstrates the functionality and results?

rju commented 4 years ago

we have a poster on that. http://eprints.uni-kiel.de/34061/1/ssp-poster.pdf However, I could assemble an example rather quickly.

layornos commented 4 years ago

I've startet an analysis on [1], it's running since yesterday evening. And I'm not sure if its stuck or if it is still computing. :D

[1] https://github.com/layornos/Palladio-Analyzer-SimuLizar

rju commented 4 years ago

Here is a small intro (will be improved in future) https://github.com/rju/architecture-evaluation-tool/wiki/How-to-use-the-Architecture-Evaluation-Tool-for-Java-Code

Anyway, Palladio-Analyzer-SimuLizar could have a very large network which will result in long computing times as the O(*) complexity is somewhat high n² or n³. The application can parallelize execution and I set the parameter to 8 in TransformationHypergraphSize. This could be increase if you have more parallel threads in your computer. The key issue is the complexity metric which needs to calculate the size for each sub-hypergraph of each node. Essentially, the more complex your application is the longer the thing runs. Usually it log infos to the Analysis Log View. This could be increased. Also in the Eclipse Progress View you should be able to see activity.

In my thesis the analysis run 1-2 days on certain code generator versions. I later improved performance a bit, but currently it is still slow. Alternatively, you could modularize your project and make therefore the observed-system smaller.

layornos commented 4 years ago

Eclipse is not responding. If it is still stuck tomorrow, I will try the intro. Thanks for your support! :)

layornos commented 4 years ago

The analysis runs for about 19h for the core project. As we wont run the analysis that often, it seems ok.

We've tried to modularize some parts of the core project, but the results are getting worse instead of better (higher complexity and lower cohesion instead of vise versa). Is there any documentation how the hypergraph is built, based on Java code?

Sorry for answering so late, but somehow Corona happened and now is a almost a half year gone...

rju commented 4 years ago

I am currently on holiday (vacation). There was some documentation available. Essentially:

I have a little more in an unpublished paper which is the text that follows here: 4.2 Mapping Java

The Java type system is very complex due to its multi-inheritance feature, enumerations with methods, and abstract classes, inner classes, anonymous classes, etc. In addition dependency injection frameworks, which resolve interfaces to class instances at runtime, cause additional complexity due to further indirection. Therefore, we present a concise description of a mapping of Java classes, interfaces and methods to modules, nodes, and hyperedges.

We distinguish classes in three groups representing the observed system, the infrastructure, and the data types. All classes to be handled as data types are listed data-type- pattern.cfg file and the observed system classes are noted in observed-system.cfg. The remaining classes are considered framework classes. For user’s convenience, both files allow to specify patterns instead of naming every single class.

Data Types. Java defines several primitive types, like int, short, and char, supplemented by data classes, e.g., String, Date, and List. While these are classes, they serve – in context of a source code analysis – the purpose of data types. Therefore, they must be added to the list of data types. The same applies to all classes in the observed system which are used for the data model, e.g., Java persistence API entity beans must be added to the configuration file.

Classes and Interfaces. All classes and interfaces belonging to the observed system are analyzed completely, meaning each class and interface are mapped to a module, all methods are represented by nodes, and data type properties, which are not constants, are mapped to hyperedges.

For classes and interfaces of frameworks and libraries, only those are added which are used in the observed system, and only methods accessed by the observed system are mapped to nodes. All other parts are hidden to the developer and do not contribute to the complexity of the observed system.

The relationships induced by subclassing must also be mapped to the hypergraph. While, the hypergraph is a flat model without inheritance, it must be resolved. This could be done by producing nodes for each inherited method resulting in node duplication. However, developers perceive super method calls more like calls to other classes.

Our mapping distinguishes two kinds of hyperedges, with call edges for method calls, and data edges for access to data type properties. The latter are in fact hyperedges, as they may have more than two participant.

Special Class Types. They are handled like normal classes. However, abstract classes’ abstract methods are handled like method declarations of interfaces. And inner and anonymous classes might contain references to the outer class in form of property access. Such property accesses result in a call edge to a node representing virtual setter method.