Preparing for the Exam

When marking exams previous years I have seen some common mistakes. Below, I express concrete advice that should help you to get it right. At the very least, please use this list as a reminder to test your own understanding. If you are unsure, go back and revise the relevant parts of the course. I will add to this list as I see more things.

• Use Cases have actions in their names. A use case typically has a name that includes an action. For example, “Pay money”, “Book ticket”, “Reserve flight”. If you just use the noun (“money”, “ticket”, “flight”), there is no way of knowing what an actor is supposed to do in the use case. The nouns are good names for your concepts in your domain model, though.
• Don’t use composition or aggregation unless you are absolutely sure. First off, when you make the domain model there is no such thing as a composition or an aggregation; these are strictly hints for how to implement the system and thus only appear in your class diagram. Second, most relations between classes can be modelled as plain associations. The composition or aggregations may look cool because it’s got a fancy little diamond in one end, but if you are even wondering whether a relation should be an association or a composition, then it is a “simple” association.
• Put the symbols at the right end of the relation. In composition/aggregation this means that the diamond is on the owner side. For inheritance the triangle is on the parent side. To illustrate:

Car o- Engine
note right: A car <i>consists of</i> an Engine.

Media <|- DVD
note right: A DVD <I>is a</I> type of Media.

• Put the method in the called class. Consider the interaction diagram below. Where would you put the Start() method? What I have seen in many exams is that there is a tendency to put it into the Car class. But think about it for a while. It is c:Car who is initiating the method call, and it wants the e:Engine to start. If you put the Start() method in Car, then Engine has no way of knowing that it has been called. Expressing it in a different way, Start() is an operation we wish to perform on the e:Engine, and therefore it must be offered by the Engine class.

"c:Car" -> "e:Engine" : Start()

• A Class is a description of an Object. An Object is a concrete instance of a Class. Think of a class as a blueprint that tells the compiler that “When you create objects of this type, this is how much memory to allocate, and these are the methods that can be called”. An object is then a “physical” representation of a class description in memory. Once a system is running it has no clear representation of the class anymore – just the objects¹. The borders between what a class is and what an object is is often muddled in dynamically typed languages such as JavaScript, so if your background is in such languages it is worth thinking twice about it.
• Dynamic diagrams deal in objects. Related to this is that when you look at the dynamic diagrams they tend to work with objects (and not classes). Consider, for example, sequence diagrams. In these diagrams it is specific instances of classes (i.e., objects) that have specific values on all their attributes, and these specific instances collaborate (with the help of method calls) to solve one particular scenario of execution. Remember that we may have instances without names :Car as well as named instances that are assigned to a variable, myCar:Car. Also note that this does not imply that the second example knows that it is named myCar, this is just the name of the varible that is pointing to an object of the type Car.

A small selection of old exams (For the course PA1415. The other courses are normally a 90-95% subset of this exam). The following were done before my involvement in the course (but I did provide the example solution for the January 2016 exam):

• Exam 2014-08-28
• Exam 2015-06-08
• Exam 2015-08-21
• Exam 2016-01-09
  • Solution for Exam 2016-01-09, Part I
  • Solution for Exam 2016-01-09, Part II

More recent exams made while I was involved in the course:

• Exam 2016-05-29, With Solutions
• Exam 2016-08-19, With Solutions
• Exam 2017-01-02, With Solutions

Computer Based Exams:

• Exam 2017 May
• Exam 2017 August
• Exam 2018 January

Since the exam will be in swedish a translation of common terms are presented below. Sometimes the english term will be used also in swedish, for reasons of simplicity and clarity.

Note: These are my translations that does not necessarily correspond to any official standard. If you see anything that is obviously wrong, or if you have a better list, please contact me.

The terms are roughly organised into different groups below. This does not mean that the term is only valid in that group!