Structure101 v3 released, adds team-based architectural control


News: Structure101 v3 released, adds team-based architectural control

  1. Released by Headway Software today, new team support makes Structure101 v3 a complete software architecture control solution. Architecture block diagrams define code-base layering. IDE plug-ins communicate these to the team and warn when code changes are inconsistent with the architecture. RSS feeds warn when violations make it into a build. With this major upgrade, Structure101 becomes a well-rounded software architecture control solution in addition to existing structural analysis and complexity management capabilities. Software architects can now specify constraints on the composition and layering of a code-base using intuitive architecture block diagrams. These architecture diagrams are immediately communicated to the development team through IDE plug-ins (Eclipse and IntelliJ) and developers are warned immediately when they make code changes that are inconsistent with the specified architecture. Reports and RSS feeds warn project managers and architects when violations make it into a build. A new online demo gives an overview of Structure101 (in about 13 minutes, with audio) and the version 3 help is available online. The price has been kept at $499 and $999 for the client and publisher respectively, and the full-featured product can be trialed at no cost.
  2. Controlling the dependencies in a system is one of the most important tasks of an architect. Without it, the system may become hard to maintain, harder to understand, and prone to unprincipled changes that can break the system and render it useless. Unfortunately, thus far there was little tool support available to tackle this task. Structure101 promises to change this by giving the architect control over allowing and disallowing dependencies in the system, and giving the developer the chance to fix the violation or "educating" the architect that a certain dependency should be allowed and the architecture should be updated. I tried the demo on a project with (according to Structure101) 436 packages, 2831 classes, 745k bytecode instructions, 320 NCLOC. The ability to zoom in and out of the diagram, and/or collapsing packages would be helpful in what I consider a medium size project. Along with this, naming cells should go on the todo list. Bundling dependencies (a key concept of a similar tool I used to work on some 10 years ago) could be of value to make the tool more scaleable. I think the price is definitely right and there shouldn't be much resistance from the purchasing department. Not all software architectures lend themselves to be represented as layers, if not conceptually, then at least graphically. Making this restriction optional and letting the architect define optional, forbidden, and mandatory dependencies more freely would be an interesting feature to see. Thanks, Thomas
  3. Hi Thomas, many thanks for posting your comments. I think structure101 does most of what you're looking for, but we have put a lot of funtions on context menus because, well just because... Collapsing packages - you can right-click a cell for a parent package and "delete contents" or "hide" selected sub-cells. Cell naming - when you select a cell, the Cell Properties to the left of the diagram show the current name and pattern fields. What may not be excessively obvious is that you can edit these if you double-click the fields. Optional layering restrictions - these are called "overrides". To override the default layering constraints, right-click a cell, "create override" and connect the override to a higher cell to allow a dependency (override is green), or to a lower cell to dissallow a dependency (red). The decision to not support zooming was a concious one (though not without some internal debate). The size of the text is normal small text, so zooming out any further would make the text unreadable and therefor kind of useless. Also, our intent is that each of these diagrams should really fit into a single screen. If they are bigger than this, then they are probably hard for a human to make sense of, and you would likely be better to split the architectural story into multiple diagrams. For example you could create a diagram for the top level architecture with less detail (i.e. nesting), and then have a separate diagram for the internal architecture of each major subsystem. Another consideration is that these diagrams are displayed in IDEs and your developers aint going to leave them lying round if they eat up tooo much of their precious real-estate. All the best, Chris.