Download Object-Oriented Software Engineering Implementation at Edinburgh Uni and more Summaries Software Engineering in PDF only on Docsity!
Up dating the software engineering curriculum at
Edinburgh University
Perdita Stevens?
Department of Computer Science University of Edinburgh The King's Buildings Edinburgh EH9 3JZ
Abstract. This pap er rep orts the exp erience of Edinburgh University's Department of Computer Science in undertaking, in two stages, a ma jor reform of its software engineering teaching in the third and fourth years of the degree. Our aim was to increase our students' exp osure to ob ject oriented and comp onent based software engineering, asp ects of mo dern software engineering which are highly relevant to the careers many of them undertake. One of our more signi cant decisions was to teach the emerging standard mo delling language, UML. The pap er describ es the background to the decision to change the course, the changes that were made, and the results of the changes. It do es not presume to draw univer- sal lessons from the story, but do es describ e what we see as the signi cant features.
1 Intro duction
In 1994 the University of Edinburgh intro duced an honours degree in Software Engineering to complement its existing Computer Science and other degrees. At that time the Department of Computer Science to ok the view that software engineering was a branch of computer science, and accordingly the software en- gineering degree was a more constrained version of the computer science degree, omitting some of the more theoretical courses and requiring the more practical courses. It rapidly b ecame clear, however, that there was scop e for a broader and deep er coverage of software engineering as a discipline in its own right, and that there would b e a great deal of student interest in such coverage. The department decided to create a new nal year mo dule in Software En- gineering in order to strengthen the software engineering content of the degree. However, resource problems meant that a new mo dule was not designed in time for delivery in the academic year 95/96. This marked the b eginning of the au- thor's p ersonal involvement in the development of this part of the syllabus. I had recently joined the department as a research fellow, after working for some years as a software engineer. Moreover I had b een acting as tutor on a course, Topics in Software Engineering [3], develop ed by the (British distance learning)
? (^) Perdita.Stevens@dcs.ed.ac.uk
Op en University. This course seemed broadly suitable for our needs, and as the existence of a nal year software engineering mo dule had b een announced to students, it was agreed that I would deliver a course based on it, adapting it as necessary. Because of the availability of go o d self-study materials (which we pur- chased from the OU), it was p ossible to depart from the more usual 18-lecture format of our courses, replacing some lectures with tutorial-style meetings in which students addressed problems in small groups. Lectures summarised the material, students read the detail outside contact time, and the tutorial-style meeting allowed them to check their understanding.
2 The rst iteration: successes and problems
Topics in Software Engineering (TSE) was on the whole a success, suciently so that in 96/97 I changed the course incrementally and gave it again. There were three parts to the course: let us examine each in turn. (The original OU course also included a section on concurrency using CSP, which we omitted: concurrency was already well covered in our nal year.)
- Structured analysis and design using the Yourdan Structured Metho d. We abbreviated the intro ductory section, since our students had a greater back- ground in software than the OU course assumed, and we emphasised the solv- ing of design problems. We (students and sta ) felt that the problem solving nature of the course was very valuable, and esp ecially that getting students to address problems in sup ervised groups was useful. However, we were less happy ab out the particular paradigm and metho dology involved (structured metho ds, sp eci cally YSM): we wanted to consider teaching OOA/D instead. We had no to ol supp ort for YSM; one consequence of this seemed to b e that the weaker students, who made a large numb er of essentially syntactic errors in their YSM diagrams, didn't get as far as considering the more interesting mo delling issues.
- Rigorous sp eci cation using VDM. This was the least successful part of the course. The Edinburgh degree course, re ecting the research interests of the ma jority of the sta , has a slightly higher than usual formal content, so this was not the rst rigorous sp eci cation language students had b een exp osed to. While some students enjoyed the material, few saw it as very relevant to their needs. In the second year of presentation I deemphasised the actual writing of VDM sp eci cations and emphasised instead the question of what techniques are appropriate under various circumstances; but this was still felt to b e an unsatisfactory section.
- Issues of large scale software development: pro ject planning, management and quality assurance. This section was seen as particularly relevant to the students, esp ecially those planning to enter a career in software engineering. We supplemented, and in the second year of presentation replaced, the OU material, and emphasised real world exp erience and the absence of silver bullets. Final year students are mature enough to appreciate discussion of
{ The third year has a compulsory course in Programming Metho dology. This p opular course provides a thorough grounding in the software lifecycle. On the technical side it discusses p ossible structures for large systems using the ML mo dule system as a source of examples and exercises. It considers reliability and safety of systems and discusses the in uence of human factors. An optional third year course was Software System Design (SSD), which its lecturer Dr Rob Po oley was inclined to think could b e improved. This course taught the concepts of ob ject oriented design in the context of C++, and backed this up with semi-formal sp eci cation of C++ programs. The twin problems were that the ob ject concepts were tending to get swamp ed by de- tailed concerns ab out the sp eci cation language, and that the to ol asso ciated with the sp eci cation language was unsatisfactory. The basic motivation of the course, to provide a go o d basis in ob ject orientation, was ne. Third year students undertake two ma jor pro jects, one of which is individual, and the other of which is done in groups. { Fourth year students do an individual pro ject, which normally involves some conceptual work and the development of a system.
3 The full reform
Dr. Rob Po oley (the lecturer of the third year course, SSD) and I agreed that it would b e a go o d idea to replace b oth SSD and TSE with an integrated pair of new courses teaching ob ject oriented and comp onent based analysis, design and programming. These courses b ecame known as Software Engineering with Ob jects and Comp onents 1 and 2, with SEOC1 b eing a prerequisite for SEOC2. We pro duced syllabi for the courses, and the department agreed to pro ceed. This section discusses the decisions we made ab out the new courses. We felt that it is imp ortant for students to have a thorough understanding of ob ject concepts and detailed design b efore they can sensibly attempt analysis and high-level design issues. Therefore SEOC1's resp onsibility is to teach ob ject concepts in the context of an ob ject oriented programming language, and to cover detailed design without exp ecting students to b e adept at making architectural decisions. SEOC2 deep ens this understanding and considers high-level design and analysis issues, as well as addressing the pro cess of software engineering within an organisation, including topics such as quality, quality assurance and management. We wanted to use a class-based ob ject oriented language, and b ecause of our intention to b e seen as immediately relevant to students intending to go on to industry, we wanted to use a well-known language. Our main options were C++ { which was obviously the favourite, since we already taught that language and since our students already know C { Smalltalk and Java. We settled on C++ for the rst year of presentation, in uenced partly by the unavailability of a CASE to ol supp orting Java on Solaris at that time. Although I have taught a successful ob ject orientation course using Smalltalk, I felt that, given their backgrounds, our students were more likely to b e happy with a typ ed language,
and that exp ecting them to make two paradigm shifts in one course { to ob jects and away from static typing { on one course was probable unwise. In future we exp ect to use Java, but we wish to avoid tieing the courses inextricably to any one language. We aim to make clear to students which asp ects of SEOC1 are particular to the programming language b eing used, and also that most asp ects are not. SEOC2 has no explicit programming language dep endency, though of course it draws on students' exp eriences with an OOPL.
The remaining questions were ab out metho dology and mo delling language. The latter question was rather easy: at around this time it was b ecoming clear that UML, the Uni ed Mo delling Language, was going to b ecome a standard. We felt that if we chose any other mo delling language we would have to switch again within a few years, that UML was a very interesting development in any case, and that UML was the b est b et for the employability of our students. Learning to use a mo delling language comp etently, like learning a programming language, involves understanding its syntax, semantics and idioms. It do es not automatically pro duce the ability to write go o d designs, but it facilitates the expression of designs. Therefore we decided that one aim of the two courses was that students should b e comp etent in UML by the end of them. This decision made us, in 97/98, an \early adopter" of UML, which brought its own problems in the lack of a suitable textb o ok. There were go o d textb o oks on ob ject oriented design, and there were b o oks at a professional level ab out UML; but there was no textb o ok which taught ob ject oriented design with UML as its mo delling lan- guage. Rob Po oley and I decided to address this problem by writing such a b o ok ourselves; Using UML: software engineering with objects and components [1], is to b e published by Addison Wesley in Novemb er 98. Another problem was that the UML do cumentation [2], which is under revision, is in places contradictory and confusing; however, we do not feel that the problems we faced were in prac- tice any harder than they would have b een with another mo delling language; rather, the existence of a (partly) rigorous semantics do cument made it easier to exp ose inconsistencies that otherwise might have remained hidden in less formal do cumentation.
The question of a metho dology to use was harder. We considered teaching the infant Ob jectory (the metho dology from Rational designed for use with UML), Bo o ch's OOD or Rumbaugh's OMT. However, no one of these was clearly the most suitable. More seriously, I harb oured serious doubts ab out whether it was useful to lab el the software development pro cess with a metho dology name. It seemed, and seems, to me that metho dologies b orrow greatly from one another and that successful software development pro jects (including, but not limited to, those I had b een p ersonally involved in) normally adapt and b orrow from di erent metho dologies. I susp ect that pro jects which \use the Bo o ch metho d" for example, often mean little more than that they use the Bo o ch notation; the rise of UML may make this clearer. In the end we decided to teach some common techniques for analysis and design, and to discuss some ma jor metho dologies brie y, but not to advo cate any particular metho dology or teach one in detail. This decision is still under review, but our initial impression
we have (Sparc 5s with 32Mb RAM) its p erformance was irritating. We are considering switching to NT. { The only area of the syllabus that caused widespread diculty was design patterns. I susp ect that this was purely my fault: I was immersed in patterns in my own research, and probably failed to imagine myself into the p osition of someone who hadn't seen patterns b efore.
The CS3 course SEOC1, whilst p opular, do es not seem to have b een such a sp ectacular success as SEOC2, probably b ecause it is more similar in style to other courses. However, it is a clear improvement on the course that it replaces.
5 Conclusion
At the time of writing, these courses have b een taught once each, and b oth app ear to b e successful. We think the main area for further improvement in the coming year is the SEOC2 coverage of architecture, frameworks and patterns, which were squeezed this year by the need to teach UML from scratch. These areas seem increasingly imp ortant, and will reinforce the existing coverage of reuse and comp onents. We hop e that readers who are involved in similar situations to our own may nd our exp eriences interesting. We would b e interested to hear ab out comparable exp eriences elsewhere.
5.1 Acknowledgement
I thank Rob Po oley, who was my main collab orator in the reform discussed here.
References
- Rob Po oley and Perdita Stevens, Using UML: Software Engineering with Ob jects and Comp onents. Addison-Wesley: to app ear, approx Nov. 1998.
- UML1.1 Notation Guide and Semantics, available from http://www.rational.com/uml/do cumentation.html
- Op en University course M355, Topics in Software Engineering: further informa- tion available from http://www.op en.ac.uk/OU/CourseDetails/m355.html
