CS 3500   Fall 2010
Object-Oriented Design

Overview

Official summary (sightly modified): Presents a comparative approach to object-oriented programming and design, with an emphasis on techniques for programming large-scale systems. Discusses the concepts of object, class, meta-class, message, method, inheritance, and genericity. Reviews forms of polymorphism in object-oriented languages. Contrasts the use of inheritance and composition as dual techniques for software reuse: forwarding versus delegation and sub-classing versus sub-typing. Studies main programming language tools and techniques to facilitate the creation of applications: modularity, encapsulation, code reuse techniques, design patterns. Basic concepts in object-oriented design are illustrated by writing programs in one or more object-oriented languages.

Announcements  

Fri, 17 Dec 2010: Oops. Bug in my implementation of rooms for homework 6. You only ever notice it if an AutonomousPerson moves into a room with no exits. The check for an empty list of exits when picking an exit at random from a room is broken. Method randomExit() in Room should read:

     def randomExit ():Option[Exit] = {
       if (theExits.isEmpty())
         Option.none()
       else
         Option.some(theExits.nth(Util.random(theExits.length())))
     }

Tue, 14 Dec 2010: First off, some people are reporting problems under Eclipse getting the code to compile. One problem seems to be that the Eclipse plug-in is unhappy with my class name Clock. So one solution might be to rename Clock to something like GameClock or some such, and rename all references in Adventure.

Second off, I should remind you that while the exam on Thursday is closed notes, you have the right to a single 8.5"x11" double-sided cheat sheet.

Tue, 14 Dec 2010: I'll be in my office today (Tuesday) and tomorrow (Wednesday) 15:00-17:30, feel free to drop by if you have questions. I may have some short one-on-ones scheduled with students within those times, so if the door's closed, I'd appreciate it if you'd just wait until it opens again before barging in.

Mon, 13 Dec 2010: I'll also be holding office hours on Tuesday and Wednesday, although at this moment I'm not quite sure of the actual times. I should be able to fill out my schedule tonight, and I'll post the times here later tonight.

Mon, 13 Dec 2010: I've uploaded the homework 5 grades on Blackboard. Please have a look at your full set of grades and let me know if anything doesn't agree with your records. In particular, if you received a 0 (usually indicating no submission) for a homework that you're sure you submitted, please inquire. There are a couple of homeworks that I have received out of band and that are in Nick's hands, so those grades should be updated in the coming days.

Mon, 13 Dec 2010: I will be holding office hours today, but I may be late for them, since the whole faculty is in a meeting for the whole day. It should end at 15:00, but who really knows with those things. If I'm not in when you show up, just try again ten minutes later.

Fri, 10 Dec 2010: The submission site is open for homeworks 6. As I mentioned multiple times, I will accept submissions until Dec 17. Please name your submission adventure.zip, and don't forget to include a text file called README.txt describing your team, your extensions, and the classes you modified and how. Please please don't put it in a Word file (or anything else annoyingly proprietary.)

Wed, 08 Dec 2010: Here's the final exam topics sheet that I went over in class yesterday.

Fri, 03 Dec 2010: The lecture notes for the last two lectures, on the Publisher-Subscriber and the Model-View-Controller patterns, are up.

Fri, 03 Dec 2010: The code for this morning's lecture on the Model-View-Controller pattern.

Thu, 02 Dec 2010: Homework 6 is out. I will accept submissions for this homework until Friday, December 17th, the day after the exam. (Extra day because the homework came out a day after the days I said I would make it available. Only fair.) Source code for the homework is in the Homeworks section of the web site, as usual. Look at it, and familiarize yourself with the code. There's a lot in there for you to look at.

As I said in class, for this homework, you may work in pairs. You do not have to, but I strongly recommend it.

Tue, 30 Nov 2010: The code for this morning's lecture on the Publisher-Subscriber pattern.

Mon, 29 Nov 2010: Here's the final exam information I got from Banner -- let me know if your information is different:

     Final Exam   1:00pm-3:00pm  R  Shillman Hall 335  Dec 16, 2010 - Dec 16, 2010

