Philip Johnson
Collaborative Software Development Laboratory
University of Hawaii
$Id: VersionSeven.html,v 1.6 2005/09/28 21:55:16 johnson Exp $
This document presents a proposal for the architectural revisions to be made for the Version 7.0 release of Hackystat. To understand why these revisions are being proposed and what the expected benefits of them will be, it is helpful to define the following concepts:
In the best of all possible worlds, the conceptual, module, and package architectures would all be consistent with each other. In reality, they exist in a kind of dynamic tension. For example, during initial development of some new feature, code might be co-located in a single module. Later, that code should be distributed across several modules. A concrete example of this occurs in the hackyTelemetry module, which contains implementations of reduction functions for specific SDTs. This was convenient and appropriate during initial development, but creates architectural confusion in the long term.
The following figure illustrates the module-level architecture of Hackystat 6.x:
For readability, the "hacky" prefix on the CVS module names is dropped from this (and following) images. Thus, "kernel" in this figure refers to the hackyKernel CVS module. The arrows indicate a build (code) dependency: for example, since the Jupiter module imports classes in the Eclipse module, there is an arrow pointing from Jupiter to Eclipse. Several modules, such as Office, Emacs, and Visual Studio do not have any build dependencies on other modules, so there are no arrows connecting them.
Before beginning our critique of the 6.x module architecture, let's revisit our goals:
It turns out that the current structure of the StdExt and Telemetry modules make it impossible to satisfy these design goals. This is because these modules contain both "generic infrastructure" and "SDT specific functionality". As a result, any other module wanting the generic infrastructure from SdtExt or Telemetry modules ends up acquiring a great deal of specific functionality that it may or may not need for its specific application.
More specifically, the StdExt module contains the following:
| HackyStdExt Module Components | |
| Generic Infrastructure |
|
| SDT specific functionality |
|
| Other |
|
The Telemetry module contains the following:
| HackyTelemetry Module Components | |
| Generic Infrastructure |
|
| SDT specific functionality |
|
To understand these functions in detail, please consult the JavaDocs for these two modules, which are available as part of the stable releases for various configurations. Try this link for a recent version.
The combination of generic and specific code in these two modules creates the following major problems:
The following figure illustrates a reorganization of the Version 6 module architecture to address the problems noted above:
Reading from left to right, nothing changes until you get to the "Common" module, which occupies the spot formerly used by StdExt. The "Common" module contains the generic infrastructure formerly associated with StdExt, and the generic infrastructure formerly associated with Telemetry, but none of the SDT-specific code associated with either of these classes. To the right of this module are a set of "Sdt*" modules, currently 13 in all, each of which contain a single SDT definition and associated classes (such as DailyProjectData, DailyAnalysis, Reduction Functions, etc.). To the right of these Sdt* modules are the modules that depend upon one or more of the Sdt* modules.
Note that there is a dashed box around the Sdt* modules, and arrows go into and out of that dashed box. I do this to make the diagram less messy by reducing the number of arrows. The actual dependencies are as follows: all of the Sdt* modules do in fact depend upon the Common module. However, not all of the modules to the right of the Sdt* modules depend upon all of the Sdt* modules. For example, the JBuilder module might depend upon only SdtActivity. In the build.xml file, the higher level modules will specific the subset of Sdt* modules they depend upon explicitly.
The most important improvement in this revised module organization is that there is no longer any ambiguity about where an SDT definition or related code should go. Each SDT definition is contained in its own module, along with all associated DailyProjectData, DailyAnalysis, Reduction functions, and so forth specific to that SDT. The biggest "cost" of this organization is to make the "common" infrastructure (which now includes Telemetry) almost mandatory for any sophisticated application on top of Hackystat that employs SDTs.
Note that there is also a new module called StdCmd that is to the right of the Std* modules. This module contains any remaining commands/analyses that are not properly associated with a single Sdt* module.
Version Seven will also include the HackyInstaller client-side system, and that also has an impact on the module-level architecture. HackyInstaller consists of a set of classes constituting the "generic infrastructure", along with a set of classes to be associated with each sensor implementation that define how to install that particular sensor. Currently, both generic infrastructure and sensor-specific implementation code are combined together in the HackyInstaller2 module. Obviously, we know by now that this is not the best long-term module-level organization, so in Version 7, there will be an Installer module containing the generic infrastructure, upon which all of the modules containing sensor implementations will depend.
The following diagram illustrates the proposed Version 7 module-level architecture with hackyInstaller added:
As you can see, there are no longer any "stand-alone" modules without dependencies, since the prior stand-alone modules were sensor implementations which will now depend upon the Installer module. In addition, two of the higher level modules (Ant and VCS) will contain sensor-specific Installer code and thus will depend upon Installer.
This final increment in the redesign of the architecture is intended to acknowledge that with over 30 modules in the system, it is getting increasingly hard to understand what a module does and where it fits. Up until now, all modules had the standard prefix of "hacky", which is good to identify them as members of the hackystat system, but does not recognize any further functional distinctions. In the beginning of the Version 6 development cycle in mid-2004, the "layering" consisted of Kernel | StdExt | <multiple applications>. In other words, the lowest level was a single module, the middle level was a single module, and multiple modules were all built upon these two lower stages.
In Version 7, we recognize that the natural architectural layering no longer revolves around the kernel and stdext modules, but instead around four subsystems, each containing several hacky* modules:
An 11x17 sized poster of this new architectural layering is available at: http://www.hackystat.org/hackyDevSite/doc/VersionSeven.poster.png.
I believe this is module organization and naming system provides a substantially more understandable architecture.
The last release in the Version 6 development stream will be 6.8, which will release the evolutionary sensor data types. After that, we will begin work on Version 7, which comprises the following major development activities:
Build system redesign: A redesign of the Ant-based build system to include new Ant features and to refactor out all module-specific references from the hackyBuild build.xml files. The goal is to simplify external development and enhancement of the system without requiring centralized knowledge in hackyBuild of all of the modules involved in Hackystat.
Package/module refactoring: Movement of all Hackystat modules from CVS to subversion. As part of this process, modules will be renamed according to the new guidelines (hackyCore_*, hackySdt_*, etc.) and the code within them refactored to obey the new package naming conventions (org.hackystat.core.*, org.hackystat.sdt.*, etc.)
The current projected release time for Version 7 is the end of October.
Please offer any suggestions or improvements.
