Lattix Web: Architecture Trends and Insights

Lattix Web Transcript

Back to the Videos page
Watch the video on YouTube


Let’s take a look at how Lattix Web is applied in a development lifecycle.


While projects are in development, changes are taking place every day. Lattix Web can become part of your continuous integration system. We can see if the architecture is eroding as you change your code. Are we introducing violations or are things getting better because we applied a refactoring initiative? We want to measure and quantify that improvement.


We’re now looking at the dashboard of projects. There are two projects: one’s the Ant demo project, which is a Java project; and the other is the IsoAgLib project, which is a C++ project.


Let’s go inside the Ant project. We’re looking at snapshot version 1.9.6. We can choose any of the snapshots in the list. We can also download a snapshot if we want. We can choose to see reports, views, issues, and so on.


The first report we’re looking at is the Systems Metric Delta. We’re doing a diff between version 1.9.6 and version 1.9.4. We can see how the line count has changed, how the number of classes has changed, and the number of interfaces. These are system-level metrics at a top level.


We can go further and look at how the Architecture Metrics have changed. We can see how the Complexity has increased, how the System Cyclicality has changed, and how Intercomponent Cyclicality has changed. We can look at Cycles and see the current cycles. These cycles are organized from top to bottom. Starting at the top level we’re walking through all the different cycles. This one has a large number of cycles. We can look at violations, which we will explore a little later.


We can look at Architectural Changes. We’re looking at how version 1.9.6 differs from version 1.9.4, the two snapshots we’re comparing. We can see what new classes have come in, what new violations have come in, what classes have changed, and what classes no longer exist. If you fixed any violations that number would show up, as well. It turns out no violations were fixed or introduced.


Let’s look at the number of classes that no longer exist. We can see that there used to be a field called INITIAL_SIZE in two different classes, DemuxOutputStream and LineOrientedOutputStream, and those fields no longer exist. There are a number of methods, getNextCharacter, setBeginToken, setEndToken, which no longer exist. And, in fact, there are some classes that no longer exist either. In going from one build to another, you will instantly be able to see what changed.


Let’s bring up a new report and find out the impact of those changes. I can open an impact report, which is organized by levels of import. Let’s make this version 1.9.4. We can see that there are five Impact Report levels, which are the levels of indirection. The left-hand side tells me what changed and the right-hand side tells me the things that depend on the things that changed. You can see from one build to another what changed and, at a deeper level, all the things that could be affected by those changes.


In Lattix Web you can control what reports you choose to show in the default dashboard or you can select different reports to view at any time.


There are some more interesting metrics here. Here is a metric of file sizes. Javadoc happens to be the largest class here with a line count of 2,600 lines. Sometimes we can see classes that are really long and that would be good candidates for splitting up.


Next, we will look at some object-oriented metrics. For those of you who are familiar with or fans of Robert Martin, these are the metrics he originated. A number of these are package-oriented metrics. We can see the number of classes, the number of abstract classes or interfaces, abstractness, incoming dependencies, outgoing dependencies, instability, and distance. If you follow Robert Martin then you know that when the distance is zero or the distance is one, you have an indication of whether these are high-level or low-level packages. And often those are the ones you want to focus on for improvement.


We can also look at trends. We can look at Intercomponent Cyclicality, which is a really nice metric. We’re looking at it over a history of twenty different snapshots, from version 1.5.2 to version 1.9.6. These are the cycles that cross package boundaries, one of the best metrics for object-oriented systems. You can see how the cyclicality jumped up from version 1.5.4 to version 1.6.0 and then went down from 1.6.5 to 1.8.2. And so on.


Let’s look at stability, too. You can see how the stability started out at 76.6% and then ended up at 70% but there were some dips that took place. You can also see how the coupling became worse before it got better.


Notice how these metrics are correlated. As the intercomponent cyclicality improved, the stability increased in the system. That means that when you make a change, fewer things are affected by it. Similarly, you can see how the coupling dropped. On the other hand, where the intercomponent cyclicality became worse, you can see how the stability worsened and how coupling also became worse. This is a way for you to actually evaluate your initiatives. Did a particular release make things better or worse? If you have a refactoring initiative, did it lead to a reduction in the intercomponent cyclicality, did it improve coupling, did it make your system more stable? You’ll be able to answer those and many other questions.


You can also look at violations. Lattix allows you to create architectural rules and when those rules are violated, you can keep count of those violations.


Similarly, you can determine whether your projects, as they become larger, are becoming more complex. Sometimes you may split your projects up into multiple parts to reduce complexity. You can also create bar graphs to view the number of classes and interfaces.


We looked at metrics and we looked at trends. We’ve looked at some reports and we’ve looked at several charts. Now we’ll look at views starting with the DSM view.


This is a really compact view of all of the elements in a project and their relationships. Since we created rules, we can see that architectural violations are flagged. If we wanted to see a particular dependency, we can look at the right-hand panel and see a class called SymbolicLinkUtils, which has a dependency on a class called Execute. SymbolicLinkUtils happens to be the part of a framework and has a dependency on something at an application level. That’s a problem. We can see that there are many different dependencies here that violate the architecture. You’ll be able to see this on your own system as you make it part of your continuous integration process.


We looked at how Lattix Web can be integrated into and made part of your continuous integration system. This information is available to your entire team right from their browser. As your code changes, you can look at how your metrics are being affected and whether the architecture is eroding. You can look at trends and zero in on the exact dependencies that might be causing violations and eroding your architecture.