So Thursday Dec 16 in the afternoon.

Thu, 25 Nov 2010: Just a little remark. During Tuesday's coffeeshop chat, the undecidability of the halting problem for Turing machines came up. And I remembered that I mentioned something like that in class, and that I wanted to come back to it, but never did. Let me say something about it here. I claim that there are some problems for which it is impossible to write a program that correctly solves every instance of that problem. (A problem may be "addition of two integers", and an instance of that problem is a pair of integers to add -- that's a problem for which it is easy to come up with a program to solve every instance of the problem.)

The problem I have in mind here is "does a program terminate on a given input?" and an instance of that problem is a program and an input. I claim it's impossible to write a program to solve every instance of that problem correctly. In Theory of Computation, you will see the necessary theory to prove this in general. Here, let me make the argument specifically for Scheme. (Thanks to Michelle for reminding me that there is a simple argument for this.) Concretely, I want to show that it is impossible to write a Scheme function that correctly solves every instance of the problem "does a given one-argument Scheme function terminate when called on a given input?".

I will argue by contradiction. Suppose that you managed to write such a program that you claim correctly decides whether an arbitrary function terminates when called on a given input. Suppose you called that function (terminates? f x), where f is the function you want to check for termination when given input x. I don't care how you managed to write terminates?. Maybe you did something fancy that actually checks the source code of function f and does some fancy analysis on it. The important thing is that (terminates? f x) should return true when (f x) terminates, and return false when (f x) does not terminate (for instance, enters an infinite loop). I show that that supposition, that terminates? exists, is absurd.

If I had terminates?, I could write the following perfectly legal Scheme function:

     (define (loop-forever) (loop-forever))
                                                               ;;
     (define (HP x)
       (if (terminates? HP x)
           (loop-forever)
           1))

Now, (HP 0) either terminates, or it does not. Which one is it? Let's consider both cases.

Case 1, (HP 0) terminates: But then, by assumption, (terminates? HP 0) must be true, and therefore, from the definition of HP, (HP 0) must loop forever, i.e., it does not terminate, contradicting that (HP 0) terminates!

Case 2, (HP 0) does not terminate: But then, by assumption, (terminates? HP 0) must be false, and therefore by definition of HP, (HP 0) returns 1 immediately, i.e., it terminates, contradicting that (HP 0) does not terminate.

Because we get a contradiction no matter what, it must be that what we initially assumed was wrong, i.e., that terminates? works correctly for every function. Because terminates? was completely arbitrary, the argument works no matter what the implementation of terminates? is. In other words, we cannot write a correct terminates? function in Scheme.

Wed, 24 Nov 2010: The last few lectures have been posted to the website. I've also uploaded the code I demoed in classes. Have a good Thanksgiving break!

Wed, 17 Nov 2010: The code for yesterday's lecture on adapters and iterators is up. Remember the challenge I left you with: can you design an adapter that adapts an iterator into a stream? Here's the structure I have in mind:

     class IteratorToStream[T] (it:Iterator[T]) extends Stream[T] {
       ...
     }

Wed, 17 Nov 2010: Lecture notes for Friday (and part of Tuesday)'s lecture on mutation are up.

Mon, 15 Nov 2010: In Question 1(b), when I say "Note that trying to move a person into a container that cannot hold a person (i.e., trying to move a person into another person) should have no effect. We could throw an exception, but for simplicity let's just fail silently." what I mean by "fail silently" is that the operation (attempting to move a person into a container that cannot hold a person) should have no effect, but also not cause an error. Like adding an artifact to the Limbo room.

Also, later tonight I should be updating the Atlas tester so that it works with our new Atlases and Rooms, and get some interactivity going.

Sun, 14 Nov 2010: Homework 5 is out. Due Wednesday 24 Nov, at 22h00. Helper files are provided in the Homeworks section of the web site.

