Project assignments
You will work on one of these assignments in a group with exactly three members. There is a sign-up list for creating the groups at the course page in Studentportalen (Object oriented design, 5 hp). You are strongly encouraged to create groups with members of mixed backgrounds (programmes, experience, ...). If you have not signed up for a group before the second lecture, you will be assigned to one.
Once groups are formed, we will make sign-up lists available for selecting the group assignments.
When selecting an assignment, it may be useful to know that a higher project number means that a stronger programming background might be needed than for a lower number. However, if you have created a group of mixed backgrounds/programmes, this should not be a major factor.
- Simple Server
- approaches design through code and requires that you are able to read a chunk of Python code, create a model from it, reason about it and extend the model
- Dungeon Quest
- focuses on modelling a classic board game as a multi-player online game.
Deadlines
Deadlines are absolute, unless negotiated well in advance (more than a week beforehand).
- First seminar: Be ready to present your poster on Sep 27
- Final seminar: Unfortunately the schedule is still not finalized, but it will be during the week of Oct 15-19.
- Be ready to present your design and to review another group's design in your respective time slots.
- You must hand in your design documentation at least 48 hours before your presentation, both to Kent, David, and Stavros as well as to the group that will review your design.
Instructions for presentations
Oral presentation 1
The first presentation will be midway through the course, and is intended to allow you to present your analysis and to get feedback for your further work. The presentation
is intended to be informal: Within the group, you will take turns standing by your poster to answer questions and walking around looking at the other posters
(i.e. pretty much how a poster presentation at a conference works). Please be
prepared both to answer questions about your own poster and to ask questions of the other groups.
You may "steal ideas" during this presentation, but note that it's ideas; don't copy verbatim.
At the seminar, you are expected to have finished the analysis, and concretised it in a class diagram. Your poster should include use cases and (at least) a class diagram.
Also include CRC cards or equivalent if applicable. The class diagram should probably not include all that many attributes and operations at this point.
Note that attendance at this presentation is compulsory.
Oral presentation 2
This presentation is a bit more formal and in smaller groups. It will be spread out over two days and each session will consist of three project groups, the teaching
assistants, and the lecturer. One group will present their design, one will act as reviewer, and one as "interested audience" or "peer group." This means that each group
will participate in three sessions: Once as presenter, once as reviewer, and once as audience. Each of these will take approximately 40 minutes. Reviewing will primarily be
done by a group who has worked on the same project as the presenting group. Auditing will primarily be done by a group that has worked on a different project.
Presenting
Each group will again prepare a poster, more detailed this time, which they will use to present their design to the examiner(s) and two other groups (review group and
peer group). You should be able to decide beforehand what diagrams/information is needed to communicate your design. Don't prepare a slide presentation or similar.
You will also be required to hand a complete copy of your work over to the reviewing group, and the examiner, 48 hours before the seminar.
You are required to bring all your documents on a USB stick or make them otherwise available in PDF form during the seminar so that they can be fetched if any of
the reviewers wants to talk about something which is not on the poster.
Guidelines
- Your goal is to explain how to to build the software for your project
- Are there non-functional requirements? How do you cater for them?
- Imagine the listeners are the coders that will build the system, if we don´t get it, we´re going to build crap
- Where do you start explaining?
- What are the most important parts?
- What do we need to get? Have you made any implicit assumptions that need to be explained?
- How will your design documents aid us in our work?
- What parts are tricky, could be questioned, etc.?
- In doing the above, you should at least demonstrate that you understand the principles of OO design, the design process, and your own designs
Reviewing
- You know the project and what´s hard because you´ve done it - and probably differently
- Your job is to question the design of the other group
- Have they thought about the X corner case?
- What´s the consequences for X of their design?
- Why are classes A, B, and C not related by inheritance?
- Why is this use case not in the system?
- Etc
- Show us that you have a relatively deep understanding of the problem, that you can understand others´ designs, and that you can question them aptly
- We are not interested in notational bugs, but in semantics! Similarly, don't quibble over choice of words, unless it actually makes a difference to the interpretation.
- We expect you to look at the other group´s design beforehand
Acting as audience
This role is both the easiest one and the hardest one: Easy because you don't have to prepare for it and hard because you can't prepare for it...
- You´ll be listening to another group presenting their design (ideally from another project)
- The seminar leader will be interested in whether you understand the design being presented to you
- Is the communication of the design working or not?
- You are expected to ask questions, but you are not expected to look at the design of the system you´re being presented beforehand
Note that attendance at this presentation, once for each role, is compulsory.
Hand-in format
Preliminary draft
We expect the quality of the designs that you hand in to be good enough to start implementing them. Imagine the implementing team only partially overlapping with the design team - and explain yourselves accordingly. It is often quite impossible to understand a system by looking at just design diagrams. Thus, there should be a single textual document describing the design of the system heavily referencing and relying on the diagrams to provide a decent overview. Do not embed diagrams in the textual document.
The examiners reading what you hand in will start with the textual document and only look at diagrams it explicitly references. Any diagram not explicitly referenced will thus be lost.
Design documentation
The design documentation you are required to hand in can be roughly divided into four different parts: Analysis, Static models, Dynamic models, and Deployment & System architecture. Each part should be described textually (as you see fit) in a way that walks the reader through the different design and analysis diagrams you have produced. As will probably be clear from interaction with the peer and review groups, reading someone else's design straight from the diagrams is not easy. Accompanying text helps.
Note that there may be non-functional requirements that must be met. For each such requirement, a 1-2 page document must be handed in describing what design decisions were made in order to support/meet the requirement, potentially substantiated by scenarios and what problems or difficulties arose due to the requirement.
- Analysis
- The analysis part encompasses:
- Use case diagrams and associated textual descriptions
- Simple class diagrams (mostly without properties or operations, instead focusing on associations with roles, multiplicities and generalisations)
- Simple activity diagrams (no need to qualify with stereotypes, data flow, exceptions, etc.) capturing the most important parts of the application on a high level
- Static models
- The static aspects of the system design encompass:
- Subsystem decomposition in packages, clearly showing interaction/dependencies between packages
- Detailed class diagram, with properties, operations, etc.
- You should model ownership for some relevant subset of the system using structured classes (models nested in models); E.g. a car has an engine and four wheels that belong to that car only. If no ownership exists in your system, clearly indicate that in your documentation and write a short text about why it is so, and whether that has any consequences for the system.
- Component diagrams, with ports and required/provided interfaces (if applicable)
- OCL constraints expressed over the elements of your model
- The OCL constraints can be in the diagrams themselves, described separately or both. P3 and P4 clearly state what needs expressing in OCL. Remember that the way you design affects how straightforward it will be to express the desired properties in OCL.
- You should use collaborations to express any recurring patterns in a suitable way. Define the collaboration(s) on a separate diagram(s).
- Dynamic models
- The dynamic aspects of the system encompass:
- Time-based flow of events captured in sequence diagrams for key aspects of the system (alternatively, as communication diagrams), and interaction overview diagrams
- Use (a mix of) sequence or communication diagrams to capture the flow of messages between elements. Where time or order is important, sequence diagrams are preferred. Also use interaction overview diagrams to aggregate sequence diagrams to capture overall flow of one or more subsystems.
- How a (sub)system transitions from one state to another, modelled through statechart diagrams
- Note: When applicable, we expect you to consider concurrent aspects of the system, and what transitions or actions might happen in parallel.
- Deployment and system architecture
- With respect to deployment and system architecture, you should use deployment diagrams to express the overall system architecture, mapping software (sub)systems onto hardware nodes. If your system architecture follows a specific architectural pattern, clearly indicate it. Clearly explain and motivate your architecture (how does it work, why does it look the way it does).
Quantitative Requirements
At the first seminar, you should have accomplished at least the following:
- Identify at least 30 different use cases
- Pick 10 key use cases and describe them textually in the prescribed fashion (and motivate your selection)
- A class diagram (mostly without properties or operations, instead focusing on associations with roles, multiplicities and generalisations) for the entire system
- At least 5 comprehensive sequence diagrams, activity diagrams, communication diagrams, or state charts of key aspects of your system (motivate, start selecting from the use cases)
At the final seminar, you should have accomplished as least the following:
- Subsystem decomposition in packages, clearly showing interaction/dependencies between packages
- Detailed class diagram, with properties, operations, etc. for the entire system
- Component diagrams, with ports and required/provided interfaces for any components in your system
- Sequence diagrams, activity diagrams, or communication diagrams for the 15 key behaviours of your system (motivate your selection)
- State charts for 2 different key components of the system (e.g., buses, the Client class, friend requests and combat) at appropriate levels of detail (motivate your selection)
- A single deployment diagram for the entire system, clearly showing its architecture
There might also be other requirements to ponder specific to your project.
The models above is a (partial) design for your system. It should be accompanied by a textual document walking the reader through the design, clearly referencing the models and diagrams. Examiners will read this document from start to finish, following you references to diagrams. It should be possible to understand how to start implementing the system after reading this document.
At the end of your document, include a short report (1-3 pages) on the usefulness of your design. What issues came up while doing it, to what extent did the UML notation or the various aspects highlighted by the different models help you understand how to make an implementation? ("A lot" is not a good answer - explain and elaborate!) Remember, a model is a simplification of something intended to highlight certain aspects and gloss over others. If you are making a state chart model, you are (or should be) thinking about the system in a very different way than you would if you are doing a class diagram or a sequence diagram.