The course is aimed at third-year undergraduates and builds on the basic knowledge of software engineering you acquired in Inf2C-SE and on your experience of programming with objects in Java.
One of the major concerns of people advocating object-oriented software engineering has always been how to build software in a modular way that lets you understand how to change or fix a software system without needing to understand every detail of how the system works. Even better, we want to build software from ready-made parts - components - rather than writing everything from scratch. In fact if you've grown up with with OO, you may be surprised this even needs to be said, but I remember when class libraries were a novelty and we used to teach about data structures because people would actually be programming their own on a regular basis. Object orientation gives a way to think about the structure of software systems that most people seem to find cognitively natural.
To build a system of any size, people need to be able to talk about the structure of the system and again, what's cognitively natural seems to be to draw diagrams. This leads into the idea of modelling software using a diagrammatic language. You can describe various aspects of the system, and you can do so at a much higher level than the code itself, and you can do so before the code has been written.
You've already learned the basics of how to use the Unified Modelling Language, UML, which is the industry-standard language for modelling software systems. ...that is, this course assumes you have done so; if not, you'll need to do a little extra work on this...
In this course we'll go into a lot more depth, and as well as talking about how to write down your design decisions in UML we'll be talking about how to make those decisions, how to decide what design would work best in a given situation.
We'll also be covering something which I think is among the most interesting ongoing developments in software engineering, and that's what's called model-driven development. As people get used to having models of software, they naturally want to get the maximum value out of them for the minimum cost, and there are different ways to approach that. Sometimes it's best to use UML very informally - minimising cost - for example just drawing diagrams on whiteboards during discussions, and not spending time putting them into a tool. In other circumstances projects decide to go for maximising benefit, and that means using the models not just to foster discussion but also to generate outline code, keep the database schema up to date, generate documentation automatically, and so on. You have a spectrum of possibilities and where you are on it affects how you use the modelling language, and to some extent even the way you design.
It isn't essential to have a book for this course, but if you'd like to use one, this is the one to get. You'll see that I wrote it, so I'm perhaps not entirely objective about it. The going rate for second-hand copies seems to be about 62 pence and they're quite widely available, but you will find a second edition, covering UML2, much more useful than a first edition covering UML1, because the language changed quite a lot between those versions.
For more information you can look at the course website, but if you're watching this sooner than about August 2012 you need to be aware that the course is changing a bit for 2012/13. ...no need to worry about that any more... Basically what I'm trying to do is to reduce the amount of overlap with our other software engineering courses, and instead go into depth on the design and modelling aspects of software engineering with objects and components.
Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK
Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail: firstname.lastname@example.org
Please contact our webadmin with any comments or corrections. Logging and Cookies
Unless explicitly stated otherwise, all material is copyright © The University of Edinburgh