There are three architectural perspectives on Hackystat that are important to understand as a developer: the data flow architecture, the subsystem architecture, and the configuration architecture.
Figure 12.1, “ The Hackystat data flow architecture ” illustrates the "classic" architectural perspective on Hackystat, which illustrates how data flows between the Hackystat server and its clients.
This architectural perspective is the one familiar to users of Hackystat: sensors are attached to client-side tools, which send data to the server, where it is processed and higher level abstractions are provided back to the user, either through emails or the browser-based interface to the Hackystat web application. However, it provides very little detail on how the software itself is structured, other than that some of it is "client" and some of it is "server".
After checking out the sources for Hackystat from Subversion, you will discover that the sources are contained in approximately 70 directories. We refer to each of these directories as a Hackystat "module". Furthermore, each Hackystat module belongs to one of four "subsystems" called: "Core", "SDT" (for sensor data type), "Sensor", and "Application". Figure 12.2, “ The Hackystat subsystem architecture ” illustrates these four subsystems, their interdependencies, and whether their code runs on the client-side (sensor), server side (web application), or both. The figure also lists some example public modules in each subsystem.
Modules in the Core subsystem are named with the prefix "hackyCore_", and some examples are hackyCore_Build, hackyCore_Kernel, and hackyCore_Common. As of this writing, there are 7 public modules in the Core subsystem. This subsystem provides basic facilities, such as SOAP data transmission, web application facilities, language definition code, and testing utilities that might be used by any of the other three subsystems. Both "client" and "server" sides of Hackystat might use code contained in the Core subsystem.
Modules in the SDT (Sensor Data Type) subsystem are named with the prefix "hackySdt_", and each module in this subsystem is responsible for defining a single sensor data type and its associated functionality. Example SDT modules include hackySdt_FileMetric, which defines the FileMetric sensor data type, and hackySdt_Coverage, which defines the Coverage sensor data type. As of this writing, there are 17 public modules in the SDT subsystem, which uses the Core subsystem. The SDT subsystem is used by both the sensor and application subsystems. SDT code is also utilized on both the client and server sides of the system.
Modules in the Sensor subsystem are named with the prefix "hackySensor_", and each module in this system is responsible for defining one or more sensors to be associated with a tool to generate sensor data for transmission to the server. Example Sensor modules include hackySensor_Ant, which implements the Ant sensor, and hackySensor_Emacs, which implements the Emacs sensor. Sensor modules generally depend upon code from the Core subsystem, which provides data transmission facilities, as well as code from the Sdt subsystem, which provides representations for the sensor data to be captured by the sensor. The Sensor subsystem code runs exclusively on the client side of the system, and does not depend upon code in the Application subsystem. As of this writing, there are 34 public modules in the Sensor subsystem.
Modules in the Application subsystem are named with the prefix "hackyApp_", and each module in this system is responsible for providing one or more analyses on the data provided to the server. Example Application modules include hackyApp_Cocomo, which implements the Cocomo cost estimation algorithm, and hackyApp_Zorro, which implements inference of Test Driven Design practices. Application modules generally depend upon facilities implemented in the Core and Sdt subsystems, but not upon code in the Sensor subsystem. Application code runs exclusively on the server side of the system. subsystem. As of this writing, there are 15 public modules in the Application subsystem.
The client-server system built from the entire set of public Hackystat modules is large and cumbersome. Furthermore, any given organization will find only a small subset of the features provided by the entire set of public modules to be useful. To address this issue, Hackystat supports the architectural concept of a "configuration": a collection of modules which together provide just the capabilities required to address the needs of a specific context of use.
Figure 12.3, “ The Hackystat configuration architecture ” illustrates three sample configurations: Hackystat-UH, Hackystat-MDS, and Hackystat-Cocomo, and a selection of the modules present in those configurations from each of the four subsystems.
For example, the Hackystat-UH configuration includes all of the modules in the Core, Sensor, and Sdt subsystems, but does not include several of the Application modules. The Hackystat-MDS configuration includes the Core subsystem, one Sdt module, one Sensor module, and one Application module. The Hackystat-Cocomo configuration only requires Core and Application modules (As a preliminary implementation, it does not currently use any sensor data to perform its calculations.)
The Hackystat daily build system builds a small set of configurations automatically each day. Developers, however, are free to build whatever subset of the system is most appropriate to their needs by editing the hackystat.build.properties file and building from source. The ability to build and test only the subset of modules relevant to the current development task is a significant aid to development, since building and testing a small number of modules can take less than a minute, while building and testing the complete set of modules takes over 20 minutes on a typical workstation.
Due to module dependencies, not every possible subset of modules forms a valid configuration of Hackystat. For example, because the Eclipse sensor uses the DevEvent SDT, the build system will not permit the creation of a configuration that contains the hackySensor_Eclipse module without also including the hackySdt_DevEvent module. Detailed information about the process of building Hackystat configurations and managing these dependencies is found in Chapter 13, Anatomy of the Hackystat build system.