Incorporating Software Engineering Practice in Compiler Construction Course

Incorporating Software Engineering Practice in Compiler Construction Course 8 th Workshop on “Software Engineering Education and Reverse Engineering”, Durres, 8 – 14. September 2008. Goran Šuković, University of Montenegro 1/27

Agenda • Resources • Course structure • Teacher’s view • Students’ view (excuses) • Why students’ projects fails? • Reorganizing the course • Conclusion Goran Šuković, University of Montenegro 2/27

Resources • My own experience (12 years) • William M. Waite - “The Compiler Course in • • Today’s Curriculum: Three Strategies” William G. Griswold – “Teaching Software Engineering in a Compiler Project Course” ACM Journal of Educational Resources in computing, Vol. 2, No. 4 Hong Liu – “Software Engineering Practice in an Undergraduate Compiler Course”, IEEE Transactions on Educations, Vol. 36, No. 1 Goran Šuković, University of Montenegro 3/27

Course structure • Number of ECTS credits: 6 • Prerequisite knowledge – Students must have a prior knowledge of programming in C. • Prerequisite courses – Programming I (Intro to C Programming) – Programming II (Algorithms & Data Structures in C) • Project oriented course Goran Šuković, University of Montenegro 4/27

Course structure - Workload • Lectures: 14 x 2 hr 15 min lectures. • Practicals: 14 x 1 hr 30 min practical. • Assessment: – Midterm – 3 hours written exam (worth 35 marks) – Final – 3 hours written exam (worth 35 marks) – Homeworks – 6 HW (worth 4 marks on average, 4 programming and 2 written) – Quizzes – 3 quizzes (worth 2 marks each) Goran Šuković, University of Montenegro 5/27

Course structure - project • Small compiler from Decaf to MIPS – Lexical analysis (using lex/flex/jflex) – Syntax analysis and AST (using bison/jbison/cup) – Semantic analysis – Code generation from AST • Two students in team Goran Šuković, University of Montenegro 6/27

Teacher’s view • Course organized as “software project course” – Close to traditional “have the students write a compiler” – Focus on teaching software development techniques rather than compiler algorithms – Unfortunately, can’t use OO design and implementation methodology Goran Šuković, University of Montenegro 7/27

Teacher’s view • Software process designed around a syntax-directed specification • Risk-driven approach – Each team’s measure of success is translated to grade. Their primary risks are correctness and schedule: if the compiler is buggy or turned in late, the team’s grade will suffer Goran Šuković, University of Montenegro 8/27

Teacher’s view • Reuse – Using libraries • Use of tools – Generators encapsulates the process of constructing software components from problem specification – Flex, Bison, Sable. CC Goran Šuković, University of Montenegro 9/27

Teacher’s view • Design patterns – Slightly modified “Composite” pattern – syntax analysis – Flyweight – entities whose state is independent of the tree node that reference it – Visitor – separate the structure of the tree from the computations that take place upon it Goran Šuković, University of Montenegro 10/27

Teacher’s view • Team management – Ad hoc management techniques could suffice Goran Šuković, University of Montenegro 11/27

Students’ view (excuses) • We ran the compiler on all your practice test • • cases, so we figured it was OK. Getting built-in types to work was easy, but we couldn’t get the compiler to work for userdefined types. The lab’s computers were too overloaded, so we couldn’t finish in time. I had to wait for my partner to finish before I could start. My partner didn’t finish his part. Goran Šuković, University of Montenegro 12/27

Students’ view (excuses) • We worked on it all week but we couldn’t finish • • • in time. My partner and I tried to integrate our code the day before the deadline, but we couldn’t get it to work in time. I did the first project, so it was my partner’s turn to do the second project. I thought my partner was working on the project, but I found out last night that my partner dropped the course/is ill/traveled home. Goran Šuković, University of Montenegro 13/27

Why students’ projects fails? • These reasons are largely unrelated to compiler design per se, or to the students’ understanding of it. Each reason falls into one or more classic causes of software project failure: – Software design – Testing – Use of tools – Scheduling – Teamwork and communication Goran Šuković, University of Montenegro 14/27

