School of Informatics Courses: SDM Lab 1 University Homepage School Homepage School Contacts School Search Post-notes on SDM Lab 1: Relating UML and Java, using Umple (updated 2018) The exercises in this lab were essentially self-checking, so there are no model solutions. If you're not sure whether something you did was OK or not, post to Piazza about it and I'll gladly comment. Towards the end there are questions designed to provoke you to think, rather than to get answered precisely - feel free to post about those, too. Things I remember saying (possibly not this year!) that might be useful to anyone who had to miss the lab and is going through it afterwards (NB that's no substitute for actually being there, so don't miss the lab unless you have to!): Multiplicities in Umple class diagrams: put them in on the Umple text side, there isn't a way to do that in the diagram. If Umple gets confused (spinning wheel that doesn't ever get replaced by actual output) sometimes it helps to copy your Umple text code, shut down the Umple Online tab, start a new one, and paste your Umple code back into it. A class called System in a class diagram is a "bad smell" (technical term!) because it suggests that you're heading towards having all functionality in that class with the other classes relegated to being simple data containers. The classes in your conceptual class diagram should correspond to key concepts in the domain where the system will operate. Both attributes and navigable associations are properties of a class in UML, and both will typically be implemented by attributes in the eventual Java code. Don't represent the same information by both things. Use associations where the type of the eventual attribute will be one of the classes in the diagram (or a collection of them); use attributes where the type of the eventual attribute will be a base type, or something from a library that you're using rather than designing. One effect is: you should never see the same name as both the name of a class in your class diagram and the type of an attribute on your class diagram. This helps to obey the WRITE ONCE "rule". As we'll see a lot in this course, any time you have two manually-created representations of the same information, they have to be kept consistent, and that can be painful. So you only do it when there's very good reason to. Otherwise, write each piece of information once. Why does the Airline example have separate Role classes, rather than just using Person and specialisations of it? If we had Passenger and Employee specialising Person, then any actual object in the system of class Person, say the one representing Perdita Stevens, could turn out to be an instance of the subclass Employee or of the subclass Person, but not both ((begin nitpick) unless we're in a multi-classification setting which is a dragonous region of UML we don't go into because it doesn't correspond to anything you can implement in Java - and even then, there'd still only be one object (end nitpick)). But we want to allow for the case that I, Perdita Stevens, am both an airline pilot (say, due to pilot the 9am flight Edinburgh to Glasgow on 23/9/18) and a passenger (say, due to fly on the 6pm flight Glasgow to Edinburgh on 23/9/18), and we want to do this without duplicating the information that the system keeps about me because I'm a Person. (We've only got a small amount of information of that kind for now, but maybe there's lots; the system may also need to be able to handle constraints like "the same person can't be a crew member and a passenger on the very same flight" as briefly discussed in the lab.) That's what the role concept is for. There's a person object representing me, Perdita Stevens. If I ever fly on this airline (maybe I know too much about its safety record to do so...) there's a PassengerRole object that is linked to the Person object representing me. This object knows about stuff like my frequent flyer status and my upcoming bookings. Separately, there is an EmployeeRole object that is linked to the Person object representing me. This object knows about stuff like my salary and my record of employment. Alternatively, it would have been possible to combine all of this information into one class, but then the class would have ended up not feeling very cohesive - we'd have found that it was doing several, not very closely related, jobs. It would have felt unsatisfactory because, for example, the 99% of objects in the system that represent people who are only ever passengers would still have unused data nad functionality pertaining to employees. So it's better design to separate the functionality into several classes that are appropriately related. This makes the system easier to understand and hence to maintain. I doubt if anyone finished the state diagram part of the lab in the lab. As you do it (reinforcing the reading...), make sure you're clear on the difference between protocol state diagrams (have transitions triggered by events, possibly with conditions, do not have actions; are useful for clients of the class being described) and behavioural state diagrams (can have actions in addition to the elements that occur in protocol state diagrams; are useful for implementors of the class being described). Here's a pertinent question and answer from a previous presentation: Q: Can you tell us how to best abstract a system so that no unnecessary states are created so that the UML will not be overcomplicated A: There's no single right answer to this, but I think a reasonable rule of thumb would be: two fully-detailed states of an object should abstract into different states of a state diagram if there is something qualitatively different about the way the object behaves in the two states, so that the reader of the diagram needs to be aware of that. The reader might be someone intending to use the object (your client) or it might be someone intending to implement the object's code - these readers have subtly different requirements. Usually, the former will want a protocol state diagram, the latter a behavioural state diagram. For example, (see the first state diagram video) if an object should be initialised before it makes sense to send it the doIt message, then you can document that using a state diagram showing that the Uninitialised state is the first state reached after object creation, and then the initialise() message causes the object to transition to the Ready state, which has a self-transition caused by receiving doIt(). 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