Fri, 12 Nov 2010: Here's the code for the lecture this morning on mutation . The exercise I left you with: add copy() methods to each of the classes that creates a copy of an instance that eliminates any sharing the instance has with other values.

Tue, 09 Nov 2010: When I talked about multiple inheritance in this morning's lecture, I mentioned that Scala has a restricted form of multiple inheritance via traits. Scala uses a linearization approach to "flatten" the class hierarchy and resolve method lookup (as well as super). A description of this linearization approach can be found in this blogpost, while a more careful description appears in Chapter 7 of Wampler and Payne's "Programming Scala", Linearization of an Object's Hierarchy.

Mon, 08 Nov 2010: A few of you have requested a sample solution for the last question of homework 3, where I asked you to add a stream() operation to atlases that returns a stream of the rooms in the atlases. Here is a sample solution, where I add stream() to the implementation of atlases from homework 2, as opposed to a binary-search-tree implementation. The subtlety for this question was to realize that I wasn't asking you to make atlases themselves support the stream operations, but rather require you to invoke stream() on an atlas to get a stream out of it. That's an alternative way to provide a stream interface that has some advantages. (Of course, there are ways of answering the question correctly and still have atlases directly support the stream operations... Think about it if you want.) The way I implemented it, I added two new (private) classes to the implementation to support the stream operations.

Fri, 05 Nov 2010: Here's the code for the lecture this morning on the implementation of measurable lists via delegation . Worth looking at and thinking about.

Wed, 03 Nov 2010: Homework 4 is out. Due Wednesday 10 Nov, at 22h00. Helper files are provided in the Homeworks section of the web site.

Wed, 03 Nov 2010: Here's the code for the lecture on stream gadgets and for the lecture on inheritance and delegation. The latter contains the full code, correcting the problems I ran into there at the end. I've also used inheritance slightly differently than I used in lecture for the reuse of code between the two concrete subclasses of Point. So check it out. Lecture notes for those two lectures are still due, and I hope I'll get to them before bed tonight. Homework 4 is being finished next and should be up soon.

