This is the last post in a series of posts highlighting the Software Architecture Analysis Method, SAAM. The two previous posts are here (part I) and here (part II); please read them first!
We’ve come so far as to develop a relevant set of scenarios, and we’ve described the architecture on a level of detail that’s appropriate for the scenarios. Actually, we can have several candidate architectures at this step. Since the SAAM doesn’t give you a number like "this architecture got eight points out of ten", you should in fact compare at least two architectures to see which is better. But anyway, now it’s time to map the scenarios onto the architecture(s). How do we do that?
There are actually two kinds of scenarios, direct and indirect. The direct ones are already supported by the architecture (you probably constructed the architecture to support them), and the indirect ones are not, so they require modifications of the architecture in order to be supported. So, first, we decide which ones are of which kind.
Then, for the direct scenarios, we mark within the architecture which components and connections are used by the scenario. Now, if there are marks on lots components and connections, we have low cohesion for that scenario. The functionality represented by the scenario is spread out over many parts of the architecture. Thus, we can now compare different architectures with respect to how well the functionality of each scenario is kept together. Doing this mapping of direct scenarios to the architecture description should be done with all stakeholders present (see the previous post). They’ll learn a lot about the system!
But the interesting scenarios (for software architects) are the indirect scenarios. For each of those, we list the changes needed for the architecture, for example a change in a component, a change in a connection, or an addition of a new component or connection. For example, if we’ve numbered the scenarios from one to twenty, we can draw a number for the scenario on the architecture for the places where modifications are required. If you’re a bit more sophisticated, you could also factor in some kind of estimates of how difficult it would be to do each modification, but let’s simplify. We’ll end up with an architecture description (or several) with lots of numbers on them. Can they tell us anything? Yes indeed! The "bad" thing we’re looking for is a phenomenon called "scenario interaction".
What does it mean for two scenarios (let’s just look at two) to interact? It means that the two scenarios (representing extensions to the architecture, remember?) require changes in the same component or connection. Graphically, it would mean that there’s at least one component or connection with two numbers on it. And why is that bad? For the same reason as tight coupling is bad: two functionalities are inherently connected; there’s no separation of concerns in this case. In practice, it would mean that to accommodate both changes, two developers might have to work on the same component on pieces of code that very much depend on each other.
It could also be that two scenarios interact a lot because they are very similar. That’s a very subjective criterion, of course, but we have to take that into account, too. For example the scenarios "change the password of the administrator" and "change the password of an ordinary user" are quite similar, and will probably have interaction in almost every component.
After doing that, we need to look at the amount of interaction we got, and make a (subjective!) judgment on what architecture is better. Or perhaps just whether the single architecture that was studied was good enough. This step isn’t easy to perform, but I think it’s better to keep it subjective than to try to get some objective measure of the quality of the architecture. The method simply provides you with the relevant objective facts, which make it easier for you to decide what architecture is the better. If you have a lot of courage, involve all the architecture’s stakeholders at this step, too.
So, finally, I hope I’ve managed to explain the SAAM and why it appears to be pretty intuitive and useful.
Filed under: Software Development
