Explaining Your Software in an Architecture Document

There's more to software architecture than the pretty pictures you create to make your 4 + 1 model. You need to incorporate your UML diagrams in an architecture document that explains why the architecture is being proposed and how it meets the customer's needs. This document should explain the key abstractions that you used, as well as the patterns that helped you design the architecture. (I begin telling you about patterns in the next chapter.)

Organizing the architecture document

A very complete architecture document contains quite a few sections. The actual organization of your document may vary, but a typical table of contents looks like this:

  1. Architectural Goals
  2. Architectural Significant Requirements
    • 2.1 Functional
    • 2.2 Nonfunctional
  3. Decisions and Justification
  4. Key Abstractions/Domain Model
  5. Software Partitioning
    • 5.1 Logical Component Model
    • 5.2 Process Model
    • 5.3 Physical Component and Layers
    • 5.4 Development Model
  6. Deployment Model

images

Not all your architectures will need this much documentation. You should be guided by two factors: what your audience wants to see and what your team needs to move forward.

Filling in the sections

What goes into all these sections? The description of your architecture that I've been telling you about in these first three chapters. I give you specific contents of each section in a moment.

You ...

Get Pattern-Oriented Software Architecture For Dummies now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.