In this post, I’ll explain why coupling and cohesion aren’t good enough for judging the modifiability of an architecture, as well as explaining the first few steps in the Software Architecture Analysis Method (SAAM). It’s a sequel to a previous post, so please read that one first!
First of all, the concepts of coupling and cohesion are too abstract. You can’t stand in front of a customer arguing why your architecture is so very good because it exhibits such a nice degree of coupling and cohesion. Not even your fellow architects or developers will be convinced. Probably not even you would be convinced by such arguments!
If some concepts are too abstract, they’re probably wrong, or at least not useful. Read Joel Spolsky’s article "Don’t Let Architecture Astronauts Scare You" to understand why and how. For coupling and cohesion, there are a number of problems.
- The coupling and cohesion takes into account all connections and all functionality of the system. So, for example, of your system isn’t portable between different OSes and different hardware, you’ll get too much coupling between components, a "bad thing". But perhaps you have no plan whatsoever to port your system!
- If you want a complete picture of the coupling and cohesion of your system, you need to extract and describe each and every functionality and connection of your system, on every level of description and every level of detail. But you don’t know if all of those are relevant!Again, it probably contains lots of information about things that won’t change. And the complete picture will be an incomprehensible mess of details.
- There’s no temporal information included. For instance, a connection from one component to another could denote a call done at startup ony, and another a call done every second. So, even if they are part of the same functionality, broadly speaking, they wouldn’t be part of the same use case. A change in a feature is mostly connected to a use case (or a scenario, as it is called in SAAM’s terminology), so that’s the level you’d like to look at.
So, let’s see how the SAAM improves upon this. When you perform a SAAM evaluation, you start by developing a collection of relevant scenarios, and at the same time, you develop a description of the architecture on a level that’s appropriate for those scenarios. So, you won’t get an architecture that contains too much detail. And actually, for describing the architecture, boxes for the components, with arrows between them, for connections, will be sufficient! No UML or cryptic architectural languages are needed. The scenarios will represent actual uses (or changes) of the system, whether supported by the architecture or not. For example, a scenario can be "Log on to the system using Kerberos authentication", or "Change the font of the characters in the settings dialog box".
We’ll see soon what we do when we’ve developed our scenarios and our architecture description, and how it connects to coupling and cohesion. But first we note that the scenarios (use cases) we’ve developed will be the basis for making other people understand the modifiability of the architecture. In addition, the scenarios are good for showing how the functionality is implemented in the architecture, of course. For the "communication" part of the method, the SAAM actually prescribes that the mapping of scenarios to the architecture, which is the next step of the process, should be done in front of all stakeholders of the architecture (that is, those having interests in the architecture, such as developers, users, architects, system administrators, and sales people).
To summarize SAAM so far:
- Develop scenarios and describe architecture
- Map scenarios onto architecture description (not yet described)
When we look at how the scenarios are mapped onto the architecture description, we’ll se how it generalizes the concepts of coupling and cohesion. But that’ll be in the next part of the series!
Filed under: Software Development
