SDM Lab 3: More with Papyrus (last updated 7/10/19)
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 give you more experience with Papyrus, still
working with small examples. 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.
Getting started: class diagram
- Recall the course registration example from last week. (2019 note:
actually we didn't talk about it, so instead, listen at the start of the lab!)
- Build a conceptual class model in Papyrus to show a suitable conceptual
class model (just two or three classes: why not use three, and get an
aggregation in there?).
- Build a simple use case diagam (just one actor and one usecase).
Sequence diagrams
Consider the following scenario:
Student Jane Bloggs is to be registered for SDM. SDM has Inf2C-SE as
prerequisite; it has a quota of 100 students; 17 students are currently
registered on SDM. Jane has taken Inf2C-SE.
- Using any technique you find useful (e.g., something inspired by
robustness diagramming, or CRC cards), decide how your system should
realise this scenario. Which classes should have which methods, and do any
classes need extra attributes? (If you can think of more than one way to do
this, don't agonise over what's best: you can always change your mind
later.)
- Draw a sequence diagram in Papyrus to represent the scenario, given your
decisions.
As you may have found in last week's lab, or finishing it later, there are
quite a few things to know about sequence diagrams in Papyrus. For example:
- to create lifelines, the easiest way is to drag a class from the model
explorer to the SD canvas;
- there doesn't seem to be a way to have an actor shown with a stick
figure;
- start by creating an Action Execution down the lifeline of your
initiating actor;
- use synchronous messages (we're representing method calls);
- if you add a new operation, you are actually adding that operation to
the appropriate class - but to get that visible on the class diagram, you
have to select the class, select Filters from the right menu, select
Show/Hide Contents, and tick Attributes and Operations;
- return arrows really shouldn't have names, but by default they do in Papyrus;
- if you have trouble representing an object sending itself a message,
put the nested Action Execution on the lifeline first, then add the
message;
- to add parameters and return types to your messages, use the
properties window in your class diagram.
- In Java, implement classes Student and Course that are consistent with
your sequence diagram. (Since you've only considered one scenario, your
classes will not be complete. Abbreviate appropriately: for
example, if some method has an if-statement checking whether some
pre-requisite has been satisfied, and only one branch is exercised in the
scenario, feel free to leave the other branch containing only a comment.)
- Now, download this JUnit test class.
Import it into your Java project (Import, General, File System...). Take it
as a starting point, but you are likely to find, you have to modify it
before it will compile with your Java code. Modify it if necessary, but
make sure the test still tests the right functionality! Run the modified
JUnit test and check it passes. (Right-clicking the file should give you a
Run as... menu item with JUnit test as an option; if not, you probably
don't have a JUnit library in your project's build configuration yet. The
easiest way to fix this is to create a JUnit 4 test file of your
own, using File, New, Other, junit, and then accept the suggestion of
adding the library.)
If you need to modify something in your code (for
example, in developing this lab, I decided I needed a registerStudent
method to return a boolean to indicate success or failure, whereas it had
returned void before) update your code and also your model. What other
tests might be needed?
- Swap screens with someone nearby (not in your group, if you worked in a
group!) Explore one another's UML diagrams and Java code. Discuss. Did
either of you have problems, and if so can you solve them between you? Are
there interesting differences in what you've done? Discuss.
State diagrams
Build state diagrams in Papyrus for your classes Student and/or Course,
depending on what qualitatively different states there are in your
solution. Create the state machine as a child of the class it describes,
e.g., right click on Student in your Model Explorer and choose New Diagram
from there, to create a state diagram for Student.
Make sure you find out how to have a condition - that is, a constraint - on
a transition. Pay particular attention to the choice of language in which
to express the constraint.
This page is maintained by
Perdita Stevens (
perdita@inf.ed.ac.uk)
