Object Oriented Programming at the University of St Andrews

At the University of St Andrews the programming module, Computer Science (CS1002), is mandatory for all first year students on the BSc Computer Science courses and is offered as an elective to other students. The majority of the students studying the module have no previous programming experience. The entrance requirements for the BSc Computer Science course was BBBB at Scottish ‘Higher’ Grade (at least one ‘Higher’ pass is required in a science subject). A pre-requisite of the CS1002 module is a credit pass in Standard Grade mathematics or equivalent. The module is worth 20 credits and comprises one-third of the students’ studies in Semester 1. Students cover object-orientation, basic constructs and data in preparation for a more advanced programming module, Internet Programming, in Semester 2. The module is taught with continuous assessment throughout the semester contributing to 40% of the final grade. An examination set at the end of the semester constitutes the remaining 60% of the grade.

The Java programming language is used to teach programming concepts, through the Together IDE (www.borland.com). Students receive four one-hour lectures, a one-hour tutorial session and a three-hour laboratory session each week. The aim of the module is to develop students’ skills in the use of modelling tools and object-oriented programming whilst introducing them to computer science and the concepts of software design and programming. The objectives of the module are to:

 Be able to design simple object-oriented (OO) models using an OO design notation and supporting software tools.

 Be able to implement an OO model in a high-level OO language using objects, classes, inheritance, arrays, conditionals and iteration.

 Be conversant with effective documentation, layout, debugging and testing.

 Be aware of a selection of current areas of interest in Computer Science.

To contextualise the observation process, problems encountered and feedback notes, the following section outlines the practical exercises undertaken

4.3.1 Practical exercises

Weekly exercises cover expression, conditionals, methods, classes, code design, iteration, arrays and inheritance. Each weekly practical typically comprises one or two substantial exercises. Each exercise is divided into sections, with the accompanying handout detailing the stages required for each section. The handouts towards the beginning of the semester are more detailed than those towards the end of the semester, when students need less guidance. In addition to writing a program, the student is required to write a document of their program design and include textual answers to pertinent questions. For example, in week 5 when the students are introduced to Classes they are given the following problem statement:

In this practical you have been elected as the Treasurer of SAM, theSociety for

Accumulation of Members. You decide to write a simple accounting system to keep the society's books.

The Society for Accumulation of Members is a new society and starts off with no money. It receives income from an SRC grant; from members' subscriptions, and from selling tickets for a dance. It spends money to produce posters advertising the dance, to hire a dance hall and to hire a band. It keeps its money in a bank account and a cash box, and has no other assets or liabilities.

During the year, SAM has 12 financial transactions. (Transactions are listed with descriptions, amounts, and account). These 12 transactions are the essentialinputto SAM's accounting system. Theoutputis a statement of SAM's financial position at the end of the year, like this (required output is displayed). TheIncome & expensessection shows where money has come from and where it has gone. It ends with a surplus, which is the excess of income over expenses. TheBalance sheetshows where any remaining money is now. Notice that the

year's surplus is copied from the SURPLUS section to the LIABILITIES section. This is not a mistake; it is part of the double-entry book-keeping system, and ensures thatTotal assets

andTotal liabilitiesare equal. In other words, that the books balance. The accounting system consists of the Account class. Each line ofIncome & ExpensesorBalance Sheetwhich has an amount is an Account object. For example, Thestationeryaccount records stationery expenses. Some of the accounts are totalling accounts. For example,Total incomeis the total of the three separate income accountsSubscriptions,Dance ticketsandGrant. The accounting system is to do this totalling automatically. Each account is alsonormally in credit

ornormally in debit. The convention is that income accounts are normally in credit, balance and expense accounts are normally in debit. This simplifies the appearance of the financial statement, since otherwise (for example) income and expense accounts would have to have opposite signs, as would assets and liabilities. By following the convention, a minus sign only appears in the statement if an amount is the opposite sign of what is normally expected for that account.

Credit and debit are easily represented as positive and negative — but which is which? If you think of money as flowing from income (normally credit) accounts to balance (normally debit) accounts, and then from balance accounts to expense (normally debit) accounts, then it follows that credit is best represented as negative and debit as positive.

To implement this, each account records its balance as a signed number, with the convention that negative is credit, and positive is debit. Each account also records (with a boolean variable) whether it is normally in credit or normally in debit. When the account balance is printed, a minus is used only if the amount is not of the normal sign.

Each of the 12 transactions is balanced: it moves an amount of money from one account to another. This is implemented by subtracting (ie crediting) the amount from one account and adding (ie debiting) it to another. No money is created or lost. The total of all the account balances is always zero.

This extended problem statement is part of a larger documentation set for this practical exercise. Students are expected to write a constructor, create objects, write and use instance methods and follow object references for this practical exercise. In addition to this, students are required to write a document describing how their program works. A statement of the learning objectives precedes this description and guidance on solution design and implementation together with sample test cases follows. In all, the document spans 15 pages.