Myths and Misconceptions
Teaching this course over the years, there are a number of misconceptions that we run into. As much as possible, the course material tries to prevent these arising, but they do anyway. Generally our impression is that students that actively engage with the material and the subject understand the true nature of the course after a few weeks. Still, it is worth writing these down here, so that instructors are forewarned and students can be guided in a more positive direction.
We are learning a software architecture processNot at all. The process that is used in the subject is in fact a simplified version of the first two phases of the Unified Process -- that is, the Conception and Elaboration phases. The intention here is to simply to provide a framework in which to structure the work on the project assignment. It's a good match, since the Unified Process explicitly recognizes the place of architecture, but it doesn't mean that you have to use the Unified Process in order to use or benefit from explicit construction and study of the system's architecture.
Similarly, the fact that the three views (conceptual, execution, and implementation, in this subject) are presented in a particular order in the subject modules does not mean that they should necessarily be approached in that order, or in fact in any sequence at all. While the conceptual architecture generally comes earlier in a "green field" development, the different views are simply tools for understanding and describing the system's architecture, and should normally be used as and when appropriate.
The programming assignment has nothing to do with architecture
The programming assignment is intended to be a "light" version of the Executable Prototype. As such, it should be used to firstly demonstrate that the architecture is feasible, and secondly as the basis for ongoing system development (in the Construction phase). Students that view this assignment as an implementation of a system will always go horribly wrong, as they have no choice but to think about functions and features when they should be thinking about architecture. This is in fact one of the hardest things for many students to grasp in this subject.
We spend a lot of time learning how to draw diagrams, instead of learning about architecture
Diagrams are a natural part of any architectural description, and once you accept that, then the question becomes what kind of diagrams are you going to draw? One common choice is to use informal, ad hoc notations. That is fine, if it serves to communicate something useful. A second is to use UML. That is also fine, if you are prepared to accept the fact that you are really only using UML syntax and not its semantics, and you do not mind the fairly cumbersome diagrams that often result.
What we do in the book -- and teach in this course -- is try and make the diagrams that we already use (informal, ad hoc ones) a bit more systematic. The notation is really very simple, so it always surprises me (John Reekie) when people focus on the syntax of the diagrams, rather than on what they mean. Because that is the real point: regardless of the diagrammatic notation you use, what does the diagram mean? Does it capture useful information about the architecture? Does it do so at an appropriate level of abstraction? And with an appropriate level of precision? Always remember that the diagrams are simply an aid to capturing some particular information about the architecture. So if, by learning "how to draw diagrams," you are actually learning "how to think about structuring an architecture," then I guess I'd have to say that that is a good thing.
We should be following standards
I'm never quite sure how to react to students who claim that software engineering is about following standards. The subject does touch on IEEE-1471, but honestly, until a student truly understands and has internalised the whole concept of view, then talking about 1471 is really a waste of time. The subject presents architecture in terms of three views or "architectures" (conceptual, execution, and implementation), each of which is different in a very very fundamental way. If one is able to describe the architecture of a system in terms of these three views, then it's worth talking about how you formalize your architectural descriptions in terms of IEEE-1471-compliant viewpoints. But until then, worrying about 1471 is a bit like worrying about how to "drift" a corner in controlled oversteer when you still have trouble letting out the clutch in first gear.
We should be learning 4+1
The subject material touches on 4+1, but 4+1 is simply a particular choice of views. It's not that far off the three views presented in A Software Architecture Primer (see Chapter 9 for a comparison with 4+1 as well as other sets of views). Nonetheless, it is most important to a) understand the concept of views and b) understand the fundamental distinctions that determine what goes into (or stays out of) a particular view. The book and this subject focus on three primary criteria for choosing components in a view: domain-level responsibilities, execution structure, and implementation structure. If you can understand those, you will be able to navigate any set of views, or (even better) define them using IEEE-1471 to meet the needs of a specific organization, team, or project.
And when you do that, please write us and tell us about it. We would love to hear from you :)