This guide will walk you through the Sturcture101 products to make your evaluation process quicker and easier. Structure101 is a very rich product and we will not try to predict all of the specific use cases to which it may be applied. What we will do is walk you through the main features in a reasonably sensible sequence and point out the kind of things they can be used for. The idea is that by the time you have completed the guide you should have a good idea as to whether and how Structure101 can help you and your team manage your own projects, and know where to find the additional information that you need.

We include liberal links, mostly into the Structure101 online help that you should follow for a complete understanding of each topic. (This is the same as the help that ships with the Structure101 Client.)

Structure101 for Java comprises several components. The guide starts with Structure101 Client which is functionally the richest component. We'll show you how to analyze the current structure of your code-base and define how it should be structured (the architecture). When you have finished walking through the Client, we'll get you to save some architecture diagrams in a repository where they can be accessed by the other components.

Next we'll get you to try the IDE plug-in, either in Eclipse or IntelliJ (your choice). You'll be able to point the plug-in at the repository to see the architecture diagram within the IDE, navigate to the code that causes any architectural violation, and receive warnings if your code changes cause any new violations.

The final component is the Web Application. This is most useful once you have accumulated some historical data, something you may or may not have time to do as part of the evaluation. We'll walk you through an online example repository/Web Application full of open source projects and help you populate your own repository if you wish.

At any time please feel free to contact us directly with questions or comments - we love evaluators!

Before you do anything

If you haven't already, you should view the online product tour (15 minutes with audio). This will give you an understanding of the Structure101 key concepts and how the product components work together.

Ideally you should gather together the jar files for 2 builds (with a reasonable amount of change between them) of your current project or a project with which you are familiar (not too small, e.g. >20 KLOC is best). This is not essential, we will give you a "canned" project if you prefer.

Structure101 Client

Install the Structure101 client

Follow the instructions here to download, install and license the "Client and Publisher" for your platform:

Make sure you enter a valid email address and click the "Keys please" button on the download page.

For Windows you have the choice of an installer that includes the Java Runtime Environment (JRE) or one that does not. Using the one that includes the JRE takes up some more disk space but requires that you have a JRE correctly installed already. (If in doubt, "with JRE" = less hassle.)

You will receive a Client and Publisher license by email along with instruction on where to save them. The Publisher is licensed separately since can be run stand-alone on a build machine. The Client can run without a Publisher license but a Publisher license lets you publish directly from the Client.

If the project you intend on using for the evaluations is very large (e.g. >1 MLOC) you should increase the heap size allocated to the Java Runtime Environment when Structure101 runs. If you are using a lower memory machine, another option will be given to you later.

Overview of the client

The Structure101 Client creates a model of your code-base directly from the byte code or from information previously saved in a Structure101 repository.

The most important control in the Client is the Perspectives toolbar.

There are a number of perspectives, each one showing completely different views of the model in the main body of the application window.

This guide will walk through the perspectives in sequence, top to bottom.

The file menu and tool-bar at the top of the Client application are static - that is they will be the same no matter which perspective is selected:

A detailed help system is available from the client Help menu. There is also a context-sensitive help that can be opened from the main toolbar:

This opens a simple window with information about the viewer that is currently in focus. It is useful when first finding your way round the client to open this and click round the different viewers in each perspective (wait til you have a project loaded).

Some other general pointers:

Structure101 likes lots of screen space - higher screen resolution is good - maximize the Structure101 application window.
Quickly maximize any viewer within the Structure101 client by double-clicking the viewer's header.
A lot of viewers have drop down menus in the top right, check these out to see what functions they contain.
A lot of functionality is available on context (right-click) menus.
Pretty much every list, graph, matrix, diagram, etc is exportable in a number of formats (csv, xml, jpg, ...) from either the "options" menus on the containing viewer or the context (right-click) menu.

Create a project

