School of Informatics Courses: SDM Lab 3 University Homepage School Homepage School Contacts School Search 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) Home : Teaching : Courses : Sdm Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail: school-office@inf.ed.ac.uk Please contact our webadmin with any comments or corrections. Logging and Cookies Unless explicitly stated otherwise, all material is copyright © The University of Edinburgh