Those familiar with military aviation training methods and simulators will be aware of a fact which came to my attention just last week. During a meeting with a major UK supplier of military and civilian hardware and software, their representative reminded me that military pilots, once qualified, are most regularly trained in the tasks which they least regularly carry out.

While a pilot will be operating the undercarriage and trimming elevators or the rudder in every flight, he will hopefully never need to eject from the cockpit. However, should he ever need to, he absolutely must know how to go about it, the procedures that need to be carried out and the controls used to ensure his safe ejection from the cockpit and deployment of his parachute. To ensure that this is the case, he will regularly undergo cockpit ejection training in a simulator environment, but will rarely use a simulator to practise trimming procedures.

Whatever role we find ourselves in, most of us quickly internalize those activities which we regularly carry out. How does this relate to training software engineers?

During the last few years I’ve been disappointed to learn of the number of educational establishments which will teach many of the topics we’ve discussed only through a lecture format. Whilst I appreciate that projects are time-consuming to plan and run, my experience tells me that a student who is encouraged to use the techniques they learn in the context of a team project, will not only gain a better understanding of how a project is run and the project management techniques they’ve learned, but also will be more likely remember the likes of UML and SSADM.

Application of taught skills is, in my view, essential to the full learning and further development of those skills, and also gives the opportunity for students to experience them in something closer to a real world environment, rather than just in the sterility of the lecture hall.

Let’s call this ‘aspect-oriented teaching’ and consider how it might work…

In my first post of this series a few weeks back I mentioned the relevance of using conventional techniques such as SSADM to illustrate the concepts of abstraction and iteration. These are ideal illustrations of what I term software engineering aspects. Although these should not to be confused with the specific discipline of aspect-oriented programming (AOP), they are a concept not dissimilar to the crosscutting concerns of AOP.

The usual example of a crosscutting concern is logging – a technique often used to help trace method calls, particularly in distributed systems which may not be easily debugged. Entry and exit points to methods will often be logged with some textual information stored to some file or other storage mechanism. The difficulty is that in most programming languages in order to acheive this the engineer is forced to add appropriate logging method calls in each and every method of the system.

The idea of AOP is that these crosscutting concerns are transformed into single units called aspects which are implemented separately from the rest of the project, then combined into the final executable form using an aspect weaver. This enables a single, self-contained aspect to contribute to the implementation of many methods and classes without the original code having any knowledge of the aspect or its functionality.

So, dragging us back to the point of this post, I consider software engineering aspects to be a means of identifying common concepts across a range of SE disciplines, thereby allowing those disciplines to be better integrated in the curriculum. This means that in addition to the publication of a series of modules on the basics of programming, data structures, object-oriented analysis and design, UML, SSADM, architectures, project management, software testing and so on, one might consider publishing a matrix which shows how aspects such as abstraction and iteration apply to these topics.

An even braver approach might even re-arrange course content so that each semester was aspect-themed, with traditional modules run over a longer period of time in order to allow the student to be led through an exploration of an aspect in different disciplines. The semester is then effectively ‘framed’ by the aspect, providing a common meeting place for the varied topics, and a means of communicating to students the importance and relevance of identifying commonalities in a range of subjects. This exercise in itself might also help students in their own quest to generalise concepts in the systems they create.

I’m sure that this poses a number of questions to those involved in the day-to-day education of software engineers.

• Are examinations aspect-oriented or topic-oriented?
• If a topic is being spread over a longer period to allow all relevant aspect-related subjects to be covered, how can the topic be efficiently assessed?

Fair enough – post them and let’s discuss.

Is this really an attitude we should be passing on to future generations of computer scientists?

At the risk of sounding like a grumpy old man (before my time I hasten to add!), my belief is that we’re better off training software engineers than creating Java programmers (or .Net programmers for that matter). It’s a belief which I appreciate is grounded in my own educational and commercial experiences, but a set of generic engineering techniques is a far more valuable resource for developing a worthwhile career in IT. They enable the recipient to more quickly grasp a wider range of concepts, without having to carry out additional mappings from a particular language they’ve been taught.

I know that students will always want to know when they can build an application, and that is an important aspect of any degree course, particularly if it can be carried out in the context of some group engineering exercise. But if we bow to the pressure to teach just programming, or worse still just the development of glitzy websites, we run the risk of losing a generation or two’s worth of computer science. Perhaps students need to be persuaded a little more of the value of understanding the historical context of the topics they’re studying, and spend a little less time hacking something together.

I fear that technology imbalance is a problem which is also exacerbated by the activities of recruitment agencies. I guess it’s partly down to the way in which the IT job market is now driven, but many of the agencies I’ve worked with seem to place far too much emphasis on keyword searches for ‘Java‘, ‘C#‘, ‘C++‘ and so on. I suppose when the market is so busy, as it seems to be now, and when face-to-face meetings are reserved for the select few, there’s no time for them to assess the wider merits of an applicant. I find it’s often the experiences described in a CV’s prosaic paragraphs which better communicate the real skills of an individual rather than some claim to have 5 years experience of SQL Server. Perhaps this points to a need to do more direct recruitment…

It’s clear to me that the use of the Structured Systems Analysis and Design Method (SSADM) is still an important part of the software engineering educational curriculum in many countries. I discussed this briefly in a recent debate with the author of one of the leading textbooks on software engineering, which in the latest editions has dropped its chapters on such ‘traditional’ techniques. While it’s true that much of the commercial software world has moved onto ‘contemporary’ techniques, I believe there is still some educational value to be gained from understanding SSADM.

The key point is that many of the contemporary techniques are simply that: techniques. Many of the standards from the Object Management Group do not advocate a particular method of invoking techniques such as the Unified Modeling Language (UML), although of course a number of methodologies such as RUP and Select Perspective incorporate UML techniques in their delivery. Therefore students may be taught how to model a system using use cases, classes, state models and components, but the context for that modeling activity is often less clearly communicated to them. The application of SSADM in an educational environment can really help students to understand the value of the common concepts behind all these techniques.

In particular, the concepts of abstraction and iteration can be very effectively taught using SSADM tools. The several levels of dataflow diagram advocated by both SSADM and Yourdon approaches are an ideal way to communicate to students how a high-level abstract view, which is simple and quick to understand, can be of real value to those trying to comprehend a complex system. Of course this high-level view is then iteratively decomposed (the reverse of abstraction) gradually increasing the level of detail of each process, until sufficient information is identified about the system.

Of course, the all-to-familiar occurrence of technology favouritism plays a part in how software engineering is taught. In my next post, I’ll consider the pitfalls of allowing personal preference to influence curriculum content too greatly, and the importance of providing a balanced viewpoint.