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 approach. 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 Name Attributes Methods 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. Deck - 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. 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 www.google.com (or read lou's paper).
Pages to are hidden for
"UML Introduction for java programmers - DOC"Please download to view full document