UML Introduction for java programmers - DOC by exx10251


									UML Introduction for java programmers
And how to use it well

Class Diagrams

The Class

UML consist of several different parts, each of which models a different aspect of a
project. The most unfamiliar type of diagram is the structure diagrams. Several kinds of
UML diagram fall into this category and all of them model the structure of a program, in
other words how it is put together and how the parts are related. The one other main type
of diagram is the behavior diagram, these deal more with state and the way that the
program actually works. In fact one kind of behavior diagram is almost the same thing as
a flowchart. The last major metatype of diagram is the interaction diagram, these are
subtypes of the behavior diagram but they have a wider focus. Interaction diagrams
model communications between different components of a program at runtime. Each of
these three types of diagram has three or more actual diagram standards associated with
them. You may be overwhelmed by the sheer number of diagrams in UML, but luckily
you don’t have to learn all of them. The interesting thing about UML, or maybe the
annoying thing about it is that it is probably not a good idea to use all of the different
diagrams for a project, in fact most types of UML are never used. Parts of UML model
things that code or psudocode does better and for this reason I will not be talking about
these parts at all. This is a tutorial on class diagrams only, these are the most common
and most useful type of UML diagram, if you find that you need to diagram out the really
inner workings of things on most projects then it may be a good idea to simplify your

The main type of structure diagram is the class diagram. This diagram is designed to
model all the classes that are in your program, as well as their members and visibility.
The class gives you an idea of the components of your program and how they are related.
This is a good first or sometimes second step in your planning. Each member of a class
diagram is a rectangle divided into three parts



Each of these represents a class, you write some indication of the attributes(variables) in
the middles section and some indication of the methods in the bottom section. In general
the way you represent a variable is something like [+#-~] type : name = default value the
sign at the beginning of the variable “definition” is the visibility of the variable + is
public # is protected, - is private and ~ is package (this one is very optional as package is
the default visibility of things in java). These visibility modifiers can be used on both
methods and attributes.
In the methods section you put the names of methods in the form of [+#-~]
name(args):type the arguments are formatted just like attributes but without a default
value or visibility modifier. In general getters and setters tend to be excluded from the
UML. In fact it is your choice how much detail to put in a UML diagram and it really
depends on how large of a project you are working on.
        The last (or first) part of a class in UML is the name, this is written in bold for
normal classes and italics for abstract classes. What follows is an example of a complete
class diagram for one class.


     - ArrayList : deck

     + shuffle() : void
     + loadDeck() : void
     + deal(numCards : int) : Hand

So this tells you something about an individual class but there is not enough information
here to justify the work that goes into creating the diagram, we need to know about the
connections between multiple different classes. For this we need connections.

There are TONS of different kinds of connections or relationships and each of them has
all sorts of properties and spots for names and labels. The thing to remember is that you
should not constrain yourself to the exact words of the UML specification, in fact I have
noticed that different editors seem to treat the relationships differently. The point is that
you should use UML in a way that effectively models your program, if you don’t feel the
need to ever use a certain type of relationship then you do not have to.
What follows is a chart of how the relationships are drawn.
                                                  Aggregation – This relationship shows that
                                                  one class contains another, the diamond is
                                                  always on the contained class, the child.
                                                  Generalization – This is the inheritance
                                                  relationship. The arrow points from the
                                                  child to the parent
                                                  Association – This is the most general kind
                                                  of relationship, all that this means is that
                                                  one object is doing something to the other
                                                  like calling a method.
                                                  Dependency – This is again a weak form of
                                                  relationship. This shows that one object
                                                  depends on another object or uses it.

Package Diagram

         Package Diagrams work a lot like you would thing they would, they are for
organizing your classes into packages just like a java package. I see them as a way to be
able to model larger programs (the ones that really need modeling) without having an
extremely cluttered and useless diagram. A package looks like a picture of a folder. You
can have packages inside packages and there is also the import relationship which looks
just like the dependency relationship that indicates that you are importing one package
into another one.

What follows is a sample of a UML diagram for a set of cards to be used in a card game,
the only new thing here is the enumeration “class”. These are used to represent
enumerations and you can learn about those at (or read lou's paper).

To top