The next step in SAF (after “quality Attributes”) is Modeling. Webster’s dictionary defines “Model” as (among other things) : “3 : structural design; 7 : Archetype ; 10b : a type or design of product (as a car);11 : a description or analogy used to help visualize something (as an atom) that cannot be directly observed” – as I mentioned in my what’s software architecture post there’s no single structure that IS the architecture – this means that we’ll have to look at the architecture from different angles (viewpoints) – for example, a block diagram such as the diagram below (accompanied with some documentation that explains it) may tell us something about the layers that will be used to solve a problem it tells us nothing about the business that we are trying to solve.
We need to augment with more views on the system (such as the next diagram) to visualize better and convey the system’s architecture.
IEEE 1471-2000 “Recommended Practice for Architectural Description of Software Intensive Systems” defines the relationship between the Stakeholders, their concerns, viewpoints, views, and models:
(IEEE 1471 model adapted from a presentation by Rich Hilliard )
By the way, the fact that we need to look at the architecture from different viewpoints doesn’t necessarily mean that the documentation isn’t just POW(“plain old whiteboard”) – The formality of the documentation is driven by the project style (agile/formal) and other stakeholder constraints (company standards, customer requirements, etc.)
Since models participate in views (which in turn conform to viewpoints – which address the stakeholders’ needs/interests), I consider choosing the views a prerequisite for modeling. Thus, in the next modeling post, I will talk a little about choosing views (suggested minimal set, viewpoint library, etc.). Once I get that off the table, I’ll try to talk a little about architectural styles and patterns and follow that with some strategies for dealing with quality attributes before moving to the next SAF phase (Mapping).
