Project

Project Objective

This year's general topic is:

Trip Planning

Trips can be very complex undertakings that can really benefit from software support. Often, they involve making detours to visit interesting sites in the vicinity of the main route. Different services and events can be offered at these sites. The sites may be recommended according to the traveler's needs and constraints. During the trip, the initial plan may be changed. Traveling in a group may involve synchronizing detours. Whether a trip plan is created by a professionals or by travelers themselves, it may be worthwhile sharing it with others.

Prepare the objective of developing a software system within the area defined by the general topic (approximately 200 words). Focus on a selected aspect (no need to cover everything). Provide your own, sufficiently descriptive title. Do not repeat the basic topic.

Even tough the objective should be phrased in an application manner – i.e., you shouldn't use solution domain notions in it (object, class, and such) – bear in mind how are you going to employ object-oriented features of Java in it. Make a sufficient space for this. Don't be afraid to phrase your objective more broadly – that doesn't mean you will have to implement everything.

In the program that you will be creating according to your objective, it will not be necessary to solve network issues or concurrent use by multiple users (e.g., real communication between users across the network). It is sufficient to imitate such activities (e.g., you can log on as one user, and then as another one). Also, it is not necessary to solve security. Focus on object-oriented modularization.

Support your objective by an object diagram of typical situation in the system you anticipated with an initial class diagram (you will be capable of dealing with this after the first two lectures). Focus on few most important objects and, afterwards, generalize them into classes between which you will determine primarily the relationships of association (general relatedness) and inheritance. Identify few important attributes and methods in these classes. You will learn of a simple and flexible tool for drawing diagrams in exercise 3, but you can draw your diagram in whatever tool you prefer (a scan of a diagram drawn on paper is also acceptable).

Consult your objective with your teacher at exercises in a timely manner.

To be submitted: a text in the PDF format

Assessment

For a project objective to be eligible for a nonzero assessment, the following conditions must be fulfilled:

1. It must be within the general topic.
2. It must be provided with a specific name.
3. The text must be comprehensible and clearly formulated.

The assessment is as follows:

• well-arranged and clear project objective with a suitable own project name, with a clear class diagram – 5 p
• mostly well-arranged and clear project objective with a less suitable own project name, with a less clear class diagram – 3–4 p
• less well-arranged, but still acceptable project objective, with an unclear class diagram or even without one – 0–2 p

Working Program Version

To be submitted: program (source code) into the GitHub classroom created for this course

