SDM Lab 4: Working with larger systems
This page gives brief notes and instructions on the guided lab session. It
will have omissions and bugs - you need to listen as well as read!
Introduction
The main aim of this lab is to let you build larger models, and explore
features of UML that have not come up so far in the labs. It also aims to
set the stage for code generation, reverse engineering (creating diagrams
from existing code), and bidirectional transformations between code and
diagrams. As you work, think about which parts of what you do are routine
and could be automated, and which involve intelligence.
You are welcome to work individually or in small groups, as you prefer -
but as always, if you work in a group, make sure you all understand
everything done.
Note: We have a new version of Eclipse with the latest Papyrus
pre-installed. This is what will be available in the assessment, so do try
it out. The menu system is now cluttered enough with Eclipse versions that
the recommended way to start it is: start a terminal and type
papyrus!
Getting started: loading Java code for Borg calendar system
The Borg calendar system is an open source personal organiser: here is its
home page.
You will be building UML models of some of its code: I encourage you also
to build it, explore its design and consider how its design could be
improved.
We will install just some of its code for this lab, so it won't actually
build: don't worry about this. (Exercise for the reader, not actually
necessary for today: get the whole system to build in Eclipse. If you just
wish to build it at the DICE command line, see last year's SEOC
exercise for some help (I checked this still gave a successful build
this year, though the application didn't behave well when I ran it - I
didn't investigate why).
Use menus: File, import, Git, project from git. Give the URI
https://github.com/mikeberger/borg_calendar.git.
When prompted, choose branch Master (only), and project model (only).
(If you do want to build the system, and I emphasise you need not for this
lab, you'll need to make sure you have the Maven plug-in m2e in your
Eclipse: you get that by using menus Help, install new software, then
selecting the Neon - ... option to install from and searching for m2e, and
ticking the one result labelled Maven Integration into Eclipse. Then you
will (if your setup is like mine) find that the build chokes because you
don't have Lombok, the system that translates annotations like @Getter and
@Setter into actual get and set methods, available... I haven't
investigated how to solve that one.)
How to approach the exercises
For all of these, the purpose is to learn, not to produce a perfect final
artefact. (I do not have a set of perfect final artefacts myself.) If
you're spending a lot of time doing mindless boring aspects of this, change
what you're doing. There are two distinct reasons for this: first, your
time as students is limited and you should maximise the learning:time
ratio; second, developers' time is also limited, and I want you to think
about how people can do modelling cost-effectively.
This exercise has
scope for a lot more work than you can do in one two-hour lab so feel
free to skip around and do parts of things.
Once you have attempted a question, and either feel happy with your
solution or have got stuck, please go and join, or start if it hasn't been
started yet, a discussion about it in Piazza.
Exercises
-
Study the code in package net.sf.borg.model.entity. Draw a UML class
diagram representing the contents of this package. Think about the
usefulness of what you're doing: e.g., feel free to omit most attibutes
(in a hand-drawn diagram, you'd write ... : can you do that in Papyrus?).
But do think about how to precisely represent as many different kinds of
information as you can, and see what questions arise as you do so. If
appropriate, look things up in the the UML2.5 standard to
understand how UML treats features you may not have considered, e.g.,
parameterised classes. But the best can be the enemy of the good: feel
free to approximate and move on.
- Now consider package net.sf.borg.model, and do the same there. What
are the relationships between packages net.sf.borg.model and
net.sf.borg.model.entity (a) in Java terms (b) conceptually?
- (If you can make Papyrus draw sequence diagrams, then in Papyrus, else
on paper!) Draw a single-scenario sequence diagram to represent what
happens when an object of class Memo receives message
decrypt(``password''). Assume that in this scenario
isEncrypted() returns true.
- Draw a sequence diagram using fragments to represent all possible
scenarios when an object of class MemoModel receives message
getMemos().
- (Much harder: you might want to leave this one for later rather than
doing it in the lab.) Next look at class TaskModel in package
net.sf.borg.model. Study the saveProject() method. Note that the code is
quite complex, but the Javadoc contains no detail about what work is
being done and why. Consider broadly what kind of documentation you would
like to inherit, if you were to take over as the maintainer of this
project. Consider developing a sequence diagram for the behaviour of this
method (in all scenarios, using fragments to represent alternatives,
etc.). Will you represent every detail of the behaviour, or will you omit
some details? Can you identify a principled way to decide what to include
and what to omit, so as to produce a diagram that might be of use to a
maintainer? Try to do so, and draw the resulting sequence diagram. I
mentioned in a lecture that a long method constitutes a Bad Smell: this is a
case in point. If you were going to refactor it, what might you do?
- Draw a protocol state diagram for class Memo.
- (Also harder, and could be left for later.) Draw a protocol state
diagram for a more complex class, e.g. ReminderPopup, which you'll find
not in the model project you loaded into Eclipse, but in the swingui
project, package package net.sf.borg.ui.popup. Here you'll have a
trickier job to decide what the states are, and you'll need to look at
the superclasses as well as this class's own code.
- Explore the functionality of the Borg Calendar to the point where you
can describe an interesting use case for it, with some exceptional or
alternate courses. Draw an activity diagram to describe the use case,
paying attention to where there are restrictions on the order of
activities and where not.
This page is maintained by
Perdita Stevens (
perdita@inf.ed.ac.uk)