Why students’ projects fails? • Software design. Students were incapable of • examining the software requirements, team strengths, project deadlines, and other factors to guide their design efforts. Such low-level problems later led to failures in communication, scheduling, etc. Testing. Students did not have a clear idea of what it meant for their systems to be reliable, did not know if their software was reliable, and did not know how to test their software in a systematic fashion Goran Šuković, University of Montenegro 15/27

Why students’ projects fails? • Use of tools. The students did not know how to • use debuggers, compilers, generators, etc. , to manage the software and their projects Scheduling. Students failed to allocate enough time for the project, presumably due to competing demands on their time, unfamiliarity with compiler construction, and lack of experience in building a system that takes more than a couple of days to build Goran Šuković, University of Montenegro 16/27

Why students’ projects fails? • Teamwork and communication. Students failed to work effectively with their partners, presumably because they were unaccustomed to team projects of any length. Responsibilities outside the class were likely a contributing factor as well Goran Šuković, University of Montenegro 17/27

Reorganizing the course • To eliminate the students’ failure modes and • address their feelings that the course was unfair, I refocused the course theme around compiler construction as an example of complex system construction Since domain knowledge is a vital prerequisite to successful system construction, traditional compiler material would not be replaced, only augmented and enriched, by more general software engineering knowledge Goran Šuković, University of Montenegro 18/27

Reorganizing the course • Rewriting set of notes for students - the classical • organization of most compiler texts emphasize algorithms and data structures rather than the design issues that most trouble students “Sensitization” – presenting the particular challenges the students will face in their project, conveyed both as stories about prior projects and the specific failure modes listed previously Goran Šuković, University of Montenegro 19/27

Reorganizing the course • “Sensitization” alone is not adequate – Many students seem immune to these warnings, perhaps due to over-confidence or handholding in previous courses – Project will be graded solely on how well it performs on our rigorous test cases, late projects will be severely penalized, and all members of the team receive the same grade. This provides both an unambiguous and realistic context for the application of software engineering Goran Šuković, University of Montenegro 20/27

Reorganizing the course • Putting project in context – Many students feel that hard work should be rewarded, or exceptions allowed – Students are reminded that a software product’s success is measured by the benefits it brings to its users (i. e. , usefulness), and consequently to the company that developed the software (e. g. , profits from sales) Goran Šuković, University of Montenegro 21/27

Reorganizing the course • Putting project in context – Remind the students that software is everywhere, including life-critical systems such as nuclear power plants airplanes, medical equipment, and banking. Consequently, quality software is not just a classroom topic, but a responsibility that the students will carry with them daily as software developers. – With this context, I explain that the rules established for the class are no different than what is expected of them outside the classroom Goran Šuković, University of Montenegro 22/27

Reorganizing the course • Specification – Due to time constraints, it is not feasible to teach students how to write specifications, especially since they likely have no experience doing so. The focus here is on the first step, learning to use a specification • Design – Likely some form of object-oriented design (OOD). Unfortunately, only part of the students have experience with OO programming, due to different backgrounds Goran Šuković, University of Montenegro 23/27

Reorganizing the course • Team management – Students are advised to work together at a common location at least two times a week to minimize communication problems – Since the project is too large to be completed by one person, each member has to contribute equally if the project is to succeed Goran Šuković, University of Montenegro 24/27

Reorganizing the course • Team management – It is suggested that they each take responsibility for a portion of the grammar rules (i. e. , a portion of the specification) – Labor may be divided by task specialization. In a typical division, one student designs and implements the code, the other writes and performs the tests. This is especially effective for teams that possess a clearly superior designer/coder. Goran Šuković, University of Montenegro 25/27

Conclusion • Course still need further improvements • Changes in curriculum dictates structure of course • More information – www. pmf. ac. me – compilers@rc. pmf. cg. ac. yu Goran Šuković, University of Montenegro 26/27

Thank you Questions? Goran Šuković, University of Montenegro 27/27