Release 1#
Automated DSM Creation#
Given a set of binaries for a Java application, Lattix LDM will parse those binaries and produce a Design Structure Matrix for the given Java application. A Design Structure Matrix is a square matrix (or grid) that shows dependencies between classes, packages and subsystems by showing a mark (an “X- or a number) in the cell where the two classes/packages/subsystems intersect. Please see the Lattix Whitepaper, “DSM for Software Architecture-, or the DSM website, http://www.dsmweb.org.
DSM and System Structure Editing#
Lattix LDM allows you to save your application’s DSM in a project file (*.ldz or *.ldm). Once saved, you can manipulate the visible structure of your application, while maintaining all of the correct dependency information. In this way, you can make the DSM more resemble your concept of the architecture of your system. Alternatively, you can use this feature to create “what-if- versions of your architecture as a potential blueprint for future re-factoring.
Editing operations include actions such as create and rename subsystem and subsystem cut and paste, and all have undo/redo capabilities to allow easy experimentation.
DSM Partitioning#
The Analysis capabilities of Lattix LDM include DSM partitioning. This capability allows you to use the existing dependencies to algorithmically calculate the best sub-systems for a given system. Frequently, new insights can be gained about a system by performing this type of analysis.
Design Rule Creation#
Once the DSM is created, and system restructuring is complete, i.e. Discovery and Analysis is complete, you can then begin to create design rules. Lattix LDM allows you to specify CANNOT-USE and CAN-USE rules between the elements of your system. For instance, you can say that Package1 CANNOT-USE Package2. Additionally, Design rules are inherited from parent subsystems. So, if you had Jar1 and Jar2, and specified that Jar1 CANNOT-USE Jar2, then Jar1.Package1 would inherit the CANNOT-USE file for packages like Jar2.package2.
Design rules are a powerful and unique method to represent your Design Intent for your application. They allow you to codify common sense rules such as “DB layers cannot call UI layers-, as well as more complex or less obvious rules for your system in such a way the implementers of the system have a blueprint to follow during implementation. With each rule, you also have the ability to add a description for a rule, its architectural intent, and any other textual information about a given design rule.
Additionally, Lattix LDM provides a view where allowed and disallowed dependencies are clearly shown in the DSM grid.
Software Subsystem Classification#
It is possible to define software subsystem classifications, and assign these to subsystems. Furthermore, it is possible to define criteria by which classifications will automatically be assigned to subsystems that meet the criteria. And finally, these classifications can be used as Source or Target in Design rules.
For example, you could create criteria that any subsystem that uses “java.swing.** or org.eclipse.swt.** or java.awt.** or javax.servlet.http.**- is classified as Presentation subsystem, and then you could create criteria that any subsystem that uses “java.sql.** or javax.jdo.**- is classified as a Persistence subsystem. At which point, a rule could be created
#Persistence Cannot-Use #Presentation
Design Rule Validation#
Once design rules have been created, Lattix LDM can validate your existing implementation and display violation results within the DSM grid.
Also, you can validate design rules during your build process using the command-line application, Lattix LDC. LDC will validate a project’s rules against a new set of binaries and produce a report of the results of the check including lists of any Design Rule Violations.
Mark Changed#
To get a sense of how many other subsystems may be affected by a change to a particular subsystem, Lattix LDM allows the user to mark that particular subsystem, and then Lattix LDM will visually display all of the possible other affected subsystems based on the dependencies on the changed subsystem. This is useful to get a sense of how large the impact could be for a change to that subsystem.
Create Reports in Excel#
For sharing your DSM, and detailed dependency information with others who do not have access to Lattix LDM, Lattix LDM supports the ability report DSM and dependency details to an Excel file (XLS). Additionally, the DSM grid itself can alternatively be exported to a comma separated file (CSV).
Input File Management#
Inside an existing project, besides reading new versions of the original input files, you can also select one of the original input files and specify a new file to replace that original file. This is useful when you have the convention to encode date or revision number in the subsequent versions of input files. So, you can have inputfile1.jar, which is build 1 of a jar, and replace it with inputfile2.jar, which is build 2 of the same development deliverable, inputfile. This allows you to replace inputfile1.jar with inputfile2.jar while maintaining all rules, subsystem decomposition, and other DSM editing changes you may have made to your project.