Features
Code Query Linq (CQLinq)
Code Rule and Code Query over LINQ (CQLinq)
JArchitect lets query the code base over LINQ queries thanks to CQLinq.
For example the following CQLing query matches all public methods that have more than 30 lines of code:
from m in Application.Methods where m.NbLinesOfCode > 30 && m.IsPublic select m
Around 120 default queries and rules are provided when you create a new JArchitect project.
They are easy to read and easy to adapt to your need.
Writing CQLinq queries and constraints is straightforward both because it is LINQ syntax and because JArchitect provides a CQLinq editor which supports:
- code completion / intellisense
- live compile error description
- integrated tooltip documentation
Also, once the query is compiled, it gets executed immediately and its result is well displayed and browsable:
Powerful and elaborated queries and rules can be written with CQLinq, like the following one for example:
// <Name>UI layer shouldn't use directly DB types</Name> warnif count > 0
// UI layer is made of types in Packages using a UI framework let uiTypes = Application.Packages.UsingAny( Projects.WithNameIn("PresentationFramework", "GuiProject1", "GuiProject2", "GuiProject3") ).ChildTypes()
// You can easily customize this line to define what are DB types. let dbTypes = ThirdParty.Projects.WithNameIn("DataProject", "DataProject2", "Hibernate").ChildTypes() .Except(ThirdParty.Types.WithNameIn("DataSet", "DataTable", "DataRow"))
from uiType in uiTypes.UsingAny(dbTypes) let dbTypesUsed = dbTypes.Intersect(uiType.TypesUsed) select new { uiType, dbTypesUsed }
But short CQLinq queries can be written (or even generated) to get some immediate answers to questions about a code base:
-
Is the code layered correctly?
from n in Packages where n.Level == null select n
-
Which methods have been refactored since the last release?
from m in Application.Methods where m.CodeWasChanged() select new { m }
-
Which classes inherit from a particular class?
from t in Types where t.IsClass && t.DeriveFrom ("CBase") select t
-
Which methods create objects of a particular class?
from m in Methods where m.CreateA ("MyPackage.MyClass") select m
-
Which methods assign a particular field?
from m in Methods where m.AssignField("MyPackage.MyClass.m_Field") select m
-
What are the 10 most complex methods?
(from m in Methods orderby m.CyclomaticComplexity select new { m, m.CyclomaticComplexity }).Take(10)
-
Which complex method is not enough commented?
from m in Application.Methods where m.CyclomaticComplexity > 15 && m.PercentageComment < 10 select new { m, m.CyclomaticComplexity, m.PercentageComment }
You can also be warned automatically when a CQLinq query returns a certain result. Such a CQLinq code query is actually a code rule such as:
-
I don’t want that my User Interface layer to depend directly on the DataBase layer:
warnif count > 0 from n in Packages where n.IsUsing("DataLayer") && (n.Name == @"UILayer") select n
-
Static fields should not be named m_XXX (Custom naming conventions):
warnif count > 0 from f in Fields where f.NameLike (@"^m_") && f.IsStatic select f
-
Methods out of MyProject1 and MyProject2 should not have more than 30 lines of code:
warnif count > 0 from m in Application.Assemblies.WithNameNotIn("MyProject1", "MyProject2").ChildMethods() where m.NbLinesOfCode > 30 select new { m, m.NbLinesOfCode }
-
Public methods should not be removed to avoid API breaking changes:
warnif count > 0 from m in codeBase.OlderVersion().Application.Methods where m.IsPublic && m.WasRemoved() select m
Related Documentation::
CQLinq Performance
CQL to CQLinq Conversion
Compare Builds
In software development, products are constantly evolving. Hence, developers and architects must pay attention to modifications in code bases. Modern source code repositories handle incremental development. They can enumerate differences between 2 versions of source code files.
JArchitect can tell you what has been changed between 2 builds but it does more than simple text comparison. It can distinguish between comment change and code change, between what has been added/removed and what has just been modified. With JArchitect, you can see how code metrics are evolving and you know if coupling between components is increasing or not. JArchitect can also continuously check modifications to warn you as soon as a breaking compatibility change appears.
Related Links::
How to avoid regression bugs while adding new features
Ensure the quality of the code that will be developed this year
82 code metrics
There are many ways to measure a code base. The most common way is to count the number of lines of code. This metric gives a rough estimation of the effort that had been put in to develop the code base. It also allows you to obtain a quality level agreement by pinpointing fat methods and classes.
JArchitect counts the number of lines of code. It also comes with 82 other code metrics. Some of them are related to your code organization (the number of classes or Packages, the number of methods declared in a class...), some of them are related to code quality (complexity, percentage of comments, number of parameters, cohesion of classes, stability of Projects...), some of them are related to the structure of code (which types are the most used, depth of inheritance...).
-
12 metrics on application:
NbLinesOfCode,
NbLinesOfComment,
PercentageComment,
NbBCInstructions,
NbProjects,
NbPackages,
NbTypes,
NbMethods,
NbFields,
PercentageCoverage,
NbLinesOfCodeCovered,
NbLinesOfCodeNotCovered
-
18 metrics on projects:
NbLinesOfCode,
NbLinesOfComment,
PercentageComment,
NbBCInstructions,
NbPackages,
NbTypes,
NbMethods,
NbFields,
Project level,
Afferent coupling (Ca),
Efferent coupling (Ce),
Relational Cohesion(H),
Instability (I),
Abstractness (A),
Distance from main sequence (D),
PercentageCoverage,
NbLinesOfCodeCovered,
NbLinesOfCodeNotCovered
-
13 metrics on Packages:
NbLinesOfCode,
NbLinesOfComment,
PercentageComment,
NbBCInstructions,
NbTypes,
NbMethods,
NbFields,
Namespace level,
Afferent coupling at namespace level (NamespaceCa),
Efferent coupling at namespace level (NamespaceCe),
PercentageCoverage,
NbLinesOfCodeCovered,
NbLinesOfCodeNotCovered
-
22 metrics on types:
NbLinesOfCode,
NbLinesOfComment,
PercentageComment,
NbBCInstructions,
NbMethods,
NbFields,
NbInterfacesImplemented,
Type level,
Type rank,
Afferent coupling at type level (TypeCa),
Efferent coupling at type level (TypeCe),
Lack of Cohesion Of Methods (LCOM),
Lack of Cohesion Of Methods Henderson-Sellers (LCOM HS),
Code Source Cyclomatic Complexity,
BC Cyclomatic Complexity (BCCC),
Size of instance,
Association Between Class (ABC)
Number of Children (NOC),
Depth of Inheritance Tree (DIT),
PercentageCoverage,
NbLinesOfCodeCovered,
NbLinesOfCodeNotCovered
-
19 metrics on methods:
NbLinesOfCode,
NbLinesOfComment,
PercentageComment,
NbBCInstructions,
Method level,
Method rank,
Afferent coupling at method level (MethodCa),
Efferent coupling at method level (MethodCe),
Code Source Cyclomatic Complexity,
BC Cyclomatic Complexity (BCCC),
BC Nesting Depth,
NbParameters,
NbVariables,
NbOverloads,
PercentageCoverage,
NbLinesOfCodeCovered,
NbLinesOfCodeNotCovered,
PercentageBranchCoverage
-
2 metrics on fields:
Size of instance,
Afferent coupling at field level (FieldCa)
JArchitect also provides some facilities that will help you to detect metric anomalies and to fix your own thresholds.
The VisualJArchitect UI displays an interactive view of the architecture of your Java applications. Such a view can be tuned according to numerous software metrics and can be saved in a PNG file in order to let you print posters.
Related Links::
How do you count your number of Lines Of Code (LOC) ?
Why is it useful to count the number of Lines Of Code (LOC) ?
Layering, the Level metric and the Discourse of Method
Code metrics on Coupling, Dead Code, Design flaws and Re-engineering
A simple trick to code better and to increase testability
Manage Complexity and Dependencies
It is vital information to know how the elements of a code base depend on each other. As a developer you spend time thinking about how your layers should interact, creating interfaces and events to avoid dependencies between concrete classes.
As the code base grows, more and more time is spent managing and analyzing dependencies. If I refactor this piece of code, what will be the global impact? Is this layer allowed to access directly DB? Will I accidentally freeze the UI thread if my code invokes this method?
JArchitect comes with several facilities that allow the efficient dependency management. In seconds you can know which part of the code will be impacted if you refactor a class, you can be advised if a layer dependency violation has been accidentally created, you can pinpoint precisely which part of the code relies on a particular tier component, you can list methods that can be reached from a given method etc…
Related Links::
Deconstructing Software
Hints on how to componentize existing code
Dependencies and Concerns
Interactive Code Dependencies Graph
All Paths from A to B
Detect Dependency Cycles
The easiest way to keep a code base clean is to avoid dependency cycles between its components. Components are useful to partition a huge amount of code into smaller and understandable pieces. If a dependency cycle involves N components, these N components represent a single super-component. Indeed, the benefits of having N smaller components are lost: any component can be potentially broken by a change in any of the others components, you cannot unit test a component in isolation from the N-1 other ones and finally, all N components must be versioned and deployed all together.
Whether you consider that your components are classes, Packages, Projects or a mix in between, JArchitect detects dependency cycles between them. It can also help you to find the right way to get rid of a particular dependency cycle. Once dependency cycles have been removed, JArchitect can continuously check your code base to warn you as soon as a cycle is accidentally created.
White paper: Control component dependencies
Related Links::
Control component dependencies to gain clean architecture
Keep your code structure clean
Layering, the Level metric and the Discourse of Method
Enforce Immutability and Purity
At runtime, program’s states are instance and static fields’ values. Controlling how/when/why states are changing is one of the most challenging programming task. This becomes incredibly difficult in multi-threaded environment. This is because potential side-effects due to a state change get too complicated to be understood.
Object-Oriented developers get more and more inspired by the functional programming approach where most states are immutable. An object is immutable if its state doesn’t change once it has been created. A method is pure if its execution doesn’t change any field state. Immutable objects and pure methods are two efficient ways to limit unexpected side-effects.
Through some dedicated CQL conditions and rules, JArchitect lets assert immutability and purity on your classes and methods. The best place to start with this feature is to look at the list of default CQL constraint and to read the associated documentation.
Related Links::
Immutable types: understand their benefits and use them
Manage state in a multi-threaded environment
Generate custom reports from your Build Process
JArchitect can analyze source code and Java Projects through JArchitect.Console.exe. Each time it analyzes a code base, JArchitect yields a report that can inform you about the status of your development. You can customize sections shown in the report and you can even provide your own XSL sheet for full customization.
You can also build your own set of CQL constraints that will be checked at each analysis. The report will warn you each time a constraint is violated. This feature makes automatic design and quality regression test a reality.
Related Links::
JArchitect.Console.exe command line options
Diagrams
JArchitect outputs several kind of diagrams
| |
|
Customers
JArchitect accelerate the process of your developement, support and maintenance.
These Cases Studies shows the utility of JArchitect to have a deep view of your architecture, design and implementation.
CQLinq langage provides more flexibility to request code base, so you can customize your analysis and reports .
|
|