I’ve been working through a bunch of pre-interview coding exams/exercises, and I’ve decided to post some of the problems I’ve been given that I find interesting and/or challenging. This first one, however, has some urgency to it. Can anyone explain this diagram to me??
- WTF are those numbers?!
Hope I don’t get in trouble for posting this or something, LOL.
I think the numbers mean that for 1 company — you can have many (n) employment contracts. And each person has 0 or 1 employments contracts…. Yeah… :)
I’m hoping that you understand that the boxes are objects and their variables.
I found this to be helpful to explain the other stuff: http://en.wikipedia.org/wiki/Class_diagram
..especially the part about Multiplicity at the bottom.
It’s been a while since I’ve been required to know UML. Too bad we don’t write those on a daily basis at my company.
Yes, Erin’s right. Company to EmploymentContract is one-to-many, and each Person has at most one EmploymentContract.
LOL, thanks guys. (Hi Chaz, heh) :) I figured that’s what it was, but here’s the part that still throws me…I was supposed to write the code that corresponds to this diagram. Not a problem, but to represent potentially n Company objects in EmploymentContract, would I just throw in an ArrayList into EmploymentContract?
That doesn’t seem right, for some reason, because my understanding of UML is that you would only implement what’s in the diagram…but this feels so empty, like I would need to add more methods to each class (well, especially EmploymentContract) for them to do anything useful here.
Oh, and BTW, those yellow boxes in the Wikipedia page are from a KDE/Qt program called Umbrello…sweet program for doing this stuff. Too bad I used it (while at UIUC last summer) without knowing UML apparently LOL. :)
I think this UML diagram is more about showing how the different objects relate to one another, not a complete blueprint for implementation.
How you represent this in code is up to you. If you used an ArrayList, it would go in the Company, not the EmployeeContract, since a company has many contracts, not vice versa. And to fully represent this relationship literally, you would need a pointer/reference to the Company in the EmployeeContract object too since the relationship is two way, after all. That gets a bit more annoying to maintain, though.
Really, unless if you are using an ORM like ActiveRecord or Hibernate which automagically generates accessor methods based on an XML file or database schema, you would only implement these relations as you need them. Otherwise, you might end up wasting a ton of time on code that never ever gets run.
@Spad: If your systems have such a complicated hierarchy of classes that they would benefit from being described in UML, I would say not describing them in UML is the least of your problems. ;-)
Since this is preparation for interview, where tricky questions may get thrown on a 1d6 basis, I’d like to point out a couple of other things: the “n” on the EmploymentContract side normally include zero, in which case the company has no employment contract with anybody. On the other hand, an EmploymentContract object instance cannot exist without exactly one Person and one Company (whether “null” is allowed in such case is up to your implementation).
Pingback: Counter-Intiutive UML « Diane says “word” and a bunch of other nerdy things