Finally, some statistics about the midterm. The average was 39.8/50 (lower than I'd like), with a standard deviation of 7.7 (could be worse).

Fri, 29 Oct 2010: In an uncharacteristic display of efficiency and proactiveness, the university cleaning crew quite literally garbage collected the box of homeworks 1 & 2 I left outside my office overnight. Meaning that if you have not picked up your homework 1 or 2 and would like to do so, you'll have to drop me an email...

Also, our TA Nick says that he will be available in the lab tomorrow (Saturday) 11:00-14:00, to help folks with homework 3 if help's needed.

Thu, 28 Oct 2010: Made a couple more corrections on homework 3 following feedback from people trying to test their Atlas implementation with the tester from homework 2. (Which you should do too.) Basically added the roomInFocus() method back in the ADT. Also changed the Stream trait from Question 3 to match what we saw in class. Sorry I didn't see the discrepancy earlier:

     trait Stream[A] {
       def hasElement ():Boolean
       def head ():A
       def tail ():Stream[A]
     }

You should download the Stream.scala file again.

Tue, 26 Oct 2010: Following a comment in class this morning, I've updated the support file Stream.scala from homework 3 so that Stream is now a trait, and not an abstract class:

     trait Stream[A] {
       def isEmpty ():Boolean
       def head ():A
       def tail ():Stream[A]
     }

That may make things simpler for some of you, and completely unaffect the rest. You should make that correction, or just download a fresh version of the file, since we will be testing your solutions using this updated version of Stream.scala

Tue, 26 Oct 2010: Here is an updated version of the sheet I read this morning in class summarizing the topics we've covered in class, to help you review for the midterm. You will be responsible for anything down in class or written in the notes for all lectures up to and include those on Friday Oct 22.

Mon, 25 Oct 2010: I've had a few questions on homework 3 at office hours earlier, the answer to which may be helpful to everyone. The main one if that for Question 2, I'm asking you to change the representation of atlases you implemented in homework 2. There, you had to use the representation of atlases that came out of the specification, thus, three concrete implementation classes corresponding to the three creators. For this homework, you can ditch those three concrete classes, and replaced them by something else. What that something else is is completely up to you, as you long as it implements something like a binary search tree. You still need to have those three creators for Atlas, of course, since the creators are part of the signature I'm asking you to implement, but those creators will need to instantiate and/or do something with your new concrete implementation e classes. You may also benefit from having helper methods in your concrete implementation classes (I had two in my implementation).

The hardest bit of question 2 is definitely getting the focus() operation to work, which shuffles the tree so that the room you specify is now at the root of the tree. I admit that I have a particular behavior for focus() in mind, but any behavior that yields the room with the name given as argument as the new root of the tree representing the atlas is fine with me. The kicker is of course you want to respect the binary search tree invariant. In my implementation, here's how things look like, if I use integers instead of rooms. If I start with the following tree:

and then ask it to focus() on 8, then I first go through the "intermediate" tree

and then in one more step get the result I want:

You don't have to do it that way, of course. But if you get stuck you can study the above. My implementation has the interesting artifact that all trees will degenerate to a kind of "broken back" list after enough focus() operations. I'm happy to live with that.

For question 3, I've added a sample solution to Atlas from homework 2 to the Homeworks sections of the website that you can use if you get stuck on question 2. I've also tossed in solutions to OString and Room, even though most of you got those right.

Sat, 23 Oct 2010: Lecture notes on polymorphic classes are up.

Fri, 22 Oct 2010: Here's the code for today's lecture, including the correction to the silly bug I ran into while attempting to compile the "Addable Pairs" class APair there at the end of class. (Debugged at a DD in Warner, NH on my way up to Montreal, in case you were wondering...) Lecture notes will follow sometimes tomorrow once I remember just what I said this morning.

Thu, 21 Oct 2010: Lecture notes on subtyping multiple types are up, and all the code for the last few lectures is also up on the web page.

Wed, 20 Oct 2010: Lecture notes on implementing subtyping are up. One more set of notes and the code to go.

Wed, 20 Oct 2010: Lecture notes on understanding subtyping -- the business about upcasts and downcasts -- are up. Two more sets of lectures notes and the code and then I'm up to date. Hopefully by this evening. (These were the tough ones to write up because they actually covered almost two lectures.)

Tue, 19 Oct 2010: First off, I hope to have all outstanding lecture notes uploaded to the web site by tomorrow, along with the sample code. Second, I left you with an exercise at the end of the lecture. Here it is. Start with defining a binary tree ADT BinTree with the following signature:

    CREATORS     empty  : () -> BinTree
                 node :   Int BinTree BinTree -> BinTree
                                                                  --
    OPERATIONS   isEmpty : () -> Boolean
                 root :    () -> Int
                 left :    () -> BinTree
                 right :   () -> BinTree
                 size :    () -> Int
                                                                  --
    SPECIFICATION
       empty().isEmpty() = true
       node(i,l,r).isEmpty() = false
       node(i,l,r).root() = i
       node(i,l,r).left() = l
       node(i,l,r).right() = r
       empty().size() = 0
       node(i,l,r).size() = 1 + l.size() + r.size()

Use the Specification Design Pattern, as usual, making sure you hide all implementation details. Once you've done that, I want you to make BinTree a subtype of Stream[Int], where Stream is defined to be:

    trait Stream[A] {
      def hasElement ():Boolean
      def head ():A
      def tail ():Stream[A]
    }

Intuitively, the stream should deliver all the elements of the tree, in some order. (I don't care what order you choose.) Note that you will probably need some helper classes to do this correctly.

Sat, 16 Oct 2010: Homework 3 is out. Due Wednesday 27 Oct, at 22h00. Helper files are provided in the Homeworks section of the web site. I will add a solution to homework 2 that you can use when you get to Question 2 and 3, but you can use yours too. Testers will come later.

Thu, 14 Oct 2010: Some of you are encountering weird errors in AtlasTester related to Some or None. That's because there are built-in Some and None classes in the Scala library that my tester uses, and if you called your concrete classes implementing OString those same names, my tester will pick up yours instead and will complain because they're not what it expects. This is the kind of error you'd get:

    type mismatch; found: explorer.Value required: String
    type mismatch; found: Some required: Option[explorer.Value]
    type mismatch; found: Some required: Option[explorer.Value]

The fix is to change the name of your classes in OString to something like OSome and ONone, or even better, hide Some and None inside OString, the way explained in Lecture 7 uploaded this morning.

Thu, 14 Oct 2010: Lecture notes from last week's lecture on information hiding are now available. They may come in handy if you want to hide helper functions in your homework and forgot how I did it in class and could not reconstruct it.

Tue, 12 Oct 2010: The midterm will be Friday, October 29th, in class (9h50-11h30). Closed books and closed notes, but I will let you have access to a single-sided 8.5x11 cheat sheet that you can fill with whatever you want.

Tue, 12 Oct 2010: Several folks have been emailing me telling me they're running into problems getting the testers to run under Eclipse. There are a few reasons why that might happen, but the most likely one is that code will only run if all the files in your project compile without error. (Even if the files that do not compile have nothing to do with the part of the code that you want to run.)

Thus, for example, suppose you download all the testers, and you start working on OString, and you decide to test it. If RoomTester.scala is in your project, then it will fail to compile because you haven't implemented the Room object and class yet. And because RoomTester.scala does not compile, compilation as a whole will abort, no compiled code will be produced, and because there is no compiled code there is nothing to execute, which is why you get a method main not found or class main not found. (It looks for main in the compiled code.)

So the solution is to import the testers in your project one by one, as you complete the various parts of your homework. Or write the whole thing at once and then test it all.

I will amend the scala instructions I posted yesterday to better reflect that. Someone please let me know whether that corrects their Eclipse problems.

Mon, 11 Oct 2010: A few of you seem to be confused about what to do with the testers. I probably should have posted something like this earlier, but figured you had learned how to do this in Java in previous classes, and the mechanism is exactly the same in Scala. But for those that need a refresher, here are some notes on working with Scala.

Mon, 11 Oct 2010: ... And the tester for the Atlas ADT is available. That one is interesting. Because we'll start developing code that represents the game itself, we're moving to more interactive testers that let us navigate the game world. Those testers will have a common infrastructure, which is a little interactive interpreter. When you run the tester (either by calling scala on AtlasTester or adding the tester to your code and calling the testing function by hand; see the comments at the top of the tester file), it fires up the interactive tester. Try it. If when you navigate things don't behave as you expect, then there is probably a bug in your code. (For instance, if you try to go north and you see by calling (print-exits) that there is indeed an exit in that direction but calling (follow 'north) fails, then you either have a bug in your hasExit() method, exitsTo() method, or follow() method.)

