Attribute-Driven Design (ADD) is a process to developing a software architecture. It is presented within the context of the Evolutionary Delivery Life Cycle (EDLC), a software lifecycle based around architecture. The EDLC describes two feedback loops:

  • Concept – Requirements – Architecture and high-level Design
  • Iterative Development – Delivery – Feedback – Redesign from Feedback

The most critical part of the lifecycle that I see is that the iterative development is targetted at localized changes. The feature-requests that would be architectural (i.e. “no no, it has to run on this QNX cluster, not Linux!”) are expected to be taken care of prior to initial development. This is certainly more financially feasable given the cost of changing architectural concepts after development has started, but it does place a larger burden on the architect (get the high-level stuff right or the low-level stuff will be constantly struggling).

The meat of ADD is the recursive refinement process. An architectural design is treated as rooted module tree, where every refinement step takes a module and subdivides it (starting from the top level module, “the project”):

  1. Determine the primary quality attributes and requirements for the given module, as well as any use-case constraints provided with the module.
  2. Select architectural patterns or tactics (using your architect’s magic bag of tricks) that are designed to support your given quality attributes and requirements. These patterns and tactics will naturally drive the division of labor into submodules.
  3. Document the expectation of submodules with your use cases and multiple views (the “4+1 views” approach).
  4. Define and document the API for every submodule so they satisfy (3).
  5. Verify use cases and annotate them as constraints to the submodules. Recursively refine every submodule with this process that is too big to be atomic.

Quite frankly, nothing in that description really stands out to me as being outstandingly helpful. Quality attributes and tactics have been discussed earlier, so I would expect that developing an architecture would involve using both of those features as decision-makers. The recursive nature of architecture parallels the recursive nature of any form of design. Good software always has compositions of modules, because it promotes reusability, flexibility, and local simplicity (note: the overall complexity probably increases, but it’s the local simplicity we care about because that’s what the maintenance developers need to address). I would argue that it doesn’t need to be exclusively top-down. In the case that an architect has substantial familiarity with a subset of the total project, I think that subset could be addressed first, and worked “backwards” from the subset’s top-level module into the overall architecture.

Ok, so how does this relate to Object-Oriented Design (OOD)? Well, they both focus on localizing simplicity by composing layers of “things” together… a hand is composed of skin tissue is composed of cells is composed of mitochondria is composed of molecules is composed of atoms. Just as atoms themselves have fairly simple rules, the lowest-level objects or modules will have fairly simple rules.

The differences I see are:

  • OOD does not impose a recursive definition – you find nouns and verbs in the requirements, and whatever that happens to form is what you use. There is no distinction of “important requirements”. Recursion will typically follow any division, but as it goes deeper the requirements become less attached and it becomes an issue of programmer complexity.
  • OOD does not address quality attributes. Nouns and verbs distilled from a requirements document may poorly represent the nonfunctional requirements. ADD addresses this by the framework of Quality Attributes.
  • ADD allows imperative programming styles (e.g. allowing a set of money-related functions instead of introducing a data type Money… or possibly using the OpenGL state machine without requiring it be treated as an explicit object). OOD requires that all recursive definitions end up as objects with nouns and verbs.