Level 2, 60 points.
For my second year I decided to move up to level 2 courses. Only courses of level 2 and above count towards the final degree grade, and the best grades from qualifying courses are counted, so it pays to do more than the minimum number of higher level courses in order to gain something of a cushion. M209 was a required course for the degree I was aiming for, and looked like it offered a good grounding for some of the more advanced courses, hence the choice. In addition, object-oriented programming was one of those areas that I had been meaning to look into for years, and had failed at every turn.
A 60 point course is supposed to take up approximately double the amount of study time required by a 30 point course. My experiences with the OU (and discussion with other students) suggest that, notwithstanding variations in courses, it is far tougher to do two 30 point courses than one at 60 points -- 2 x 30 generally involves more assignments, two exams (or "end of course assessments" as appropriate) and innumerable context switches between the subjects. Of course, some people choose to do more than 60 points in a year...
Much of the first block involves establishing a vocabulary (what are objects, systems, human-computer interfaces, messages, etc.) and introducing the software used by the course, which is a Smalltalk environment called Learningworks. There is some controversy about the choice of Smalltalk as the programming language on which the course is based, partly due to its unusual syntax and partly as it is perceived to be an obsolete language. Personally, I found it elegant and expressive, particularly after a discussion at a dayschool with a tutor who had been a professional Smalltalk developer for over a decade and who explained some of the inner workings of the language which, while not directly relevant to the course, proved to be a great help in understanding what I was doing along the way. Other important points included the object notation used throughout the course which was based on (but not quite the same as) the UML (Unified Modelling Language).
Block I also had the dubious distinction of introducing the most feared aspect of the course: the frogs. Just about all the object modelling examples in the course involve some form of amphibians, which is OK to start with, but a sense of despair was palpable across the online conferences (on which this course relies heavily) when the "hoverfrog" appeared. (In case you are wondering, it's a specialisation of a regular frog with the special ability to, you guessed it, hover in the air. Sigh.)
The next three blocks converted the largely theoretical discussions on the nature of objects and classes into the practice of Smalltalk code. I always find it enjoyable to gradually get into the driving seat with a new programming language and this was no exception: Smalltalk's driving seat is well upholstered but provides direct access to all but the deepest recesses of the language. From the comfort of the class browser it is possible to see how the language has been constructed from a handful of primitives and to redefine the entire environment with minimal effort. The course only really hinted at these depths, which I think was a pity as those of us who delved a little further seemed to get more out of the experience.
Something the OU tries very hard to do is fit elements of collaboration into its courses and these blocks saw a few exercises which required students to discuss issues and exchange information on the FirstClass conference system. This didn't really work well, showing one of the main disadvantages of distance learning: the difficulty of getting team exercises working.
This is where the course reached what I think was its real heart: learning the basics of using object-oriented techniques in software engineering, from initial requirements analysis based on a written statement of requirements, through to a detailed design document which should make implementation a walk in the part.
Few people seem to like going through a formal analysis and design process and I have to admit to despair at various times when yet another "noun and verb" analysis exercise turned up, but I got through it. From there on, we moved through the use of assorted modelling diagrams using the notation a-bit-like-but-not-actually UML and were introduced to the difference between static and dynamic modelling.
A little more space was given over to user interface design, critical in many applications but often ignored as unimportant. This was good stuff, but seemed to raise more questions than it answered. I suspect a whole 60-point course could easily be devoted to user interfaces, but I don't think there is such a course at the moment.
The final block was something of a grab-bag of topics including computer architectures, operating systems, persistance, the internet and security. Everything was covered pretty quickly: perhaps too quickly as there was just enough detail to get things going but not enough to really put meat on the bones. To a large extent, the final chapter felt a little like a teaser for other OU courses without being specific about which courses (though one was clearly M301, which was on my "hit list" for studying later.
This was another good course with a lot to recommend it. Years ago I had tried and failed to get my head around object oriented programming, but this course really put me firmly onto the path. There were also some good supporting TV programs which covered some interesting issues and connected elements of the course with the real world. On the other hand, we were supplied with a course textbook (which, in the end, was rarely referred to) called Computer Concepts 4th Edition (Parsons & Oja, 2000) that was large, glossy and almost entirely useless. I can only imagine some deal being done for a job lot of these doorstops.
But I mustn't end on a negative. M206 was fun and in retrospect provided a fantastic foundation for later courses.
This page last modified: 2005-10-24.