• submit only to the master branch – do merge (the download project script won't collect anything else)
• don't forget to set your first and last name in GitHub (Settings/Profile/Name)

Assessment

For a working program version to be eligible for a nonzero assessment, the following conditions must be fulfilled:

1. It must work and cover the principal parts of the assignment and project objective.
2. The submitted source code must include all necessary files and it must be possible to compile it in the Eclipse environment installed in the laboratory where the exercises are held.
3. It must have been present at least once at the satisfactory level to the teacher.

The assessment is as follows:

• a program covering a significant part of the assignment and project objective, as well as the teacher's instructions, with suitably applied inheritance, polymorphism, and aggregation; the application logic separated from the user interface – 9–10 p
• a program covering a significant part of the assignment and project objective, as well as the teacher's instructions, with less suitably applied inheritance, polymorphism, and aggregation – 7–8 p
• a program covering at least half of the assignment and project objective, as well as the teacher's instructions – 5–6 p
• a worse program, but still at an acceptable level and principally corresponding to the assignment and project objective – 0–4 p

Program and Documentation

The core of the project is an object-oriented program in Java created according to the assignment.

The program is accompanied by a documentation that consists of two parts:

• project realization report
• Javadoc documentation

In the project realization report inform briefly (in a few pages) about your project. Embrace the following:

• project title and objective
• system structure in the form of the most important classes with their explanation and with the explanation of their relationships
• how your project fulfills assessment criteria according to you
• list of the major program versions submitted to the GitHub classroom with a brief description of the most important changes for each version

The Javadoc documentation is the documentation generated directly out of the program using the javadoc tool in the HTML format. Supply sufficiently clear comments in the form appropriate for the javadoc tool to all elements of your program.

To be submitted: program (source code) and documentation into the GitHub classroom created for this course

• submit only to the master branch – do merge (the download project script won't collect anything else)
• don't forget to put your first and last name in the project realization report

Assessment

For a program and documentation to be eligible for a nonzero assessment, the following conditions must be fulfilled:

1. The program must work and correspond to the project assignment approved by the teacher and to principal teacher's requirements that occurred during the project realization
2. The submitted source code must include all necessary files and it must be possible to compile it in the Eclipse environment installed in the laboratory where the exercises are held.
3. The program must embrace a meaningful inheritance between own classes and overriding of own methods.
4. Encapsulation has to be employed in the program.
5. The program must embrace sufficient comments to understand the code.
6. The documentation must correspond to the program and it must contain a class diagram.
7. A student has to be capable of answering all the teacher's questions regarding the project during the final presentation.

The main criteria in project assessment are the extent to which the assignment is fulfilled, application of object-oriented mechanisms in the program (an appropriate use of inheritance, encapsulation, and aggregation), code organization, and documentation quality.

Further criteria embrace:

• application of design patterns except the Singleton design pattern – each design pattern implemented counts as a fulfillment of one further criterion, but the implementation of all design patterns is assessed as a fulfillment of three further criteria at most
• handling exceptional states using own exceptions – one exception is sufficient, but it has to be actually thrown and handled
• providing a graphical user interface separated from application logic and with at least part of the event handlers created manually – counts as a fulfillment of two further criteria
• explicit use of multithreading – starting an own thread directly or using a higher level API (the Task class and such)
• using generics in own classes – implementing and using an own generic class (as in the linked list example provided with lecture 5)
• explicit use of RTTI – for example, to determine the type of on object or to create an object of a certain type (as in determining the number of beings in the ogre and knights game)
• using nested classes and interfaces – only using them within the application logic counts, not in the GUI, whereby the interfaces have to be own (one possibility is present in the inner class example provided with lecture 4)
• using lambda expressions or method references – only using them within the application logic counts, not in the GUI, whereby the interfaces have to be own (one possibility is present in the method reference and lambda expression example provided with lecture 4)
• using default method implementation in interfaces
• using aspect-oriented programming (AspectJ)
• using serialization

The assessment is as follows:

• fulfillment of the main criteria – max. 15 p
  • the program corresponding to the assignment and project objective, as well as to the teacher's instructions, with an appropriate use of inheritance and polymorphism in at least two separate inheritance hierarchies, including the application of interfaces, and with a correct encapsulation and appropriate use of aggregation; the code appropriately organized into packages; a clear documentation with all items according to the description above – 14–15 p
  • the program corresponding to the concrete and basic assignment, as well as to the teacher's instructions, with an appropriate use of inheritance in at least two separate inheritance hierarchies and polymorphism in at least one of them, including the application of interfaces, and with a correct encapsulation and appropriate use of aggregation; the code appropriately organized into packages; a mostly clear documentation with all items according to the description above – 11–13 p
  • the program corresponding to the concrete and basic assignment, as well as to the teacher's instructions, with minor acceptable divergences, with an appropriate use of inheritance and polymorphism in at least one inheritance hierarchy, and with a mostly correct appropriate use of encapsulation and aggregation; a documentation with all items according to the description above – 8–10 p
  • the program corresponding to the concrete and basic assignment, as well as to the teacher's instructions, with still acceptable divergences, with an appropriate use of inheritance and polymorphism in at least one inheritance hierarchy, and with a limited use of encapsulation and aggregation; a still acceptable documentation – 0–7 p
• appropriate fulfillment of further criteria (primarily of those named above, whereby the application of the corresponding mechanism makes no automatic claim to marks – the appropriateness will be judged by the teacher) corresponding to the assignment and project objective, as well as to the teacher's instructions, with an appropriate short description in the documentation: the fulfillment of each criterion will be assessed within the range of 0–4 p – max. 25 p

Final Project Presentation

The final project presentation is a part of the project submission. The project that has not been presented will not be accepted.

After the final presentation, your teacher will announce you your approximate descriptive assessment. You will receive the definitive decision including the decision whether your project fulfills the acceptance conditions via AIS after a detailed project inspection.

To be submitted: an oral presentation at 11th or 12th exercise according to the instruction given by the teacher

Marking

The marking is as follows:

• appropriate demonstration of fulfilling the concrete and basic assignment, as well as teacher's instructions, including reactions to the teacher's questions – 5 b
• mostly appropriate demonstration of fulfilling the concrete and basic assignment, as well as teacher's instructions, including reactions to the teacher's questions – 3–4 b
• still acceptable presentation and reactions to the teacher's questions – 0–2 b