Lectures: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29]COMP2100
Lecture 1: IntroductionSummary
An introduction to the course, including discussion of the proposed assessment scheme, the textbooks, the information pack, labs and tuts, roles and responsibilities of teachers and students.
Aims
To deal with administrative details so that we don't have to spend any more time on them.
To introduce the class web site.
To introduce the project software.
To communicate our expectations.
Important information
Lecturer: Dr Ian Barnes, Mr Richard Walker Tutors: Dr Alexei Khorev, Dr Tamiru Jarso, Mr David Excell Web Site: http://cs.anu.edu.au/student/comp2100/ E-mail: comp2100@iwaki.anu.edu.au
Unit Objectives
By the end of this unit, students should be able to:
Carry out all aspects of the detailed design and construction of a moderate-sized Eiffel program system (103 to 104 lines of code), given a well-elaborated architectural design for the system.
Use and analyse a personal software process in constructing a software module.
Have an understanding of the main characteristics of the C programming language in the construction of program systems.
Be able to carry out system modification and maintenance, given changes to the architectural design.
Assessment
See the Assessment Page.
Textbooks
There will be no textbooks for COMP2100 in 2004. All the relevant books are poor value for money in my opinion. None covers everything we are going to do, so you would have to buy several. Instead the course brick will contain comprehensive lecture notes, together with selected readings from relevant books and manuals.
If you really want to buy a book, and have lots of money to spare, then consider one of the following recommended books:
Object-Oriented Software Construction (second edition)
Bertrand Meyer
Prentice-Hall, 1997.Introduction to the Personal Software Process
Watts S. Humphrey
Addison Wesley, 1997.The Pragmatic Programmer
Andrew Hunt & David Thomas
Addison Wesley, 2000.Code Complete
Steve McConnell
Microsoft Press, 1993.For more information on reading material, names and library codes of other relevant books, see the Reading Page.
Information Pack: Contents
(Almost) complete lecture notes.
Complete lab instructions.
RCS: A System for Version Control
The bash manual
PSP forms, scripts and instructions
Past exam papers
For a bit more information, see the Reading Page (or the brick itself...).
Note that all the information in the brick is available elsewhere, so there is no compulsion to buy it. I recommend that you do, because it is convenient, but it is up to you.
Information Pack: How to get it
Go to the university cashier in the Manning-Clark centre foyer, and pay $26.
Take your receipt to Sam at the DCS front office (Level 3, CS&IT Building).
Exchange the receipt for one thick red brick plus one pad of PSP forms.
Technical Stuff
The technical matters we'll cover are basically methods and techniques for constructing software, given a high-level design. These methods become more important the larger the software you are working on.
Programming to precise specifications.
Configuration management and build tools.
Graphical user interfaces.
Scripting.
Testing.
Recursive (and other) data structures.
Reading code written in the C programming language.
Calling C code from Eiffel.
Software process.
Code reviews.
The Project
One of my main aims for this unit is to give you an opportunity to develop experience and competence in working with larger programs. To do this I have structured the assignments around a project, which you will develop in stages throughout the semester.
Since most of the technical topics we have to cover are independent of each other, I have scheduled the lectures and labs so as to give you the information and skills you need for each stage of the project, when you need them.
The project for 2004 is to build a prototype "preflight" system for an academic journal. The scenario is that authors prepare their articles using an MS-Word template file. They submit the article electronically. The publishing system reformats the article for web and paper publishing and shows the results to the author who can then check that everything came out OK. The system also has to extract document meta-data like title, author's name and address from the document for use in table of contents, index etc.
We will do this using some pre-existing software and some software written specially for this purpose. The first step in the process is to use the OpenOffice package to convert the MS-Word proprietary format into an XML-based format that we can work with. The next step is to scan and parse that XML format to produce a data structure called a parse tree. The next step is to manipulate that tree to produce new documents (like the web version of the article) and to extract information (like the metadata). You will be working on an Eiffel program that performs these last two steps.
While this is a fairly small software construction task - the finished program will consist of a few tens of classes and a few thousands of lines of code -- it is far beyond what most COMP2100 students could do in a semester. So you will not be building the whole program, but instead working on three crucial stages in the development.
If you like, you can think of this as what might happen if you were a programmer working in a team. The plan for the team is to develop the software in stages. When you join the team, others have already constructed a prototype that performs some of the central functions of the finished program.
Your task in Assignment 1 will be to take a detailed specification for one component of the software and produce a test plan, test data and a shell script to automate the implementation of your test plan. You then have to run your tests on that component and write a test report giving details of all its defects.
Assume now that someone else has corrected all the defects in that component, and the project is ready to move forward. The prototype performs some of the functions of the finished program, but lots of features are missing. Your task in Assignment 2 will be to expand the program so that it becomes useful software. This will certainly mean grappling with the parse tree used to represent the document's structure. The parse tree is an example of a recursive data structure, one of the key ideas in this unit.
Assignment 3 will involve working on the graphical user interface of the system. You will be using the EXG (Eiffel X Graphics) library, which is an Eiffel binding for GTK+. GTK is the GIMP Tool Kit, one of the major open-source graphical toolkits available.
Lectures
Lecture Times:
Monday 10am, Manning Clark Theatre 2.
Wednesday 10am, Manning Clark Theatre 2.
Thursday 5pm, Manning Clark Theatre 3.
As there are 13 weeks and 3 lecture times per week, that gives 39 lecture times in all. Subtract two for the Canberra Day and ANZAC Day holidays and it still leaves 37 time slots. At the moment we plan to deliver 29 or 30 lectures, so some lecture times will not be used. See the Schedule Page for the latest up-to-date information.
Laboratory Classes
The labs are designed to follow immediately after the lectures on the same topic, so that you can practice what you have learned.
Register for a group using the Streams system this week. You can do this from any computer connected to the internet simply by going to https://cs.anu.edu.au/streams.
Class times and locations are listed on the Labs Page (or in the Streams system).
Your group will meet for two hours every week starting next week (Week 2).
Assessment will be returned in your lab group.
Homework
Starting next week there will be homework due in your lab class each week. This basically consists of a small program that you have to write. Once you have started learning the PSP, you will have to follow it while you do the homework exercise, recording the time you spend in each phase of writing the program, and also recording all the errors you make. This will make you a much better programmer - guaranteed. For more information, see the Homework Page.
The Personal Software Process
The PSP is the result of years of research on productivity and quality of the work of individual programmers.
It is a disciplined way of writing software which can lead to dramatic improvements in
the quality of the software you write,
your productivity,
the quality of your plans and estimates.
Following a discipline like this can lead to greater self-knowledge, a valuable thing in itself.
In 2000 and 2001, the PSP was an optional part of COMP2100. This year, like the last two years, it is compulsory and will be assessed.
Responsibilities
A unit like this cannot work without everyone involved taking responsibility for their part.
Your responsibilities:
To take responsibility for your own learning. We can give you opportunities to learn, but you have to actually do it.
To participate in the lectures, labs, homework, assignments and exams.
To engage with the unit material; to make an honest effort.
To raise any problems, questions, or suggestions with your tutor or lecturer as soon as possible.
To follow the prescribed parts of the Personal Software Process.
To submit only your own work for assessment.
Our Responsibilities
We (lecturer, tutors, the department, the university as a whole) have responsibilities to you and to the wider community. These are sometimes in tension.
To you:
To help you learn the concepts and skills listed in the unit description.
To support you as you learn the Personal Software Process.
To provide you with accurate up-to-date information about the unit.
To treat you fairly and respectfully.
To provide a model of professionalism.
To the community:
To assess and certify your competence.
My Expectations
There are only two of us, and many of you. In order for us to get along this semester, you need to know what we expect of you, not just for assessment, but also in terms of behaviour.
Punctuality: We will start lectures at 5 minutes past the hour and end at or before 5 minutes to. If you come in late you will miss the start of the lecture, and you will disturb the lecturer and the other students. The result of disturbing me is likely to be that I am no longer able to finish the lecture on time. Please be here, seated and ready to start taking notes by 5 minutes past.
Courtesy: We are not your servants. We do not provide a 24/7 helpdesk service. We are also not perfect. Some things will go wrong this semester. If you find a mistake or a problem, please assist by informing us so that we can correct it. If your language is courteous, we are much more likely to be helpful and courteous in return.
Office hours: (Ian) I cannot get through all the work associated with running this course if I am interrupted all the time. If you need to see me, please come during my advertised office hours. If you can't make it at those times, contact me by email to make an appointment. If you show up at my door without an appointment I may be too busy to see you. (Richard) See the "door policy" posted on Richard's door.
Assignment deadlines: Part of good practice in software development is to start work well before deadlines. Just because you choose to start late and end up working long hours the night before an assignment is due does not mean that the assignment is too hard or that we are obliged to grant you an extension.
Email: Please send email to whichever lecturer is appropriate. (See the division of responsibilities below.) Always include your full name and your student number.
We will reply to email from off-campus addresses, but only by hitting "Reply". If that doesn't work (which often happens with Hotmail, Yahoo etc), we will send again to your student email address. We cannot store, remember or search for your off-campus addresses. If we need to contact you by email, other than replying to a message of yours, we will send to your student email address. It is your responsibility to check that address regularly, or to find out for yourself how to arrange automatic mail forwarding.
Answering email takes up a large amount of our time. Please be patient. Sometimes it may take a few days for us to answer your email. We will answer messages in roughly the order we receive them, and that may take a few days. Also please do not be offended if you get a very short response, particularly if the answer to your question is already available somewhere on the class web site.
Attitude: It is not unfair or unreasonable of us to set work for you to do, and to assess it. That is our job as the lecturers for this course. If you want to go around with a chip on your shoulder, filled with resentment that we dare set work for you (especially when we're not perfect ourselves), be my guest, but we'll all have a much better semester if you remember what we're all here for.
Ability: Remember that there is a large range of abilities in this class. Some parts of assignments and labs may be aimed at the top students, others are aimed at average students. If you're an average student, you may not be able to complete the harder sections of the assignments, within the deadline or indeed ever. That's OK. If you're aiming at a pass, then passing each assignment (50%) is all you need. Don't spend unreasonable amounts of time trying to complete every part of every task. Accept your limitations.
Division of responsibilities
To avoid inconsistency and the nasty situation of students getting different advice or rulings from different lecturers, Richard and I have decided on a strict separation of responsibilities. If you have a query, ask the relevant lecturer. The other lecturer will not answer.
Contact Richard Walker for all questions about: enrolment in the course, extensions, marks, lab groups, and any lectures given by Richard.
Contact Ian Barnes for all questions about: assignment specifications, homework specifications, the PSP and any lectures given by Ian.
Contact your lab demonstrator for all questions about: labs, your assignment marks (in the first instance).
Lectures: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29]
Copyright © 2004, Ian Barnes and Richard Walker, The Australian National University
Feedback & Queries to
comp2100@iwaki.anu.edu.au
Version 2004.4, 22 February 2004, 19:09:23