Resources

Structure101 video tutorials

The videos below give a detailed walkthough of the main Structure101 features. The videos cover Studio, Workspace and Dashboard, and the interaction between them. You can use section labels on the video timeline to jump to sections of interest.

Tutorial 1

(38:53)

  • Introduction to Structure101 company, concepts and products (Powerpoint)
  • Workspace introduction
    • Basic model browsing
    • Understanding dependency levels
    • “Spotlighting”
    • Nav to/from source
    • Seeing changed dependencies - re-levelization

Tutorial 2

(48:20)

  • Workspace Continued
    • See what Fat and Tangles look like in visual model
    • Repairing Fat Methods and Fat Packages
  • Introducing the Studio UI
    • Project properties
    • Browsing the Levelized Structure Map
    • Viewing options
    • Tagging and filtering
    • Structural over-complexity

Tutorial 3

(50:10)

  • Studio continued
    • Walk through the model Views
    • Disentangling an example package structure
    • Extracting a feature from a module
  • Propagating actions (target architecture) from Studio to Workspace
    • Discovering target architecture violations in Workspace
    • Repairing violations in the code
    • Using the target architecture to guide ongoing development

Tutorial 4

(49:20)

  • Module specs
    • Module settings
    • Module UI panels
    • Defining Module visibility
    • Using Deprecation
  • Creating Structure Specs
  • Creating Architecture Diagrams
  • Using the specs in Workspace

Structure101 Workspace

Structure101 Studio

Structure101 Build

Structure101 Licensing

Third-party parsers

1 Our Structure101g Studio and Structure101g Build, "generic" versions, support third-party developed language parsers.

Currently, parser-specific help is available for:

Flavor Developer's Guide

Other

Independent resources on architecture management

We have gathered together a small and mostly random selection from the wealth of independent information available on the 'whys' and 'hows' of managing software architecture. We encourage you to browse at your leisure, and contact us if you are aware of further interesting and relevant materials.

Guidelines for Successful Acquisition and Management of Software Intensive Systems - A landmark study by The Software Technology Support Center and The Mitre Corporation concluding, among other things, that well-structured code is delivered in half the time, at half the cost and 8x less prone to defects.

Code Organization Guidelines for Large Code Bases - A presentation by the Spring Frameworks's Lead Architect, Juergen Hoeller, on why we must worry about code organization and be sure to manage our software architecture.

Stop Software Architecture Erosion - From QCon London 2011, a presentation by Bernie Merkle advising on preventing architectural degradation of a project by using tools for constant monitoring of the code, exemplifying with an analysis of Ant, Findbugs and Eclipse

Re-architecting a Large Codebase - A presentation by Sakonnet's Tim High from Dr Dobb's 2008 Architecture and Design World where Tim discusses how Sakonnet used Structure101 to refactor the architecture of over 2m lines of Java code.

No cycles allowed at package level, not even as a temporary measure! If it looks like we need a cycle, we force ourselves to look again and think harder.

Juergen Hoeller, Architect, Spring Framework

Where did my architecture go - From QCon London 2011, a presentation by Eoin Woods on writing code that preserves the initial architectural design using conventions, dependency analysis, module systems, augmenting the code & checking rules, and language extensions.

Controlling your Architecture - From Jfokus 2009, Magnus Robertsson of Jayway shows how to control the code architecture manually, statically and dynamically in order to avoid an architectural drift leading to a big-ball-of-mud. For that, he recommends ways to enforce the reference architecture through peer review, code analysis, and zero tolerance to warnings and errors.

Tools exist for enforcing your architecture. Start today! No more "Word architectures"!

Magnus Robertsson, Enterprise Architect, Jayway

Solid Principles of object-oriented design - Uncle Bob Martin's classic principles of good object-oriented design.

The Joy of Stats - Excerpt - If you have any doubt about, or want to convince someone of, the value of visualization just check out this amazing presentation.

Software Engineering Radio: Episode 115: Architecture Analysis - During Evolution of a software system, it becomes more and more difficult to understand the originally planned software architecture. Often an architectural degeneration happens because of various reasons during the development phases. In this session we will be looking how to avoid such architectural decay and degeneration and how continuous monitoring can improve the situation (and avoid architectural violations). In addition we will look at "refactoring in the large" and how refactoring can be simulated. A new family of "lint like tools for software architectures" is currently emerging in the marketplace I will show some examples and how they scale and support you in real world projects.

IEEE Paper: Structural Epochs in the Complexity of Software over Time A case study using a new complexity measurement framework called Structure 101 tracked the structural complexity of three open source software products through their different releases. The analysis found that, as these software products evolved, a large proportion of structural complexity in early releases at the application-code level progressively migrated to higher-level design and architectural elements in subsequent releases, or vice-versa.

Architectural Visualization Key to Code Reuse - From Gwyn Fisher, CTO at Klocwork, writing for Military Embedded Systems magazine - What can developers of military and avionics software systems do to take advantage of software reuse while ensuring that software is as bug-free and secure as possible?

Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test ... Each of us should ... explore and embrace techniques to reduce complexity.

