About Lattix, a CodeClinic company
We focus on architecture. We are the leading global provider of software and systems architecture analysis solutions. We deliver the ability to visualize, analyze, monitor, and control your architecture. Our solution is built to work seamlessly with the products you currently use in product development including source code repositories, modeling tools, static analysis solutions, requirements management solutions and testing solutions. We have over 1200 customers in 30 countries focusing on safety-critical industries such as automotive, aerospace/defense, and medical devices. Lattix is known for product excellence, prompt and personal support, and creating solutions that accelerate our customer’s revenue, minimize cost and improve quality.
Email us at sales@lattix.com
Lattix
352 Park St, Suite 104
North Reading, MA 01864
+1 (978) 775-2484
Lattix United Kingdom
Bath, UK
+44(0)1225 694387
Lattix Europe
Munich, Germany
+49(0)89 2080 45427
CONTACT US
FREQUENTLY ANSWERED QUESTIONS
This is because you have a standard evaluation download from the web which does not include those plugins. In order to get the plugins for Spring and Hibernate please contact Lattix and you can get a download which includes those plugins.
In order to create a project for Spring, load in the Spring xml files in the New Project Dialog. This creates a project which shows you the dependencies between Spring beans and between classes.
In order to create a project for Hibernate, load in the Hibernate configuration file or Hibernate xml files in the New Project Dialog. Hibernate generates a mapping between java classes and database tables. In a multi-module project with java, Hibernate, and Oracle you can see a model which shows the dependencies not just between elements of the application and elements of the database but also between application and database.
Expand a large class into its methods and data members. Now partition the class. The partitioning will suggest an inheritance hierarchy. Look for virtual partitions which are independent of each other, there may be other ways to split the class as well.
Yes. When Java Server Pages are compiled, you get Java classes. These Java classes can be analyzed using the Java module.
A Java Server Page (JSP) looks like a mixture of html and Java. The web server compiles a JSP the first time it is invoked. Internally, this is a two phase process. First the Jasper compiler is called which produces Java source code, and then the Java compiler is invoked on the source code to generate the Java class. For purposes of analysis, we need to pre-compile the JSPs. On the steps for doing this, please read the description of the JSP Analyzer under Additional Tools. JSPs can also have ‘include’ and ‘forward’ source level dependencies between each other. The JSP Analyzer in Additional Tools will extract those dependencies.
You can do this in two ways:
- You can create a new project with member level enabled and you will see dependencies at a finer granularity of methods and data members. Note that once a project is created, you can see the members for a subsystem by selecting it (select $root to do this for the entire project), right click and select Expand Members. The members for the selected subsystem are then shown in the DSM.
- If you already have a project which doesn’t have member level enabled, you can simply select a subsystem, right click and select Expand Members. The dialog box then allows you to update the entire project for member level or just the selected subsystem. It then prompts you to do a Project Update. You will then see members in the DSM.
Here are a couple of ways of doing it:
When you create a Project, simply go to the Options tab and specify the pattern to exclude certain classes. Note that the pattern is specified in Java stye regular expressions, (which is the same as perl style regular expression). Example:
- To exclude all classes that contain the name test specify the pattern .*test.*.
- To exclude all classes that contain the strings test and Test specify the pattern .*[Tt]est.*.
- To exclude all classes with a package com.package. specify the pattern com.package\..*.
Here is a more sophisticated way of dealing with this issue.
- Load all the classes.
- In Search/Tags pane specify a search string such as test to identify all classes that have test in their name.
- In the Search Result, select $root, right click and select the menu item Cut Branch.
- Create a Test subsystem under $root. Paste the classes you just cut into that subsystem. This will move all your test classes into the Test subsystem.
Why is this more powerful? It allows you to see if there are any dependencies on tests from your regular code. It allows you to see how your tests depend on each other. It allows you to see what tests should be rerun if you change something in your code. Of course, if none of this matters, you can then always delete or hide the test subsystem thereby removing tests from the model.
Create a project for the first time using the New Project Wizard with the option Create Subsystem for Input File not selected. You will see the partitions by package. Click on a subsystem corresponding to the package of interest and you will see all dependencies of the package in the Usage tab.
Once you create a subsystem corresponding to the jar file, you can see all dependencies associated with the jar file just as any other subsystem. Click on the row or column header for the subsystem and you will see all its dependencies in the Usage tab.
When you create a project for the first time using the New Project Dialog, remember to ensure that the option Create Subsystem for Input File is selected. As a result, you will see a partition being created for each of the input jar files. You will now be able to see the dependencies between jar files and drill down.
If you experience this problem, it may be related to the interaction between the display hardware on your PC and the Java runtime. Here is a solution that has been reported by a user of Lattix:
- Bring up Display Properties Dialog.
- Select the Settings tab.
- Click on the Advanced button.
- Select the Troubleshoot tab.
- Turn off the Enable write combining. Alternatively, you can also move the Hardware Acceleration slider to “None”.
Your Linux systems may not have the correct fonts. This can happen because you are using a different JDK from the one that comes from Sun. Change the look and feel from “Metal” to the default. This should fix the problem.
In the shell script lattixarchitect.sh, which is in the Lattix bin directory, change the line:
$JAVA_HOME/bin/java -Xmx999m -Dswing.systemlaf=javax.swing.metal.MetalLookAndFeel -cp "$FULL_CLASSPATH" com.lattix.application.cmds.LattixArchitect $*
to
$JAVA_HOME/bin/java -Xmx999m -cp "$FULL_CLASSPATH" com.lattix.application.cmds.LattixArchitect $*
Verify that the License Manager is up and running. Then ensure that there are no firewalls that are preventing the connection request from being sent to the License Manager.
Here are a few things to try:
-
-
- Try bringing up Lattix by running the batch file “lattixarchitect.bat” in the Lattix bin directory.
- If the error message suggests that you are running out of Java heap space, you can also try running “lattixarchitect.exe” with the argument “lattixarchitect.exe -Xmx1024m“.
-
Please contact us if you are not able to start up for any reason.
Typically this happens when you first run Lattix as a user with admin privileges, and then run as regular user. The problem is that the license files are no longer accessible. Follow these steps to clear the license files:
-
-
- Delete the file “architect.lic” in the config directory where you have installed Lattix (typically, c:\Program Files\Lattix9.4\config). Note that you may have to alter the directory to match your installation. Do nothing if there is no such file in the directory.
- Delete the directory c:\Users\your-name\.lattix. The “.lattix” directory contains license and config information that Lattix generates when it runs.
-
Now start Lattix as a regular user and specify the License File. Please make sure that the license file on your file system is readable. If for any reason the file is not readable or you see an error message, copy the contents of the file and paste them as text directly into the Key text area of the License Dialog box. This bypasses having to read the license file.
Lattix applications can grow in size over time based on use. However, we take pains to reclaim the memory that is no longer in use. This is done by freeing the memory and letting the Java garbage collector reclaim it. This can create a time gap between when memory is unused and when it is freed.
However, there is another important issue that can be misleading. Sometimes users look at memory usage in Windows Task Manager. It can show a lot of memory used by the Lattix Architect process even when the project that was loaded is closed. Note that this does not imply that there is a memory leak. This just reflects a large virtual size of the application when the project was loaded and does not reflect the what the current size of the application is.
Nevertheless, this is an important issue for us. We have fixed memory leaks in the past and so we are always interested in learning of scenarios where you may have experienced this problem. Please contact us if you think that you are running into a memory leak.
This error results from lack of sufficient heap memory. The virtual machine produces this message when the garbage collector is called too often because memory is running low. Increase the heap memory to resolve this problem. You can also turn off the Atom Database to reduce the memory footprint.
By default, Lattix tries to create a heap size of 1GB for 32-bit systems and a size based on the actual memory for 64-bit systems. On some systems, based on actual memory organization, the default heap size is not set correctly. You can check the max heap size and the heap size used on your system by bring up the About box from Help→About.
Note that 32-bit applications are always limited to about 1GB of heap space regardless of how much physical memory you have on your computer. You can change the heap size that is used by Lattix by using the ‘-Xmxnumber‘ argument to either lattixarchitect.exe/lattixarchitect.bat/lattixarchitect.sh or to any of the other programs. If you are running Lattix Architect from the Windows shortcut, bring up the Properties dialog and append the heap size argument to the Target.
For instance:
lattixarchitect.exe -Xmx12g will allocate a maximum of 12 GB of heap for Lattix Architect. ldcupdate.exe -Xmx8g will allocate a maximum of 8 GB of heap for ldcupdate.
Mac
The Info.plist file in the Lattix application package controls how the heap allocated when JVM is started. This steps shown here will start Lattix with 4 GB of heap memory. Please adjust according to your usage, while not specifying heap size larger than the physical memory on your system.
-
- In finder, select “Applications” on left.
- Search for Lattix in top right and find the “Lattix” application.
- Option-click (or right mouse click) on Lattix Architect application and select “Show Package Contents”.
- Expand “Contents” to view “Info.plist” file. Open file (using xcode or other editor).
- Add “string” argument to “JVMOptions”: -Xmx4g
- Expand “Contents/MacOS” in finder and double click on “JavaAppLauncher”
Follow these steps to move Lattix Web from one host to another:
-
-
- Stop the Lattix Web Repository Service. On Windows, you can do that from the Services panel: Control Panel\System and Security\Administrative Tools
- Backup the repository data directory. In Windows, the default location of the directory is: C:\LattixRepository
- Restore the repository data directory on the new host
- Install Lattix Web on the new host. Specify the new repository data directory during installation.
- Verify by connecting to the new repository using your browser. For example: http://hostname:8080/LattixWeb
- Install the new license from Admin→License
-
Remember to let repository users know what the new host name and port number are.
No, you will not lose your data. When you install Lattix Web you specify the directory where the repository is located. Note that when you uninstall Lattix Web, the repository is left intact. Simply uninstall the older version of Lattix Web, install the new version, and specify the same directory for the repository.
You do not need to uninstall the older version of Lattix applications. In fact, you can have multiple versions of Lattix on your computer. Note that projects created on later versions of Lattix may not always be loadable on older versions.
You must uninstall Lattix Web prior to installing a new version of Lattix Web.
Sometimes, the error reports the Lattix application as “damaged”. Generally, this problem occurs with older versions of OS X. Lattix has been tested on OS X 8.4 and higher. However, you should still be able to run Lattix using the shell script.
- Open a Terminal Window
- Run /Applications/Lattix9.4.1.app/Contents/Resources/Java/bin/lattixarchitect.sh. (Please adjust “9.4.1” with the version of Lattix that you are trying to run).
Since Lattix installers for Windows and Macs include Java, you don’t need to install Java to run Lattix on Windows and Macs. For other platforms or if you are not using the installer on Windows and Macs you need to install Java. Lattix can run on the following versions of Java:
- Windows: 1.8+
- Mac: Java 1.8+
- Linux: OpenJDK 1.8+ or Java 1.8+
Follow the steps in the Installation Manual. It also describes how to install the web repository and application on different platforms.
You can specify a property called “sourcefile” to an Atom and a property called “linenumber” to an Atom or a Dependency. You specify the editor of your choice through View→Preferences→External Viewer Configuration. You can then View Source for an Atom or a Dependency directly from Lattix.
LDI projects are created by loading in “.ldi.xml” files. You can get examples of the ldi.xml file format in our customer portal (cp.lattix.com). Excel projects are created by loading in “.xls” or “.xlsx” files.
A subtle difference arises because Lattix provides full round trip support for two different ways of using Lattix. The two ways of loading information from LDI/Excel are based on your style of usage.
-
-
- Usage Mode: Excel is the master source where information is maintained through the New Project Dialog (File→New Project). You cannot edit or remove dependencies in Lattix. You must change the spreadsheet and Update (Project→Project Update) your Lattix project. You can, however, always hide subsystems or dependencies to remove them from the Lattix model.
- Usage Mode: Lattix is the master source where information is maintained (Excel is used for loading the data initially) through Import (File→Import). Once you load in the Excel spreadsheet, you can add/remove/modify the atoms or dependencies. However, you cannot “Update” an imported project with a different (or newer version of) the spreadsheet.
-
Note that there is a script (Export to LDI/Excel) that allows you to export any model to Excel. This means that even if you imported and modified your model in Lattix, you can always export it back to Excel. Therefore, you can always switch between the two usage modes.
The Excel module allows you to create projects from Excel files. Both xls and xlsx types are supported. Historically, Excel was used for creating and analyzing DSMs. Lattix supports the original MIT Excel format. However, Lattix also supports a columnar format for specifying data. The Columnar format is particularly useful for collecting data. Here is a short (2 minute) video on using Excel with Lattix: https://www.youtube.com/watch?v=pSQ0ZV-s3GM&t=
LDI (Lattix Data Import) module allows you to create Lattix projects from XML files. LDI is a module that allows users to specify their own atoms and dependencies. LDI is typically used for:
-
- Analyzing your own system, for which Lattix does not provide a parser.
- Establishing dependencies between modules that are of different types. For instance, if there are dependencies between your Java code and the Database, then LDI can be used to specify those dependencies.
The merge order determines how the atoms will be merged. In this case the ultimate picture we want is the dependence of the Java application on the Oracle database. The Java module provides the Java atoms (class, interface, method, data member etc); and the Oracle module provides the Oracle atoms (schema, table, stored procedure, tigger etc). However, the Hibernate module provides atoms which are both Java and Oracle atoms such as Java classes and their related Oracle tables. Therefore, the merge order would be to put Hibernate at the end so that the Java atoms from Hibernate module would be merged with Java atoms from the Java module, and the Oracle elements from the Hibernate module would be merged with Oracle elements from the Oracle module.