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.

The five key challenges I examined were:

• Keeping business processes and the solutions that support them closely aligned
• Maintaining investment in intellectual property within, or accessible to, the organization
• Understanding the hand-over points between client and supplier organizations
• Preserving interoperability of long-lived IT system assets
• Minimizing client risk through adherence to standards for development practices

Of course, these challenges are in addition to the risks that are associated with the management of outsourced activities themselves.

In times where standards-based process improvement is de rigueur, seen in the continued push towards CMMI levels 4 & 5, it seems strange to me that so often these activities don’t include the use of standards-based analysis & design methods. Even stranger is that the software assets which are being developed offshore are so rarely subject to formal asset management techniques which can help to not only control the assets, but also to widen their use within a component- or service-based approach.