Ray Ozzie, former CTO, Microsoft

Taming the complexity: The need for Program Understanding in Software Engineering - Detailed description from Prof. Raghu Sangwan of Penn State University, highlighting the need and the practice of program understanding and design-level refactoring using real world open source examples. One of the objectives of the program understanding course is to help professional software designers and developers become more effective in doing design and code reviews, and introduce software architects to techniques and strategies for architecture reconstruction and for monitoring systems for architectural conformance.

Stop the Software Architecture Erosion - Presentation by Bernie Merkle from ACCU 2009.

Domain-Driven Design Using Naked Objects - A book written by Dan Haywood on using the Naked Objects open source Java framework. The book includes a chapter on keeping the model maintainable using Structure101.

As systems become larger and more complicated, architecture assumes a more important role than has traditionally been the case. Exactly how organizations make use of architecture is an important indicator of their success in developing complex systems that meet their requirements in a cost efficient manner.

Software Engineering Institute, Carnegie Mellon University

Structure101 Video Tutorials

Structure101 Studio lets you discover, create, and share your software architecture faster and easier than ever before. Whether you're a new or existing user, our video tutorials are here to help you get the most out of your Structure101 experience.

Introduction

Setting the scene. The rationale, principles, and key concepts behind Structure101, in presentation format.

Is it quicker & easier to do something else?

Interviews with Structure101 users. (5:41)

The structure of a codebase

How is your codebase organized now, why do you need organization, and what is a good organization anyway? (4:21)

Well-structured containment

Discover the properties that make a “well-structured containment model” so much simpler?. (4:56)

Creating well-structured containment

How you can create a “well-structured containment model” for your existing code-base. (6:14)

Making it real

How Structure101 lets you put these principles into practice. (3:55)

Quick product demo

Structure101 in action, organizing an existing code base into a cogent, software architecture. (4:31)

Levelized Structure Map (LSM)

With your objective firmly fixed in your mind, find out how to use the LSM to take your first step. Create a well-structured containment model using your existing source file dependencies and current physical organization. (Videos in this section refer to a previous product called "Restructure101", which is now the "Structure" tab in Structure101 Studio).

Quick tour of the LSM

Understand the user interface that lets you manipulate the LSM into your ideal containment model. (2:51)

Browse composition

Learn to browse the compositional structure of your code-base in the LSM. (2:15)

Understand levelization

Understand how "levelization" makes the vast number of inter-dependencies in your code-base easier to understand. (5:59)

Understand grouping and slicing

Learn to use automatic grouping and slicing to expose structural patterns, reduce complexity, and make your code-base even easier to understand. (7:36)

Editing the LSM

Manipulate the LSM to construct your containment model and simulate structural changes to your code-base. (5:26)

Example - using the LSM

Ties it all together by disentangling a sample C# project (the product and techniques are (mostly) language independent!) (15:19)

Architecture Diagrams

Once you have a containment model you are happy with, it is time to put some constraints on container relationships, and share it with the team. Learn how to define, communicate and enforce layering and visibility rules across the whole team with Architecture Diagrams, IDE plugins, and build integration.

Quick tour of Architecture Diagrams

Learn how Architecture Diagrams ensure that everyone has a common (and enforced) understanding of a defined architecture. (4:39)

Architecture Diagrams in detail

Everything you need to know about creating and editing architecture diagrams. (16:54)

Talks

Sit in on a couple of conference talks presented by Chris. These include demos of using the LSM and Architecture Diagrams (towards the end of the talks in each case). There is a fair bit of overlap between these talks, but you might find it useful to hear the story presented from slightly different angles. (The talks refer to a product called "Restructure101" which was absorbed into Structure101 Studio as the "Model" tab).

You really should organise that codebase

From Oredev 2014. We can do without architecture early on, but at some point a clearly communicated architecture offers big productivity benefits to developers who otherwise drown in the expanding implementation-level detail. When you realize you are heading for a Big Ball of Mud, you have 3 choices – start over, suffer on, or knock your codebase into shape. This talk outlines principles, options and examples using Structure101 to get the best return for the cost and intellectual effort invested in a codebase. (42:37)

Where's your Architecture?

From 33rd Degree 2014. When a code-base grows beyond a certain size, any original arrangement of source files (or architecture) is often lost. The developers also become lost, and start drowning in the ever-expanding sea of classes. Usually the underlying code – the classes – are in reasonable shape. The problem is that there are too many classes to understand without any higher-level guiding structure, and physical structures (such as packages or jars) have become a tangled mess. The good news is that it is generally perfectly feasible to organize existing classes into a modular hierarchy with minimal impact on the implemented code. (64:10)

Retrofitting Architecture

From Oredev 2012. We can do without architecture early on, but at some point a clearly communicated architecture offers big productivity benefits to developers who otherwise drown in the expanding implementation-level detail. Do you start over, suffer on, or knock your codebase into shape. (52:42)