Here's a sample run on my system.

Sun, 10 Oct 2010: Added a tester for the Room ADT. Note that the tester is missing one test -- please complete it to get a complete tester. I've also modified the OString ADT tester to make the results of testing more useful.

Sat, 09 Oct 2010: Testers for Room and Atlas ADTs coming soon. Expect them sometimes Sunday afternoon.

Wed, 06 Oct 2010: Added a tester for the OString ADT.

Wed, 06 Oct 2010: Some of you have spotted the inconsistency in addExit() for question 2 of homework 2. The signature is correct, it's the specification that's wrong! I've updated the homework to the correct specification, so please make sure you read the new version.

Wed, 06 Oct 2010: I've been playing with SBT, a "simple build tool" for Scala midway between running Scala from the command line and running Scala in Eclipse. It has a rather homegrown-in-my-parents-garage quality to it, but it's still pretty interesting. If you're handy with installing software whose instructions assume that you already know how the software works in the first place, give it a shot. If it ends up useful, I'll try to post a "tutorial" on it.

Wed, 06 Oct 2010: I've added a copy of my sample solution Direction.scala for homework 1 to the Homeworks section of the web site, if you want to use it for homework 2. Feel free to use yours, though -- as long is passed all the tests.

Sun, 03 Oct 2010: Homework submissions are done through the Homework Submission Web Interface, like before.

