OOP RESULTS 1998

Direct questions or complaints to <eliens> or <jrvosse>.

1) Wiebe Hordijk <wiebe>, Martijn Thieme <emthieme>
date: Mon Apr 6 12:55:48 MET DST 1998
mark: 7.5
program: MOiS (Moving objects in space, 3D toolkit + editor)
documentation: Sloppy, hard to read and unstructured documentation. No serious explanation of the design decisions you have made.
architecture: Good use of standard OO paradigms such as MVC and mix-ins. The same applies to C++ features such as (double) inheritance, abstract base classes, templates, inline functions etc.
interface: Interface well separated from rest of the toolkit. Compared to the toolkit, the editor interface was clearly lower on your priority list.
conclusion: Good use of OO design and implementation techniques to realize this non-trivial application. However, this does not for the sloppy documentation.

2) Martijn Bot <mbot>, Rob van Nieuwpoort <rob>
date: Tue Jul 28 11:38:25 MET DST 1998
mark: 8.5
program: Scale (music editor)
documentation: Very short, but concise. I like the description of the evolution of the design, but miss the evaluation of the design.
architecture: Good modular design separating internal, GUI and midi classes. Maybe you should have done the same for the TeX functionality(?). GUI classes make good use of the (template) classes offered by hush and composites (SamengesteldScoreItem). Namespaces are limited by using nested class definitions (Score).
interface: The (multi-lingual!) graphical interface is built up out of many (too many?) windows, but is very easy to use (despite the bug in the metronome dialog), and supports the user by automatically adding/deleting notes rests etc. I found the "grid" option very useful, and the same applies to the import/export support for TeX and MIDI.
conclusion: This is an (extreme) example of a long term OO project. However, I think the long time it took to complete the assignment has had a positive contribution to the quality of the application and the maturity of its design. The number of OO techniques used is a bit limited. However, music, music notation and music format conversion are all complex domains, and by using OO techniques were needed, you have managed this complexity very well.

3) Nicky Le <bnle>, Omar Saadouni <osaadou>
date: Tue Aug 11 11:32:14 MET DST 1998
mark: 7.5
program: Dam Club
documentation: Good explanation of all components of the program and the high level architecture. However, I miss an objective evaluation of the design (currently, you only describe the advantages, not the disadvantages) and a description of possible alternatives you did consider. Furthermore, the documentation mixes the description of the functionality with the description of the design. Unfortunately, the emphasis is often on the functionality, where I would like to see more about the design. Given your list of features that are still missing, I also miss a section about the extensibility of the application.
architecture: Clear client/server model with good use of threads. I like your use of the lobby as a "real-world" communication mechanism for the threads. Good reuse of Deitel's list code
interface: I like the social dimension of the program. Except for the login interface (bit clumsy) the GUI is OK

4) G. van Dijk <gvdijk>, B.C.E Sjunnesson <bcesjunn>
date: Fri Jul 17 17:39:18 MET DST 1998
mark: 7.0
program: Spreadish! (spreadsheet in Java)
documentation: Documentations has improved w.r.t. the previous versions. Still, the focus is on relatively low-level design issues, and the discussion of object-orientation is a bit naive (late binding is not magic...). However, the text is clearly written and does discuss both the strength and weakness of the design.
architecture: Straightforward, several large classes need further decomposition. I have my doubts about the level of extensibility: how do I add new functions/operators? What effect does this have on the rest of the program (HTMLsave?).
interface: Simple, easy to use interface comparable with other spreadsheets.

5) D.C. Venema <dcvenema>, F.E. Dozzi <fedozzi>
date: Fri Jul 17 16:48:13 MET DST 1998
mark: 6
program: Stalemate (weggeefschaak)
documentation: Sloppy, unstructured documentation. All different aspects of the design are intertwined, and important parts are missing.
architecture: Minimal use of OO features. Most functionality is in the "AI" module where the use of OO is reduced to a bare minimum. It remains unclear what the effect of the various extensions have been on the overall design, and whether new extensions can be added easily.
interface: Easy to use GUI, command line options need better documentation. Stalemate has both a hush and QT version; Xboard can be used as another alternative interface.
conclusion: I'm impressed by your programming skills: Stalemate really is a an impressive application, and it is fun to play too. However, because of the inadequate documentation and low OOP level, you do not qualify for a high mark for this course

6) Bas Sommeijer <bsommei>, Harro Mantel <hmantel>
date: Mon Aug 31 15:43:09 MET DST 1998
mark: 7.5
program: Rummicub
documentation: Well written documentation which explains both the advantages and disadvantages of the design
architecture: Straightforward client/server architecture with good use of Java's network classes.
interface: Easy to use GUI, and you've documented all major limitations already.
conclusion: Good assignment, but without a real innovative contribution.

7) Martin van Estrik <estrik>, Joost Vunderink <jvunder>
date: Mon Aug 31 15:59:55 MET DST 1998
mark: 7
program: YONN (GUI to neural network)
documentation: A bit unstructured, but it contains the most important issues in your design.
architecture: Your use of OO hardly goes beyond encapsulation...
interface: Basics are OK, network GUI not updated while network is learning.
conclusion: From the beginning, it was clear that you both lacked the programming and design experience computer science students do have, and compared to the average assignments of computer science students, this is not up to standards. Given this, I think you have learned a lot during this assignment and have earned your marks. You have faced the consequences of underestimating the development time needed to implement an application from an unfamiliar domain in an unfamiliar language, you've learned --- the hard way --- how to reuse third-party software by re-engineering Java byte code, you re-invented the MVC paradigm. Additionally, you've adequately responded to all my requests to improve specific aspects of the implementation and documentation.

8) Lars Baede <lbaede>, Jeroen Langeveld <jlangev>
date: Mon 31 Aug 1998
mark: 7.5
program: Boozed (game)
documentation: The good, online documentation partially makes up for the sloppy hardcopy version. But together, they give a good overview of the application and its design.
architecture: Though you make good use of OO in the "Steen" class hierarchy, the overall design is in particular by the chosen division of labour. The drawbacks of this division are well documented. The game itself features multiple levels that are configurable in several dimensions (including speed).
interface: Easy to use and complete interface, including on-line help, high score, preferences etc.

9) Jeroen van der Poel <jbvdpoel>
date: Mon 31 Aug 1998
mark: 6.0
program: Hypermedia PIM (GUI)
documentation: Though the documentation about the realized part of the GUI is sufficient, a high-level design of the underlying system is missing. The documentation lacks especially a specification of the interface mechanisms between this system and the GUI.
architecture: Basic hush GUI, with good use of OO to deal with multiple information sources. However, the application is too small to prove your OO design skills.
interface: Good use of existing widgets to simulate a tab control. For a Hypermedia PIM, the link manipulation interface should have been further developed.
conclusion: The main problem of this assignment was the lack of teamwork, and the both of you are responsible for the consequences. You should at least have contacted one of the supervisors in an earlier phase of the project.