Training Software Engineers – Part 3 – Aspect-Oriented Teaching

While recently pulling together over 130 hours of video-based training material for software engineers and project managers I was reminded of how regularly a number of key aspects kept cropping up, even as we looked at very different software engineering practices and ideas, like SSADM, UML, BPMN, test driven development, risk management and so on.  In an ideal teaching environment I would love to see these concepts form the backbone of the curriculum, so that a student is effectively able to navigate the course content through following the concepts, while at the same time covering a wide range of topics.

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.