Sun, 03 Oct 2010: Homework 2 is out. Because it came out two days late, it will be due two days later than originally planned, so Thursday 14 Oct, at 22h00. I will give you a pristine copy of Direction.scala implementing the code from homework 1, as well as some testing code in the coming days.

Sat, 02 Oct 2010: The code I demo-ed in class (and some more) for lecture 3, lecture 4, and lecture 6 is now available.

Sat, 02 Oct 2010: First off, I've updated the lecture notes on object-oriented implementation of ADTs. I've also added the lecture notes from last week, on errors and on subtyping. Read them, please. There is a lot more in there than I covered in class, mostly going into details that I skimmed over, especially with respect to testing. (Conversely, there are things I say in class that is not covered in the notes, so you should not rely on the notes alone...) If you find errors in the notes, drop me a line. I'll try to keep them up to date. Homework 2 coming up soon, as is sample code from the lectures above in executable format.

Wed, 29 Sep 2010: Submission instructions have been emailed to your husky.neu.edu accounts, including a unique token that you can use to set your initial password. Once you have your password, you can submit homeworks. The submission system can be found at https://cgi.ccs.neu.edu/~riccardo/cs3500/. Please get in touch with me if there are problems. You can submit multiple times, and we will generally only look at the last thing you submitted by the submission deadline. Note that the submission system will gsend you back an email confirmation of submission, including the file(s) you submitted. Please look at them to make sure that what you submitted was what you thought you submitted. In particular, submittiing .class files instead of .scala files is a common error that will probably get you zero.

Mon, 27 Sep 2010: Okay, automatic extension for homework 1 until Wednesday, September 29, 2010 -- so one extra day -- just so I can get my act together and work out the kinks out of the submission system.

Sun, 26 Sep 2010: A common question: do you have to provide any code for Q2 of homework 1? Answer: NO. The only thing I want you to do for Q2 is to give the equations you need to add to the specification to account for the new creators and operations. Also: I'm still in the process of figuring out submission instructions. Stay tuned...

Sun, 26 Sep 2010: I'm providing a tester for your Direction ADT in homework 1, DirectionTester.scala. Just compile it with your Direction.scala file, and run it. (It has a main() method.) Let me know if anything's wrong.

Sun, 26 Sep 2010: I was reminded that I did not cover equality on Friday, making answering the question of how to implement equals() on homework 1 a bit of a problem. Here's the template for writing equals() in Scala:

    override def equals (other: Any) = other match {
      case that : Direction => /*   case where 'other' is a Direction,
                                    and you use 'that' to access the
                                    argument of equals() *as* a Direction,
                                    e.g., use that.isNorth()...
                                */
      case _ => /*   case where 'other' is not a Direction
                 */
    }

Note the use of override, as I mentioned in class, to override the default. You'll need to do the same for hashCode() and toString(). Finally, I'll make a tester available to you in a few hours.

Sun, 26 Sep 2010: Lecture notes for Friday's lecture on object-oriented ADT implementations posted.

Sat, 25 Sep 2010: Lecture notes for last Tuesday's lecture on ADT implementations posted. Upcoming, notes for Friday's lecture, sometimes tomorrow.

Wed, 22 Sep 2010: I've posted the lecture notes for the first two lectures on the course web page. Here they are, if you want a direct link: Introduction, and ADTs. Lecture notes for the implementation lecture of last Tuesday should be up sometimes tomorrow.