It is generally more enlightening to perform the evaluation on your own project or one that you are familiar with (Option 1), but you could also use one of the projects from our online repository (Option 2). Both options are described below.

Option 1 - Create a local project

File/new pops up the "New local project" wizard.

Class files. The first step is to specify the location of the byte code for the project, which needs to be visible from your machine. You can specify directories containing .class files and/or .jar files. For evaluation purposes using .jar files are advantageous since some client features use the jar information. If you have 2 versions of your code, it will be convenient later if you use the older one at this stage. Just specify the code in your project, not 3rd party libraries.

Setting "Granularity" to "Overview" causes details below the class level (inner classes, methods and fields) to be omitted from the model. This is useful when you're "thinking" at the class level - it tends to be quicker, lighter, with less "noise". It also reduces the size of the model significantly, useful if your project is very large and/or you are memory constrained. We suggest you start with "Detail" granularity to see the full amount of information available - feel free to switch to "Overview" during the evaluation if you wish.

You can most likely use the defaults for the other project options, but read the text at each step of the wizard in case they are important for your project and for future reference. You can change the project properties later using model/properties. When you click on "Finish", Structure101 will build its model of your code-base.

When you shut down Structure101 you will be prompted to save the project and you can name it at this point. When you restart Structure101 to continue your evaluation, the saved project will be on the file menu or you can click on file/open.

Option 2 - Open a repository project

File/open pops up the "Open Project" dialog.

Select the "Repository projects" tab. If you have not registered other repositories, the structure101.com repository should be selected (if not you should select it from the "Repository:" drop-down). In the list of "Projects" select "Ant".

Notice the option to "Open in overview mode". This causes details below the class level (inner classes, methods and fields) to be omitted from the model. This is useful when you're "thinking" at the class level - it tends to be quicker, lighter, with less "noise". It also reduces the size of the model significantly, useful if your project is very large and/or you are memory constrained. We suggest you start with this unchecked to see the full amount of information available - feel free to switch to "Overview" during the evaluation if you wish (just re-open the project, this time checking "Open in overview mode).

When you click "Ok" Structure101 will read the Structural data for the most recent snapshot of the project from the repository and reconstruct the model.

Overview perspective

At this stage you should have successfully loaded a project.

Click on the Overview perspective in the perspectives toolbar. You should see a html report.

Scan the first section (lists the project options used) and the "Size" section to make sure it is more or less what you were expecting. If it looks clearly wrong (e.g. too few classes) or there is no report at all (the "Welcome" page is still displayed) then something went wrong and you should go back to "Create a project".

Click on the "Options" menu top right of the report. You can switch on/off the "Show notes and tips" - switching it on inserts boxes of explanatory text into the report. You can also export the report as XML or HTML or open it in a browser (handy if you want to keep it open as you browse in the structure101 client).

Leave "Show notes and tips" selected and read through the report - don't worry if it all doesn't make full sense at this stage, it'll introduce some of the key concepts that will make more sense when you come across them again in the relevant perspectives.

Composition perspective

You'll spend a disproportionate amount of time on the composition perspective because you'll meet a lot of features for the first time - features that you'll meet again in other perspectives.

Click on the Composition perspective in the perspectives toolbar.

This perspective lets you browse your code-base organized by a number of different hierarchies.

Spend some time browsing your project in this perspective.

Use the hierarchy browser (top left) or double-click on packages or classes in the graph on the right hand side to "drill down" from the top level packages to leaf packages to classes, methods and fields.

Select dependencies in the dependency graphs (top right) to see their breakout (bottom right). Vary how the dependencies are displayed using the button top right of the Dependency breakout viewer - as trees (optionally flattened to class level) and/or lists of elemental dependencies: Notice how you can discover more about what depends on what within a complex dependency by selecting items in the "from" (left) or the "to" (right) side of the dependency breakout trees.

Notice the stats on the bottom right of the dependency graph viewer - I = number of items on the graph, D = number of dependencies, T = number of tangles.

