Can I find out which Class/Dependency causes a violation?

[h3rm...@googlemail.com]

Hi there!

Architecture Rules looks great. I did a testdrive by executing it as
an ant task. But all i get is:

c:\SVN\APFlow\antbuild\build.xml:1028:
com.seventytwomiles.architecturerules.exceptions.DependencyConstraintException:
rule bpm integration tier failed: com.isr.bpm.integration.base is not
allowed to depend upon com.isr.bpm.service.domain

Is there a way to find out what class file causes this violation?

Thanks for any help,
Dirk

[Mike Nereson]

Hi Dirk. Thanks for trying out Architecture Rules.

So far so good. You have a class that depends on a class that it should not be depending upon and has therefor broken one of your rules causing a DependencyConstraintException.

Right now we don't include the class that broke the rule, but it seems like something that we could and should be tracking. I will create a new issue and we'll get that into the next release.

In the mean time, I think if you turned up the logging for com.seventytwomiles.architecturerules, you will see that there is a lot of logging going on and you might be able to determine the class that broke the rule through that.

I hope that helps. Thanks for bringing this to our attention.

~ Mike Nereson
~ 72miles.com

[Mike Nereson]

Issue created here:

    http://code.google.com/p/architecturerules/issues/detail?id=59

If anyone has any additional comments for this particular issue in terms of the requirements or implementation, please comment on the issue.

Cheers.

~ Mike Nereson

[Mykola Nikishov]

h3rm...@googlemail.com writes:

> Architecture Rules looks great.

Hi Dirk! Thank you for your feedback.

> I did a testdrive by executing it as an ant task. But all i get is:

What version of the architecture-rules do you use?

> c:\SVN\APFlow\antbuild\build.xml:1028:
> com.seventytwomiles.architecturerules.exceptions.DependencyConstraintException:
> rule bpm integration tier failed: com.isr.bpm.integration.base is not
> allowed to depend upon com.isr.bpm.service.domain
>
> Is there a way to find out what class file causes this violation?

As I can see its not possible in the version 2.1.1. We have such info
for cycles (see issue
http://code.google.com/p/architecturerules/issues/detail?id=35), but not
for layers .

--
MAN-UANIC

[Mike Nereson]

Mykola said:
 

As I can see its not possible in the version 2.1.1. We have such info
for cycles (see issue http://code.google.com/p/architecturerules/issues/detail?id=35), but not
for layers .

Right, we report that information on the cycles, but not the rules.

The way its coded right now, we only look at packages. I am thinking that once we find that a rule is broken, we might be able to investigate each class in that package and report which classes are importing that package. It's going to require a lot of ugly code, but I think its possible.

[h3rm...@googlemail.com]

Hi Mike and Mykola!

I appreciate your replys. Would be really great if that would be
available in an upcoming
version! Keep on the good work mike. Seems that there is no other
active open source
tool that asserts an architecture.

Greetings from germany,
Dirk

[Mike Nereson]

There are a few other alternatives. I have never used any of them and I think they all have different feature sets. Here is a list that I came up with.

http://72miles.com/architecturerules/alternatives

Thanks for the support.

~ Mike Nereson

[Mykola Nikishov]

"Mike Nereson" <miken...@gmail.com> writes:

> There are a few other alternatives. I have never used any of them and I think they all have
> different feature sets. Here is a list that I came up with.
>
> http://72miles.com/architecturerules/alternatives

Mike, what about these two:
* http://classycle.sourceforge.net/
* http://patterntesting.sourceforge.net/05/whatis.html

I've never used any of them too...

--
MAN-UANIC

[Mike Nereson]

Those tools have some nice features. I might even try one of them out ( :

Here are some examples of automated checks that the PatternTesting framework allows:

• Verify that no calls to any method in our application is allowed to use null,
• Verify that all Avalon components must extend a base AbstractAvalonComponent class,
• Verify that all calls to the database go through a JdbcDataAccess class and that none uses JDBC directly,
• Verify that no System.out.println() are used anywhere (should use the project defined logging facility instead),
• Verify that stateless classes (Thread Safe classes in Avalon terminology, Singleton or "static classes" in other terminologies) are not allowed to set instance variables except at initialisation time,
• Verify that the "control" layer (for exemple for a web application) is only allowed to talk to the "service" layer (implementation of the use cases) and not to the "persistence" layer (for example),
• Verify that any application exception must be a subclass of BusinessException, TechnicalException or CriticalException,
• Verify that the MVC model is applied consistently. For example, verify that any call to the service layer has been through an Action class (if you're using Struts for example),
• Verify that exceptions are only logged at the top level,
• Verify that for any use case, a maximum number of 5 SQL queries to the database is allowed,
• etc...

I'll have to update that alternatives page. Thanks Mykola.

~ Mike Nereson

[Mike Nereson]

Mykola, I wonder if we should use Classcyle instead of JDepend...

Classycle's Analyser analyses the static class and package dependencies in Java applications or libraries. It is especially helpful for finding cyclic dependencies between classes or packages. Classycle is similar to JDepend which does also a dependency analysis but only on the package level.

That would solve the exact problem that started this email thread.

~ Mike Nereson