OOP Terminology : Part VI - UML
October 13, 2008
UML is a useful tool for designing OO applications. As part of my OOP terminology mini series, I thought I'd show an example of how you would document a simple system with UML.
UML stands for Unified Modelling Language and is standard graphical language. It is often used by OO developers to help design your application, by creating a visual representation of your class structure. You can also use it to document other aspects of your software, but as there are several hefty tomes dedicated to UML, this post is going to be a quick overview of using it to design a class structure.
I've mentioned in previous posts class inheritance, interface implementation, composition and aggregation. Wouldn't it be great it we could show this as a nice diagram. Well we can, have a look at this:
So what does it all mean?
Well, let me explain. I should point out that the colour coding I've used is not part of UML, I'm just using it to help differentiate between my classes.
Starting at the bottom we can see two classes called Man and Woman. I hope you’ll excuse the gender stereotyping (and yes, I do like watching football and no I don't wear makeup). From the diagram I can see that my Man Class has two public methods called watchFootball() and isWatchingFootball(). I know that they are public, because they are prefixed with a +. I also know that calling the isWatchingFootball returns a boolean (true/false) response. The other thing in the Man class is the instance variable WatchingFootball which is a boolean value. I won't describe the Woman class as I think you'll understand the concept now.
The type of arrow that points from the Man to the Person class shows that the Man class IS-A Person and so it inherits all the methods and properties of the Person class. Looking at the Person class, you'll notice that it is described as <<abstract>>. Somewhat surprisingly, this tells us that it is an abstract class!
The Person class has relationships defined to the Address class and also the BloodGroup class. A diamond on the end of a line between two classes shows that there is a "HAS-A" relationship between them. In other words, a Person has can have an Address and a Blood Group.
A person must have a blood group; this is shown by using a solid diamond. The numeral 1 next to the diamond indicates that a Person can only have 1 blood group. It is a one-to-one relationship. If we were modelling a car then the car object would have a one-to-four relationship with a wheel object, so we'd change the 1 for a 4.
As a person can unfortunately be homeless, I'm using a hollow diamond to show that this is not a required relationship. Although some people have no home, some have more than one, so we are showing this with the label 0..*. This means, zero or more. You may also see this written as just a star on it's own. This syntax can also be used to show that the person needs to have between 2 and 4 homes with 2..4.
Finally, we get to our Mammal interface, we can see that it is an interface because of the <<interface>> caption (remember, I've added the colour coding). The dotted arrow between the Person class and the Mammal interface shows that the Person class implements the Person class.
So, there you go, UML in a very small nutshell :)
- Posted in:
- OOP
2 comments
Leave a comment
If you found this post useful, interesting or just plain wrong, let me know - I like feedback :)
I found you blog very easy to understand although I have a question...
Why would you use a must have relationship? When the design calls for an object to exist at all times from when an object of the parent class is created?
I'm doing an assignment based on has-a relationships and I just need some clearification.
Regards
Keagan
Comment by Keagan – October 15, 2008
Comment by John Whish – October 15, 2008