This page is a good starting point for understanding Lattix products and services. Note, however, that this is only a partial list of white papers and articles. Comprehensive documentation is available in the Lattix Customer Portal at http://cp.lattix.com. Access to the Lattix Customer Portal is provided to customers and evaluators of Lattix products.
Lattix White Papers
We explore MySQL’s code to discover its various components and to understand how they relate to each other. Using Lattix Architect we will identify all code elements such as methods, structs, classes, and global variables and discover the dependencies among them.
How should we analyze an application that might consist of hundreds of executables and libraries, derived from thousands of source and header files? As developers we want to understand which source files are used to derive each binary and how those files depend on each other. In addition, we need to understand the dependencies between the binaries and map those dependencies down to the source. This is proper dependency analysis of C/C++ code. Armed with this information we can validate the architecture, compute metrics, discover unnecessary unused headers, and perform automated checks.
CMMI is process improvement framework commonly applied to software development. It is a response to the crisis in software development that commonly manifests in failed or poor quality projects. A well-defined architecture is one of the fundamental tools for controlling complexity and maintaining quality. Therefore, a CMMI focus on processes which are relevant to architecture can be an effective technique to improve and maintain the quality of our complex code bases.
Maintaining legacy applications is a difficult problem that most long running businesses will eventually confront. Since the business environment is always changing, there is continual pressure to support new requirements and to fix existing bugs. However, changing these applications is hard.
Let’s suppose that you have a mission critical monolithic application that supports a wide range of functions. Every time you make a change, the possibility of an unexpected error creates a risk to the entire enterprise even when the change is small and needed only by small number of users. Microservices architecture breaks up your monolithic applications into a set of services, each of which is easier to understand, maintain, and test. The idea is hardly new. Modularizing a complex system into components is the natural way we deal with complexity.
The stability of software system is a measure of how much of the system is affected when an incremental change is made. A system that is less stable is generally a fragile system that breaks easily when a small change is made. As a result, a system with lower stability is often harder to maintain because every change requires greater testing and validation. As a result, a system with lower stability is also likely to be buggy or error prone. By contrast, systems with higher stability are robust, changes are often localized, and they are easy for developers to understand.
A study by National Institute of Standards and Technology (NIST) in 2002 estimated that software quality problems cost the US economy about $60 billion per year. A more recent study by Cambridge University in 2013 found that software bugs cost the world economy $312 billion per year. Companies building complex software-centric systems have responded to these challenges in a variety of ways, such as improved requirements gathering, continuous integration and testing, and defect and vulnerability detection. In this paper, we are concerned with understanding the value of a well-understood and well-managed architecture on software quality.
System complexity results from dependencies that can violate an intended architecture. Dependencies prevent modularity and the lack of a well-defined and well-understood architecture makes change difficult to manage. We decided to analyze the Android kernel using Lattix Architect to illustrate how understanding software architecture and identifying dependencies can help any development organization manage the impact of change, improve productivity, simplify code maintenance, and reduce risk. This is the first time an in-depth analysis of this kind has been done on the Android kernel.
The Lattix Architect solution employs a unique and powerful strategy for communicating, visualizing, analyzing, and managing a software system's architecture. Lattix allows the architect to formalize and enforce the overall architecture of a system through design rules, and to leverage DSM as a key component of Lattix's approach for controlling the complexity of a large software system.
The Lattix approach allows developers of large software systems to formalize, understand, communicate and maintain their architecture. Further, this architecture is easy for managers to understand which makes it easier for business issues to be incorporated in the development process.
Since software development is a highly iterative process, the management of software architecture impacts the entire software life cycle. Lattix products help understand the impact of requirements, maintain the integrity of the architecture during the code implementation process, and simplify the test requirements. As a result, Lattix solutions have wide applicability.
This QoSA paper recounts large retailer L.L. Bean's effort in restructuring its code-base and adoption of process improvements that support an architecture-based agile approach to development, governance, and maintenance.
The software architecture is formalized in terms of a Lattix Dependency Model (LDM). An LDM allows the architect to formalize and enforce the overall architecture of a system through design rules, and to leverage DSM as a key component of the approach for controlling the complexity of that system. Furthermore, the LDM serves as a blueprint of the architecture that is easy for managers and developers to understand, which makes it easier for business issues to be addressed in the development process.
The process of creating an LDM involves the use of Lattix Architect and leveraging the knowledge that architects already have about their system. This process is iteratively applied to refine and update the architecture over the life cycle of the product.
Design Rules allow us to tackle one of the thorniest problems in software. It has frequently been noted that software begins to degrade over successive revisions. A key reason behind this common phenomenon is the inability to communicate and enforce architectural intent. Over successive revisions, changes to software no longer adhere to the original architecture. Often, new developers change things in unintended ways. These changes are necessary for the evolution of the software system to support new capabilities. However, the changes made to accomplish this are made without either a clear understanding of the current architecture or a clear understanding of how the architecture should evolve to support those changes.
As will be seen in this paper, the DSM grid itself provides a powerful representation for setting and visualizing design rules. Further, the grid makes it easy to pinpoint violations of design rules and to understand where the violations come from.
Whether including open source components or purchased 3rd party components, most large software systems being built today leverage some form of 3rd party components. As a result, most organizations need some level of process to ensure that the licensing requirements of the 3rd party package are understood and met. For instance, when and where to credit or include copyright information for the 3rd party component is frequently specified in the license agreement.
However, these processes are typically manual, relying on development staff to follow in a timely manner, rather than an automated mechanism to check for compliance. Often, this means that newly included 3rd party libraries are assessed only at the end of the software release cycle, or worse, at some point after the software release.
With Lattix solutions, you can establish an automatic "gate keeper" for 3rd party libraries. That is, you can create Design Rules that allow use of approved 3rd party libraries, and by default disallow the use of non-approved libraries. Moreover, you can control which of your systems/products can use which 3rd party libraries.
Learn how BEA explored the architecture of Javelin with Dependency Structure Matrix in this Java Developer Journal article.
Read the EclipseZone article on expressing software architecture with inter-module dependencies. Look at a DSM for the entire Eclipse platform and learn what it reveals.
Read up the basics of Dependency Models in the CrossTalk Magazine and understand how this powerful new approach fits into CMMI.
Read an analysis of Jackrabbit with Lattix LDM in Jukka Zitting's blog.
An approach to managing the architecture of large software systems is presented. Dependencies are extracted from the code by a conventional static analysis, and shown in a tabular form known as the Dependency Structure Matrix (DSM). A variety of algorithms are available to help organize the matrix in a form that reflects the architecture and highlights patterns and problematic dependencies. A hierarchical structure obtained in part by such algorithms, and in part by input from the user, then becomes the basis for design rules that capture the architect's intent about which dependencies are acceptable. The design rules are applied repeatedly as the system evolves, to identify violations, and keep the code and its architecture in conformance with one another. The analysis has been implemented in a tool called Lattix Architect, which has been applied in several commercial projects; in this paper, a case study application to Haystack, an information retrieval system, is described.