SDM: Lab 3

SDM Lab 3

Part 1

In this part we will consider the student registration system discussed in the Week 3 videos. You may want to re-watch them to remind yourself.

  1. In LucidChart (and when you do Part 2, you might like to re-do it in whatever tool(s) you're considering there) build a conceptual class model (just two or three classes: why not use three, and get an aggregation in there?).
  2. Build a simple use case diagam as illustrated in the video (just one actor and one usecase).
  3. 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 to represent the scenario, given your decisions. Note:

  • use synchronous messages (we're representing method calls);
  • if you add a new operation, add that operation to the appropriate class in the class diagram. Make sure you add it to the right class!
  • return arrows really shouldn't have names, but some tools do give them names by default.
  • pay attention to activations (the bars on the lifelines) and to parameters to messages.

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. 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.

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?

  1. Still in LucidChart (and again, optionally in another tool you consider for Part 2) build state diagrams for your classes Student and/or Course, depending on what qualitatively different states there are in your solution. Make sure you find out how to have a condition on a transition. Consider what language to express your condition in.
  2. What constraints should be satisfied by legal configurations of objects of your classes? Write them in OCL. (You can start by - for practice - expressing the multiplicity constraints from your associations in OCL - note, though, the convenience of generally not having to express such constraints in OCL given that UML provides the special multiplicity notation. What else can you think of?)

Part 2

This course has introduced you compulsorily to only a few UML tools. There are hundreds of others, of many kinds. In past years this course has used tools based on Eclipse in a DICE lab and you can find old versions of those labs here. However, there are lots of others. In this part of the lab, your task is to explore. If you find other online (no-installation) UML tools that you particularly like, please post to Piazza about them as I would like to know! There are certainly many that do require some installation that are worth looking at. draw.io and MagicDraw are popular; the Papyrus project, which you'll meet in a few weeks and which this course used more extensively in the past, has an associated education-focused tool called PapyGame developed by Antonio Bucchiarone and colleagues, and the focus of several past UG4 projects; and almost all of the heavyweight commercial tools have either cut-down community versions, or free trial versions, or both. There is a Wikipedia list (of varying reliability and up-to-dateness) of UML tools Googling characteristics or features of interest may well find you more.

This exercise is deliberately open-ended (and, I hope, interesting to you, if you may indeed end up in a position to influence a project's choice of modelling tool in a few years' time) but some questions to think about include:

  • why is this tool interesting? What is different about it, compared to what you have seen before?
  • where does it fall on the spectrum between constraining you to create fully correct UML diagrams, and allowing you to draw whatever you like, even if it isn't correct UML?
  • how easy is it to use?
  • how easy is it to learn (NB not the same thing as how easy it is to use after you've learned it)?
  • does it have, or link to, interesting functionality beyond the drawing of diagrams? Can you generate code? Documentation? Reverse engineer diagrams from code? Define your own modelling language? Something else?
  • does it seem to be up to date? Is there an active community? Documentation? Example projects? Tutorials?
  • is it commercial, open source, or something else? (Consider whether you might like to do a final year project baed on it! I'm very open to self-proposed projects relating to modelling, from students who are enthusiastic about something.)
License
All rights reserved The University of Edinburgh