SAIP: What is Software Architecture?

What Software Architecture Is and What It Isn't

The software architecture of a program or computing system is the structure of structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

The definition above fits well with the other definitions that we have seen so far especially the one from Garlan and Shaw's Introduction to Software Architecure. However, there are some subtle yet distinctive points about this particular definitions:

Three useful terms are defined in the book that will be pivotal to the discussion of software architecture:

Here is a picture to make things clearer.

Figure 1

So why do we need software architecture? Krutchen already discuss how it gives a representation of the state of the software to the stakeholders. And in Chapter 1, we saw how an architecture helps stakeholders make decisions about the future stage of the software development.

Furthermore, software architecture is also important because it's the earlier manifestation of the design decisions that go into the software. With this software architecture, developers have a better sense on how to organize the structure of software, how to handle changes and how to proceed in the next iteration. Though at the early stage, this manifestation is most probably incomplete and even inadequate, the software architecture serves as an early model for which to base future cost and schedule estimation.

Another importance of software architecture as given by the book is the fact that it is a transferable abstraction of the system. While this is definitely possible, I would argue that architectural patterns (defined above) are more transferable than software architecture because in a software architecture the parts are more detailed and concrete already. As can be seen from figure 1 above, software architecture is the product of the reference architecture stage. As you recall, the reference architecture stage provides the mapping between the abstract architectural patterns and the reference model. Therefore, I believe that some level of abstraction has been lost. Instead, I think that the software architecture might provide a good example of the use of the architectural pattern. But the architectural pattern is the high-level description that should be shared amongst developers.

This chapter also proposes some alternative views for representing software architecture in contrast to Kruchen's 4+1 view. These forms of representations become increasingly important as systems grow more complex. It is no longer possible to represent the entire architecture with just one diagram. By using multiple diagrams, each structure of the software architecture becomes clearer. It becomes easier to identify the important elements for each structure.

This chapter credits the works of David Parnas as one of the most influential figures in defining what software architecture is. I remember reading one of his papers, On the Criteria To Be Used in Decomposing Systems into Modules during my CS427: Software Engineering I class. Apparently this was the seminal paper that proposed breaking the system into modules to promote reuse.

comments powered by Disqus