We acknowledge and celebrate the First Australians on whose traditional lands we meet, and whose cultures are among the oldest continuing cultures in human history.
What you need to know before you can start this course (the prerequisite knowledge) is an introductory skill with object oriented programming, such as the course COMP1110, 1510 or COMP6700.
The courses COMP1710 or COMP6720 are not enough!
you need to be able to design and implement programs in a language like Java (or C++ if you insist).
How complicated?
== != > >=,and (written & or &&), or (written | or ||), and not (written !) as used in if-statements and loop controlsSystem.out.println("x =" + x);
class BBB extends AAA{ ... }
An introduction to the course, including discussion of the proposed assessment scheme, the textbooks, labs and tuts, roles and responsibilities of teachers and students.
To deal with administrative details so that we don't have to spend much more time on them.
To introduce the class web site.
To introduce the project software.
To communicate our expectations.
|
Lecturers: |
Associate Prof Chris Johnson(course convener and main lecturer) |
Dr Elisa Baniassad (lecturer, weeks 3–6) |
|
Tutors: |
not yet final as at 18/2/12 |
|
|
Web Site: |
The website is in Wattle. |
|
|
E-mail: |
COMP6442 has the same content as COMP2100, in the same shared classes.
COMP2500 will be mostly the same as COMP2100 and the three courses
will be run together.
There will be some extra content and some extra
assessment for software engineers in COMP2500 — as befits your
elite status, abilities and responsibilities.
There is no choice as to which course you enrol in. If you are doing the Bachelor of Software Engineering, you must enrol in COMP2500. If you are not doing the software engineering degree, you are not allowed to enrol in COMP2500. You must enrol in COMP2100 instead; if yo are a Masters student, you must enrol in COMP6442.
All three courses will do the same homeworks and share the same major assignment project.
revised in 2011
The planned learning outcomes for the course are that students should be able
Subversion tool)
JUnit tool)
Make or Ant tool)
See the Wattle-linked Assessment Page for details.
The assessment items for comp2100, comp2500, comp6442 are
assignment
tests learning objectives 1, 2, 3, 4, 5
selected homework tasks
test learning objectives 1, 2, 3,4, 5
midsemester theory exam
tests learning objectives 2, 4 and 5
final practical lab exam
tests learning objectives 1, 2, 3
final theory exam
tests learning objectives 2, 4, 5
COMP2500 also has assessments
team research topic presentation
tests
learning objective XX (research and verbal and visual presentation)
individual report on another presentation
tests learning
objective YY (written report)
Only a selection of the homework programs will be assessed: your best 10.
currently planned for Wednesday week 6, 28 March at 9am in the Physics Lecture Theatre - same place and time as the normal lecture class.
There will be no required texts for Software Construction in 2012. None of the available books covers everything we are going to do, so you would have to buy several. Instead the course web site will contain comprehensive lecture notes, and you will be introduced to the common working software developers' resources: online tutorials and software documentation.
If you want to buy a book consider one or more of the following recommended books:
Java the Complete Reference (7th
edition)
Herbert Schildt
McGraw-Hill 2007
Big Java (3rd edition or later )
Cay Horstmann
Wiley
Horstmann is not as good for reference as Schildt
Introduction to the Personal Software Process
Watts
S. Humphrey
Addison Wesley, 1997.
The Pragmatic Programmer
Andrew Hunt & David
Thomas
Addison Wesley, 2000.
Beautiful Code
Andy Oram and Greg Wilson
O'Reilly
2007
Code Complete
Steve McConnell
Microsoft Press,
1993.
The Pragmatic Starter Kit Series.
Volume I:
Pragmatic Version Control (Subversion) by M. Mason
Volume II:
Pragmatic Unit Testing (JUnit) by A. Hunt &D.
Thomas
Volume III: Pragmatic Project Automation (Ant) by M.
Clark
The Pragmatic Bookshelf, 2004-2005
or see The Pragmatic Programmer web site.
Other references:
Object-Oriented Software Construction (second
edition)
Bertrand Meyer
Prentice-Hall, 1997.
For more information on reading material, names and library codes of other relevant books, see the Lecture Notes by Topic page.
Class times, topics, and the schedule of the course all come together on the COMP2100/2500/6442 Schedule Page.
The lectures help you learn all of the theory and the basic ideas of the practice objectives. They contribute most to learning objectives 1, 2, and 4.
Monday 1 pm, Physics Lecture Theatre
Tuesday 4 pm, Physics Lecture Theatre
Wednesday 9 am, Physics Lecture Theatre
As there are 13 weeks and 3 lecture times per week, that would give 39
lecture times in all. At the moment I plan to have 33
lectures including review lectures. Some of the 33 are reserved for COMP2500 communications skills and presentations. Week 9 (30 April) will be free of lectures - this date to be confirmed.
See the Schedule
Page for the latest up-to-date information which will be
updated frequently.
The labs are designed to follow soon after the lectures on the
same topic, so that you can develop what you are learning in practice.
You will generally work in small groups, intensively, sharing, learning and presenting your results to the class. These are dynamic, sometimes noisy, creative small group work, for experimenting and learning from each other.
Lab class are 2 hours long, in even numbered weeks of the teaching semester 2,4,6... (odd numbered weeks of the year).
Choose your practical classes: register using the Streams system this week. You can do this from any computer connected to the internet by going to https://cs.anu.edu.au/streams.
Marked assignments will be returned in your lab class. Homeworks will be marked but only the mark will be returned to you; the feedback comes in the Monday lecture class following the homework week deadline. If you really don't see why your attempt got the mark it did, you can consult the tutors at times to be arranged.
If you miss a lab class, you are strongly encouraged to do the same exercises in your own time. Remember that the final exam is a lab exam, so it will be testing the practical skills learned in the labs. Similarly if you don't complete the lab exercises in class, finish them as soon as you can.
Homework is designed for practising and developing your programming skills. Not all of the exercises are compulsory (it's only a few marks) but I reckon they are essential.
Students in previous years said that doing the homework was one of the most helpful parts of this course. It improved their skills and confidence enormously. To provide an added incentive for you to do the homework, I guarantee that one of the homework exercises will be on the final exam, only slightly modified.
Each homework exercise consists of a small Java program that you have to write. Once you have started learning the PSP (that is, starting next week), you should follow the prescribed process carefully while you write the program, recording the time you spend in each phase of development, and also recording all the errors you make. This will make you a much better programmer— guaranteed. For more information, see the Homework Page.
There is a Wattle activity each of the early weeks that asks you to note your estimates of size and time needed, and the actual size and time, and the defects (errors) for that week's homework. This activity does not count towards your final mark, but it's a reminder to estimate and log to help you improve yourself.
The technical matters we'll cover are basically methods and techniques for constructing software, starting from a given high-level design. These methods become more important the larger the software you are working on.
Programming to precise specifications.
abstraction in program design and construction
Configuration management and build tools.
Graphical user interfaces.
command language Scripting.
unit Testing.
Recursive (and other) data structures.
elementary Unified Modelling Language UML class diagrams as a design notation
personal software process.
One of our main aims for this course is to give you an opportunity to develop experience and competence in working with larger programs. To do this we have structured the assignments around a project, to which you will contribute some development.
Since most of the technical topics we have to cover are independent of each other, we 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 2012 is to continue the development of a prototype preview system for users of SVG, the scaled vector graphics format for graphics files. The scenario is that designers prepare their pictures using a drawing application, or by hand. The resulting document describes a picture that can be renbdered by many Web browsers and other tools. Our tool called Gaga is a simple renderer, implemented using Java Graphics 2D but you will be adding functionality to transform the pictures in several ways and to add extra effects.
We will do this using some pre-existing software and some software written specially for this purpose. The first step in the processing scans and parses that XML format to produce a data structure called a parse tree, represented in a recursive data structure called an abstract syntax tree. The next step is to manipulate that tree to render the picture, or to produce descriptions of new modified pictures, and to extract information (like structural measures of the SVG source, and metadata). You will be working on a Java program that performs all these steps from the scanning onwards to processing the document structure, analysing it, modifying it, rendering with Java graphics, and converting the document into a different formats.
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/2500/6442 students could do in a semester. So you will not be building the whole program, but instead working on some 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 group. The plan for the group is to develop the software in stages. When you join the group, others have already constructed a prototype that performs some of the central functions of the finished program.
The prototype performs some of the functions of the finished program, but lots of features are missing. Your task in the Assignment will be to expand the program in some major way. 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 course.
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.
The PSP is a recommended part of COMP2100/2500/6442, but it will not be assessed.
A course 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 join in peer assessment honestly and helpfully — your peers are the other students, and students learn very well from each others' immediate experiences
To participate in the lectures, labs, homework, assignments and exams.
To engage with the course 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 (academic honesty, no plagiarism), and to work fairly in your teams.
See the Plagiarism and Academic Dishonesty Notes on the Wattle course website. It says in part:
You are expected to work together to study, it's really useful. But it's only OK to go so far, and no further. You have to stop before you work up the solution to the assignment together. How far can you go in a group? Here are some guidelines from the San Franciso State University Dept of Computer Science:
it is acceptable to discuss the meaning of assignments and general approaches and strategies for handling those assignments with other members of the Academic Community
[this means other students, staff, tutors, anywhere in the university or beyond: in residential college, a private paid tutor, another university, on the Internet].Any cooperation beyond that point, including shared pseudocode or flowcharts, shared code, or shared documentation, is only acceptable if specifically so permitted by the class instructor in written guidelines distributed to the entire class
[which means when the assignment specification or conditions say: "this is a group or team assignment" and not in any other case].
San Francisco State University Dept of Computer Science Department Policy on Academic Cheating and Plagiarism.
[The explanatory parts in square brackets were added by Chris Johnson ANU]
Our Responsibilities
We (lecturers, 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 course description.
To support you as you learn the Personal Software Process, programming tools, and theory concepts.
To provide you with accurate and timely information about the course.
To treat you fairly and respectfully.
To provide a model of professionalism.
To the community:
To assess and certify your individual competence.
There is only one of me, and many of you. In order for us to get along this semester, you need to know what I expect of you, not just for assessment, but also in terms of behaviour.
Punctuality: I plan to 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 us is likely to be that we am no longer able to finish the lecture on time. Please be here, seated and ready to start taking notes by 4 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: my office hours are very variable. I am also Associate Dean (Education) of the ANU College of Engineering and Computer Science so I have many other appointments all over the week. Using the course discussion forum is a good way to get abswers from your fellow students. If you really need an answer from the lecturer, don't rely on the forum (which is for student discussions): electronic consultation by direct email is the most efficient way to ask me a question. If I answer you by saying "please come and see me" it means that I think it's better discussed directly rather than via computer, not that you have done anything wrong. If I answer you in the forum it means that I think it's a good question and everyone will benefit.
When you email, please put COMP2100 or COMP2500 or COMP6442 in the subject line
- otherwise they will probably disappear into spam, and I won't know
which course it's about.
You may send email to
Chris
Johnson@anu.edu.au - subject comp2100
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. The assignments in this course are quite long and difficult. That's because they're meant to be. So you need to pace your work on them - start early to get an idea of how easy or difficult it will be: it's very hard to tell just from the first glance, and it's too easy to get into behaviours of denial and procrastination if it looks like it's hard. If you are working in a team, organise early with your partners.
Email: 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 maybe will be informed, and will maybe 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 student 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.
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. Don;t give up on the course! but learn what you limits are.
Contact your tutor for all questions about: labs, your assignment marks (in the first instance).
apply for Special Consideration (extensions etc.) using the form at the DCS office.
Contact CECS Helpdesk (the technical support group- the sys admins) for anything operational with computers and labs.
Chris Johnson for anything to do with the content of the course and assignments.
Copyright © 2006 –2011
Ian Barnes, Alexei Khorev, and Chris Johnson, The Australian
National University
Version 2011 $Revision: 2.12 $
$Date: 2011/02/16 $
Feedback
& Queries to comp2100@cs.anu.edu.au