Wed, 22 Sep 2010: (To file under better-late-than-never) Homework 1 is out. Due next Tuesday, at 22h00. Submission instructions to follow in the coming days. I will also provide a tester for you to play with. (For upcoming assignments, we'll ask you to come up with a tester.) Note that we do not have all the data to do Question 1 just yet -- I'll talk about that on Friday. Right now, focus on Question 0, and you can start thinking about Question 2 as well, since it does not require coding.

Mon, 20 Sep 2010: I've added links to the installation instructions for the Scala compiler, plug-ins for Eclipse, and general documentation on the web site.

Sat, 11 Sep 2010: I'm setting up the RSS feed for the course. You should see an RSS link up in your browser. Using a feed reader is probably the best way to keep up to date with the course. Oh, and welcome, by the way.

Course Information

Time and Location: Tue/Fri 9:50-11:30 108 West Village H (#23H)

Instructor: Riccardo Pucella, 328 West Village H (#23H)

Office hours: Mondays 15h00-17h30 (in 328 WVH)

Teaching Assistant: Nicholas Labich (Office hours: Thursdays 12h00-15h00 in 102 WVH), email: labichn@ccs.neu.edu

Course Web Site: http://www.ccs.neu.edu/home/riccardo/cs3500

Prerequisites: CS 2510

Textbooks: No textbook for the course. I will post lecture notes here, and give you pointers to online documents. You may find the following book useful, although it is not required, and we won't actually follow it:

• C. Hostermann, Object-Oriented Design and Patterns, 2nd edition, John Wiley and Sons, 2006

We will use the Scala programming language, which is a variant of Java developed in Switzerland. There are a few books on Scala available, and a fair amount of information online, that I will pass along to you. We will also use and refer to Java at times. The quality of a programming book is usually inversely proportional to its size, and my favorite Java book is a slim volume describing the language precisely -- it is a good book to have, but again, recommended, not required:

• P. Sestoft, Java Precisely, 2nd edition, MIT Press, 2005.

Grading: Grading will be based on weekly homeworks (50%), a midterm (25%), and a final exam (25%).

There may also be one or more quizzes, which may count as either assignments or exams at the whim of the instructor.

While some program assignments may require students to work in teams, most assignments and all quizzes and exams are individual. Student work is subject to the Academic Honesty and Integrity Policy.

Security is an important aspect of software development. In this course, students are expected to protect the software they develop from plagiarism. The quality of this protection will be graded.

Schedule Outline and Lecture Notes

This schedule is subject to change without warning. Readings will be assigned to supplement lectures, and posted here.

• http://www.scala-lang.org/

The latest stable release is version 2.8.0. This is the version we will be using. You can download the Scala compiler here:

• http://www.scala-lang.org/downloads

If you want to use Scala from the Eclipse IDE, then I suggest you install the Scala plugin for Eclipse (which install Scala too, so no need to install it separately). The Eclipse Scala plug-in can be found here:

• http://www.scala-ide.org

Note that this seems to require Eclipse 3.5.2 [codenamed Galileo]. The plug-in for version 3.6 of Eclipse [Helios] seems to be still experimental, so use at your own risks. I suggest installing a version of Eclipse 3.5.2 if you want to use the Scala plug-in. That version of Eclipse can be found here:

• http://www.eclipse.org/downloads/packages/eclipse-classic-352/galileosr2

You install the plug-in from within Eclipse itself -- here at the instructions:

• https://www.assembla.com/wiki/show/scala-ide/Requirements_and_Installation

If you have any trouble, please send us an email.

If you use a different IDE, you can find some plug-ins for other IDEs like IntelliJ here:

• http://www.scala-lang.org/node/91#ide_plugins

There is a version installed on the Linux server on the college network, but that version is 2.7.5, which is unfortunate, because there has been some changes to the standard libraries between the two versions. I will ask them to update the install, but it might take some time. In the meantime I will make my version available to you there, if you want. Just let me know

There is a fair amount of online documentation on Scala. Here are some good starting points:

• Programming Scala by Wampler and Payne. An O'Reilly book. Decent.
• First Steps to Scala by Venners, Odersky, and Spoon. Just a quick article giving an overview of Scala . Useful if you already know Java well, say.
• The standard library documentation. Always useful.
• A lot more documentation.

Online Resources