Understand how the impact thermometer can give you perspective on where the code in the current graph fits in the overall dependency hierarchy by observing how it changes as you browse around your code-base.

Scan the Options drop down menu top right of the dependency graph viewer to see how you can alter the appearance and behavior of the viewer (and export the graph).

Use the notables list (left middle) to find more complex areas of your code. Selecting on an item in the notables list takes you straight to that item's dependency graph. Use the drop down menu to list each category of notable and navigate to instances of each in order to understand what is meant by "tangles" and "fat" at the different levels of composition.

Browse to some large graphs (maybe use the notables). Double-click the title bar of the Dependency graph viewer to maximize it. Use the overview window to see the overall shape of large graphs and pan around in the main window. Notice the effect of switching on and off auto-partitioning on different large graphs. Notice how auto-partitioning shows tangles differently from clusters. See how dependencies in the minimum feedback set of a tangle are shown. View some larger graphs as a dependency matrix and understand how to read these. Look at the effect of auto-partitioning on a matrix. If your Dependency graph viewer is maximized, un-maximize it (double click the viewer's title bar again) and notice how the dependency breakout works for matrixes too.

[For the rest of the guide, we'll leave it up to you how you view Dependency graphs (unless specified) - as a diagram, as a matrix, auto-partitioned - the "best" varies with the type of graph, you should get used to switching between these].

Take a look at the graph contents viewer (bottom left) - this is an alternative representation of the current dependency graph. Navigate to a large graph and notice how you can use the alphabetically sorted lists in the viewer to find specific items or dependencies on the graph - select them and the graph pans to the correct spot. Navigate to a graph with tangles and notice how you can limit the scope of the graph contents viewer to specific tangles, and how the sortable column in the dependencies list helps you locate dependencies in the minimum feedback set (mfs).

Hierarchies

A unique capability of Structure101 is the ability to view the model organized into different hierarchies. You can switch hierarchies on the fly in the Composition perspective (and others) and can apply custom transformations to the underlying model that will be reflected in all perspectives. You can "tag" items or dependencies in the model to discover where they are in different hierarchies.

Still in the Composition perspective, use the "Switch" drop-down menu to select each hierarchy in turn. Browse the model in the composition perspective to understand how they organize the model.

Select the package hierarchy and select a package (if you are familiar with the code, try to choose one that you know is contributed to by more than one jar). Tag the package (tag/tag selected) and switch to the jar hierarchy to discover which jars contribute to the package. Clear the tags (tag/untag all) and tag a jar - switch back to the package hierarchy to discover where the code in the jar maps to the logical package namespace.

Transformations

Transformations (and more) are a powerful way to customize your hierarchy. They affect the underlying model and so will impact every perspective (here seemed to be the best place to introduce them).

Model/transformations pops up a dialog that lets you create a number of transforming expressions. Click on the "Examples" button and read the text that pops up to understand the kinds of things you can do with transformations.

If some transformations are useful for your project, set them up and save the project. Otherwise, maybe try a few just for fun - e.g. move org.apache.tools to newpackage.tools - just to get an understanding of what is possible for future reference.

Notice that using patterns makes transformations relatively future-proof - e.g. if you move org.apache.tools.* to a new location in the model, any classes or packages added under org.apache.tools next time you load the model will be picked up and moved.

Notice also on the status bar of the application window (bottom right) that the total number of classes that have been "moved" by transformations is given - if this is non-zero, you can click on it to pop up a list of all the moved classes (exportable from the context menu).

Slice perspective

Click on the Slice perspective in the perspectives toolbar.

Where the Composition perspective let you see dependency graphs for individual items in a hierarchy, the Slice perspective lets you see dependency graphs for the entire code-base at different levels of abstraction. At the lowest level, you can see all of the classes (the class "slice"). Moving up, you can see the leaf packages, and higher-level packages (called "design level 1, 2, ...) up to the top-level breakout.

Slices, especially the lower-level slices, tend to be very large. In fact seeing all of the classes or leaf packages for a large project on a single diagram is of limited use. So Structure101 isolates the "interesting" bits for you (tangles and clusters) and lets you view these dependency graphs separately. You can also limit the scope of the slices to specific branches of your package structure. There are also some new graph partitioning options (auto-partition, group by parent, group by design) that help reduce graph complexity. And don't forget you can maximize the graph window and "Show as matrix".

Look at the slice selector (top left). Scroll down the levels and note the sizes of the graphs in each slice, and the degree of cohesion and tangledness. If the cohesion is not 100% it means that some items are "orphans" - neither depending on or depended on by the main cluster in the slice. Tangledness at the class level need not be 0% - what is more important is the size of the class-level tangles and how many packages they involve. Tangles at the leaf package and design layers should ideally be 0% - the Spring framework is an example of a code-base without package tangles.

Select the "Outer class" level slice in the slice selector and select the "Clusters" tab in the group selector immediately below. Click on the "Orphans" group if there is one. These are classes that are not statically related to other classes in your project. It may be that they are used dynamically (e.g. via reflection) or they may be obsolete. You can export the list of items from the Graph contents viewer (bottom left) - select the "Items" tab, right-click anywhere in the list, "copy all" and paste into an email or whatever.

Select any "Orphan groups" in the group selector. These are groups of classes that use each other but do not have static relationships with classes in the "Main cluster". These may or may not be redundant.

Click on the "Tangles" tab in the group selector. Class-level tangles are certainly not automatically a bad thing - commonly used patterns often use mutual references. But there is a cost to cyclic dependencies - all the classes in a tangle need to be developed, tested, deployed, reused together - plus classes in larger tangles tend to be more difficult to understand and modify. Take a look at any reported tangles, especially the larger ones - are the cyclic dependencies justified? Also note the "# parents" column - this indicates the number of packages across which the classes in the tangle are distributed. A tangle is more of a problem if it crosses package boundaries since it is generally desirable to avoid package-level tangles.

If there is a large tangle with multiple parents, try tagging it (right click on "Tangle of x" in the group selector, Tag/items). Now select the next higher slice (Leaf package) and view each tangle until you find the package tangle containing tagged code. In this way you can understand the main source of tangled code. With the class tangle still tagged, switch back momentarily to the Composition perspective to understand how the tangle is distributed across the hierarchies (package or jar). Generally speaking, the higher up the hierarchy that the class tangle is "creating" design tangles, the higher the priority to "fix" it - e.g. by moving tangled classes into the same package and/or breaking class-level dependencies. Understanding, prioritizing and code-base tangles is not easy, but Structure101 provides the information to make it possible.

Back in the Slice perspective, browse round to understand the specifics of your project. Experiment with the graph viewing options: show as graph, show as matrix, auto-partition, group by parent, group by design: . The 3 partitioning features simplify complex graphs as well as showing how the code is distributed across the package structure.

The Graph contents (bottom left) and Dependency breakout (bottom right) behave exactly the same as you saw in the Composition perspective.

Scan the Options drop down menu top right of the dependency graph viewer to see how you can alter the appearance and behavior of the viewer (and export the graph).

Architecture perspective

In the Composition and Slice perspectives you were understanding how your code-base is structured. The Architecture perspective continues to help you understand the current structure while letting you also define how your code-base should be structured (we call this "architecture").

Click on the Architecture perspective in the perspectives toolbar.

If you are using your own project the Architecture perspective will be empty, if you're using our project you'll probably see a single diagram. Either way, let's start by creating a new Architecture Diagram.

Clicking on the "new diagram" button on the "Architecture diagrams" viewer pops up the "create new diagram" wizard. Read the wizard text so you understand what's happening. You can create empty diagrams and add cells later, or you can get Structure101 to initialize a diagram based on the code-base structure. Choose "initialize diagram based on existing code" and click next. In the "Diagram scope" select the root package that contains the "meat" of your project (or just leave "root" selected). Change the "depth of content to 2", don't "include classes" unless your project is very small (it will let you create more substantial diagrams) and click "Finish" - Structure101 initializes the new diagram which is now selected and displayed.

Look at the Diagram properties viewer (left middle). Structure101 automatically named the diagram e.g. "Diagram 1" - double-click on the "Name" field and change the name to "Top-level architecture" (hit <enter> to exit edit mode). "Enforce" means that if/when you publish the Architecture diagrams to a repository, they will be visible within any IDEs that are linked to the repository project - setting "Enforce" to "No" (by double-clicking the field) makes the diagram invisible within IDE's and Web application - useful if you're still working on a "draft". "Strict" means that strict layering is applied to the diagram - cells can only use cells immediately below them in the diagram, not below that (if "Strict" is "No" then cells can use any cell as long as it is lower in the diagram). The "Excludes" field lets you enter one or more patterns - anything matching the patterns is excluded from the diagram. You can enter whatever you want in the "Description" field.

Select any cell in the diagram and look at the 2 fields under "Selected cell" in the "Diagram properties" viewer - "Name" and "Pattern". The "Name" is what appears on the cell, and the "Pattern" defines the physical code which maps to the cell. Because these have been created from the physical code, they will directly correspond to a physical item (package or class) in this instance. This does not have to be the case. A cell can represent any arbitrary set of code, including code that has not yet been implemented (it will will be "picked up" by the cell when it is implemented). Wildcards do not have to be at the end of the pattern, e.g. you can specify patterns such as *.apache.*. Architecture diagrams are extremely expressive - how you use them is entirely up to you and how you wish to visualize your architecture.

Take a look at the diagram you just created, displayed in the Diagram viewer. You should see 2 levels of decomposition with deeper cells nested in outer cells. Structure101 will have "levelized" the diagram so that, as far as possible, cells higher in the diagram only depend on cells lower down. Where this is not possible, a layering "violation" exists and is displayed on the diagram as a dependency that goes upwards. Dependencies that go downwards are generally ok and are not displayed (by default).

You can expand and collapse cells by clicking on the "*", "+" or "-" symbols top right of each cell. This lets you drill down to show or hide as much detail as you wish. You can use this to "chase" dependencies down into a cell to increasing levels of detail.

You can edit the diagrams any way you want. For example you can modify the layering that Structure101 created (just drag it to the preferred level), "move" packages or cells to a new location, wrap a group of cells in a new architectural component (that may not have a physical counterpart).

Spend some time "playing" with the diagram.

Expand/collapse cells to "chase" violations down to deeper levels.

Drag and drop cells to different levels and/or parent cells.

Try out the different options on the "Options" menu - e.g. to show all dependencies, or show all dependencies for the selected cell.

Try the different options on the "Associated items" viewer (bottom left).

Notice the "Dependency breakout" behaves just the same as in the other perspectives.

Drag and drop items from the associated items and dependency breakout viewers.

Try the various operations on the context (right-click) menu.

Create architecture diagrams from the Composition and Slice perspectives (click on the "create new diagram" button within those perspectives). E.g. take a large graph that "auto-partitions" well and create a diagram including the auto-partitioning.

After dragging items to new cells (with respect to the physical structure), click on "Show moved items" on the "Options" menu on the "Architecture diagrams" viewer to pop up a list of the items that have been moved from their current physical location. Click on the "Create transformations..." button on the top of the moved items dialog to convert the moved items into transformations on the underlying model. This lets you use the other perspectives to see how the code-base would look if the change was made. It can also be useful when working on a wide ranging code-base refactoring - you can use an architecture diagram as a "sandbox" until you're reasonably sure that a set of changes is right, commit them as transformations, and start working in another architecture diagram/sandbox.

How you use Architecture diagrams of course depends entirely on your project and your own objectives. The end result should be a set of diagrams that defines how the architecture should be now, or at some point in the future (e.g. after the next iteration of development). Once defined you can use them to monitor the code-base as it evolves, spotting new violations as they appear, and hopefully observing previous violations disappearing. Also, you will be able to publish your defined architecture to a Structure101 repository to make the diagrams visible to developers in their IDEs and so that they get warnings if/when they make code changes that create new architectural violations. Diagrams in a repository are also displayed by the Structure101 web application along with lists of violations. You can even get an RSS feed to notify you if/when new violations make it into a build.

XS perspective

XS (sounds like "excess") is a measure of the amount of over-complexity (or complexity debt) for a code item and the items it contains. Regardless of the specific architecture that you apply to your project, keeping XS under control will lead to a more easily understood and modified code-base than if you don't. In principle XS can be kept to 0 - it is never impossible to keep complexity below reasonable thresholds (which you set). Read the explanation of the XS measurement framework.

Click on the Measurement perspective in the perspectives toolbar.

Double click on the red/blue bar in the top left of the perspective to drilldown what parts of your code-base contain the most XS and/or code.

Notice the Pie chart in the XS Report (top right) which shows you the relative contribution to the XS of the currently selected item from the various constituent metrics.

Notice the list of Items with XS (bottom right) which lists all overly-complex items contained by the selected item. Clicking a slice of the pie chart filters this list. Right click on a fat package and "go to Composition" to see it's dependency graph. See if auto-partitioning looks helpful - if so, create an architecture diagram including the partitioning.

Click on the "Change" menu on the XS Configuration viewer, enter edit mode and see the effect of different thresholds.

Collaboration perspective

This utility perspective lets you understand how any part of your code collaborates with items in the rest of the code-base.

Click on the Collaboration perspective in the perspectives toolbar.

The perspective works very much like the dependency breakout that you've seen in a number of other perspectives, except that you can specify any "from" and "to" nodes, even if the do not appear as a dependency in one of the other perspectives.

Expand the left hand side treeview (top left) and select an item - any items that the selected item does not use are grayed out on the right hand side treeview. Expand items that are used (by clicking on the relevant "+") to drill down on the dependency. Select one of the used items in the rhs tree to grey out items that don't use it on the lhs. The deeper and more specific your selections in the treeviews, the more filtered the dependency breakout below.

Try out the "paddle" and "flip" functions on the top right toobar. These help you "chase" dependencies in either direction.

Try out different hierarchies using the "Hierarchy" drop down menu top right.

Notice that you can "go to composition" (Composition perspective) of any item from the context menu. Try this. Select another item in the Composition perspective and "go to suppliers" or "go to consumers" on the context menu - brings you back to the Collaboration perspective with the item selected on the corresponding side.

To quickly see how your code is dependent on a 3rd-party library, select the "Show externals" option in the project properties dialog. Any items referenced by your project will appear in Structure101 with an external adornment (). Selecting these in the right-hand-side of the Collaboration perspective will show you where such libraries are used by your project.

Compare 2 snapshots

Structure101 can compare the currently loaded model with a previous snapshot saved in a repository. How you do this differs depending on whether you are working with your own local project or our "canned" project.

Option 1 - local project

This assumes that you have (at least) 2 builds of your project and the one currently loaded is the oldest.

Publish the current model to a repository (model/publish, click on "create new" to create a new repository, check "Create new project" to create a project, next, give the snapshot a label, finish, "yes" to associate the local project with the repository project).

Now open the project settings (model/properties) and change the "class files" to point to the jars or class files of the newer build. When that loads, do a model/what's new and select the snapshot you just published. Click Ok.

Option 2 - repository project

You have opened the most recent snapshot of a repository project. Simply click on model/what's new to pop up a list of the older snapshots that are stored in the repository. The default is the next most recent - you can select an older one if you like. Click Ok.

With new items and dependencies highlighted...

The items and dependencies in the various perspectives will be color coded to indicate if an item is unchanged, new or partially new (contains new items or dependencies).

Take some time to explore the different perspectives and viewers to see how the change information is presented and can be used.

End of client walkthrough

That is the end of the client walkthrough. By this stage you should be aware of pretty much all of the client features. There are about as many way to use and combine the features as there are users. The next step is to decide how best Structure101 can help you to control structure and architecture on your project and evaluate the features in that context.

IDE Plug-in

The role of the plug-in is to communicate the centrally stored architecture (created in the Structure101 client) to all programmers on the project, let them easily locate the source of violations, and provide them with compiler warnings (or errors) when they make changes that break the architecture.

Install the plug-in

Note that you need source code to effectively try out the plug-in. If you used our "canned" project for the client walkthrough, you will need to download the corresponding source code from the (open source) project web site.

Follow the instructions here (and subsequent page) to download and install the "IDE Plug-in for Eclipse" or "IDE Plug-in for IntelliJ":

The plug-ins are free to download and use so you will not need or receive a license.

Once the plug-in is installed, open your IDE and configure it.

Notice the control you have over how new vs. pre-existing violations are reported. If there are a lot of pre-existing violations you might like to change this to ignore pre-existing violations.

If you published your local project to a local repository during the Client walkthrough, this is what you should use in the "Repository". If you used our "canned" project, set "Repository" to http://www.structure101.com/structure101-java/data and select the project.

By default, the 2 viewers appear in the bottom right area of the screen. We generally recommend dragging&dropping the Architecture Diagrams viewer to bottom left and leaving the Violation breakout viewer in the default location (with "problems" etc.).

Trying the plug-in

By this stage you should have a project set up in your IDE and the Structure101 plug-in should be configured to point to an older snapshot.

Any Architecture diagrams that were "Enforced" when they were created in the client will appear in the Architecture Diagrams viewer. Clicking on a violation on the diagram will populate the Violation breakout viewer with the elemental class-level dependencies that cause the violation. You can navigate from these to the corresponding source code.

Try modifying the source code in a way that creates a new architectural violation. Notice the build time error on the problems tab.

Web Application

The Structure101 web application web-enables the data in a Structure101 repository so that projects can be accessed from Structure101 clients, web browser and RSS feed across the web.

The web application dynamically serves the data in a repository as a web site that has been defined by Headway, but that can be easily modified for alternative presentation or application.

The Web Application is most valuable when historical structural data has been stored for one or more projects.

We have populated a repository of open source projects to serve as an example. If you do not wish to populate a repository with historical data of your own project(s) as part of the evaluation, you can get a good understanding of the data presentation from this. Browse a few projects because some have only one or a few snapshots, and some do not have defined architecture diagrams.

Populate the repository

You can populate the repository with historical data (assuming you have the old builds) and/or ongoing data in a number of ways:

Interactively from the client
Using the publisher headless
Using a script to publish multiple builds at one time
Called from Ant

Install the web application

Follow the instructions here (and subsequent page) to download and install the Structure101 web application.

The web application is free to download and use so you will not need or receive a license.

Browse the web application

Once the web application is installed, open it up in a web browser, e.g. at http://localhost:8080/structure101-java/tracker/home.html (local) or http://www.structure101.com/structure101-java/tracker/home.html (remote).

At the root of the repository web site is the cross-project summary page that shows the relative size and complexity of the projects in the repository.

Click on any project name or use the dropdown menu (top right) to jump to the project-specific pages.

Click on the "Activity/feeds" menu item on the top left to set up an RSS feed - there are several options as to what which kinds of events will be reported.

The "Structure101 client" menu item explains how to link to the repository from the Structure101 client.

Contact us

If you have any queries at all, email hwsupport@headwaysoftware.com.