UML tutorial part1

 
Visual Case Tool - UML Tutorial

Welcome to the Visual Case Tool – UML . An introductory overview to UML (Unified
Modeling Language) is given in the following pages with the help of  Visual Case. UML is
considered to be complex and rich modeling language and this tutorial aims to give you an
overview of the most common aspects of this language.

Unified Modeling Language (UML)is a graphical modeling language that is used to enhance
the object oriented designs. The language has been standardized so that the artifacts and
components can be specified for the development of a software system. UMLS should be
considered as a notation and not a process. This is because UML does not provide with a single
method or design process, but is considered as a standardized tool that can be used in a design
process.

There are in total eight UML diagrams which you can go through in this tutorial. But before we
start, download Visual Case(only the trial version - free of charge for 30 days)  so to aid in the
understanding of the tutorial and for hands – on experience.

The Use Case Diagram

Use case diagram is the first one in the design processes which most of the designers will start to
work on while initiating a project. The use case diagram brings out the depiction of the high level
user goals which are to be carried out by the system. Such high level user goals may not be
necessarily actions or tasks, and on the other hand be specifications for the general systems
functionalities.

Use Case

Technically defined, use case is actually a set of scenarios. Each of theses scenarios is actually
an order of steps which define the interaction levels between an user and the system. A use case
collates all the scenarios which implement a specific user goal.
A use case is a textual description of the scenario steps which are required for ideal or the
positive flow and also any alternate scenario possible at each of the steps. Here, there is a sample
use case which gives the flow as to how the keyword search is done on the website:

Ideal Flow:

1. The keyword is entered by the customer on the website

2. The search button is clicked by the customer.
3. Search is completed
4. Search results are displayed

Alternative Flow: Search Fails

If the search fails at step 3,  Redirect User to search screen at Step 1

With the help of the Visual Case tool which you have downloaded, the use case steps can be
specified in the description field. To do so, you will have to right click on a particular use case
and elaborate on the properties. A report can then be run by you and even printed or exported to
HTML or ASCII text for evaluation and proofreading purposes. In totality, the use case diagram
and its report include all of the use case details such as the scenarios and actors required for the
system design process.

Actor

The use case diagram is used by the designer to graphically represent the use cases and the
involved actors. An actor can be defined as a role which is played by a user in the system. The
distinction of a user from an actor (or user role in a system) should be made more clearer. A
system user can have different roles according to the action performed and an actor may be the
role itself or even another system. An actor can be for e.g -  a salesperson, support person,
manager and even a web store system. In the physical world, the same user may be performing
two roles - a sales person and support person. Hence, while a use case diagram is being modeled,
the roles and the action being performed by them should be concentrated on rather than the user
or individual.
Associations

While modeling the use case diagram associations are usually drawn  between the actors and use
cases in order to depict the actor carrying out or performing the use case. There is a one to many
relationship between a use case and an actor which can be explained as a use case which can be
performed by many of the actors and vice versa.

As depicted in the above diagram, the stick figure shapes in green on the left are actors,  the blue
ellipses are the use cases, while the connecting lines in between them as the associations. The
specifications for the system and user roles are done jointly by the developer and stakeholder
while the model is created by the developer alone.

Includes

There are three other links through which the use cases can be related to one another. One of
these is the use of “ Include” link which is depicted in the diagram below. The use cases invoice
purchase and online purchase include the scenarios which is defined by purchase valuation and
hence the <<include>> link. So, this link actually helps to minimize any scenario repetitions in
case there are multiple use cases.
Generalization

A ggeneralizationh link is used when a use case describes a variation of another use case. As
depicted in the below example, limit exceeded use case is a scenario is which the scenario of
online purchase is not acted upon and hence the generalization link is shown from the former to
the latter. Use cases which have a generalization link to another use case actually depict an
alternative or exceptional scenario to the latter use case. Inspite of the generalization, the final
goal remains the same for the use cases.

Extends

In some cases where the behavioral variation is to be described in a controlled manner, then you
can define extension points in the extended use case. As given in the below example, search by
name is extending search at the extension point of name. The extends link is more controlled in
manner in comparison to the generalization link as the  former link can be added only at the
extension points.
Putting it all Together

While starting on the modeling of a use case, it is vital that the simplicity of the diagram is
maintained. Firstly the system actors should be determined and only after that should the use
cases being performed be finalized. It depends on you , whether the use case diagram is simple
or complex but you should remember that the more simpler and uncluttered it is, the easier it will
be for understanding purposes and will be better in capturing the system tasks. With the help of
Visual Case tool, a use case can be exploded or drilled into a new use case diagram. For e.g,
there may be further specifications which are required for the use case online purchase as we
delve into the depth of the design process. A sub-diagram can be created within any of the use
cases in order to clarify and understand the sub tasks which are involved. It should be that a use
case actually is the representation of a user goal and not any atomic programming operation. The
point here is that there should be a simple use case design so as to clarify the user expectations
for the system.

UML tutorial part 2

 
3. The Class Diagram

The class diagram is considered to be the core of the object-oriented design. The class diagram
depicts the system object types and the prevalent static relationships between these objects..

Packages
Packages are used to break up a large number of objects into related groups. In many of the
object oriented languages (e.g -  Java), packages have been used in order to provide to the classes
and interfaces more scope and division. In the UML diagrams, packages have a similar and in
fact broader perspective.

In Visual Case, any of the UML diagrams can have packages. Each of these packages can
contain any of the types and in any number of other UML diagrams, as well as the classes and
the interfaces.

Classes

Class is the core element of a class diagram. In any object oriented system, system entities are
represented by classes. These entities often relate to real world objects.

Given above is an example of  a simple Contact class which stores the location information.

Classes can be classified into three categories:

Top: The name, package stereotype displayed in the upper section compartment of the
class. In Visual Case, classes which do not belong to the same package are shown on a
diagram with their entire path name. A stereotype can be optionally assigned to a class.

Center: In the center section of the class, the attributes are enumerated.

Bottom: The lower section contains the operations which a class can perform.
In a Visual Case class diagram, both the attribute and operations sections can be both hidden or
shown as is required for all or individual classes. It is mostly used when you want your class
diagrams to be able to highlight only specific constructs of your system and the superfluous
information such as operations and attributes can confuse and clutter the diagram.

Attributes

An attribute is considered as a property of a class. As shown in the above example, Contact

class has the attributes such as an address, province, a city, country and a postal code. During the
implementation of the class, functionality is provided in such a way so as to set and retrieve the
information which has been stored in the attributes. The methods which are used to set and
retrieve attribute data are known as accessor methods(also called as getting and setting
methods) and are generally not shown as they can be inferred.

The format for the attributes of a class is given as follows:

visibility name: type = default Value

The visibility is as given below:

- Private

+ Public

# Protected

~ Package

During the process of object oriented design, most attributes are preferably kept as private so that
the accessor methods can control access to the data. The most common exception to this
preference are constants.

Visual Case allows you to specify the following properties for an attribute in addition to the
name, data type,visibility, and default value,:

Array: an attribute can be set to be treated as an array of attributes and is displayed with
square braces [ ]name.
Static: static attributes can exist only once for all of the class instances. As in the example given
above, after city is set as static, if at any time the Contact class is used then the city attribute
would always give the same value.

Final: final attribute's value cannot be changed i.e. its regarded as a constant.

Operations

The class operations represent the tasks or functions which can be acted upon based on the class
data.

In the List class shown above, there are three operations and one attribute (an array of Objects)

The format for operations can be given as:

visibility name (parameters): type

The format for operations can be seen as very similar to the syntax for attribute except for the
removal of a default value and the addition of parameters.

Parameters take the format:

direction name: type = default value

The direction can be one of the many options such as in, out, inout or it can be unspecified.

In Visual Case, the parameter list for one or all classes given can be shown or hidden. If the
parameters list is hidden for an operation which has parameters, then it will be depicted as three
dots (...) to indicate parameters do exist for the operations, but are now hidden. For some
operations there are a number of parameters and hence they need not be shown all the time.

Generalization

Two classes can be linked with the generalization link in order to depict that one of the  class
has all attributes and operations of the other class, but also has additional ones.
Lets look at the above diagram in which the Contact class now has two child classes. So it can be
said that the classes Client and Company have inherited, generalized or extended Contact
class. In the child classes Client and Company, the attributes of Contact class (address, city, etc.)
exists, but in addition there are other attributes. So, as is depicted in the above diagrams, Contact
class is said to be the main class or superclass of child classes Client and Company.

The child classes may override the operations in the super class in some cases with the
generalization link being used. In such cases, the child classes can include an operation which is
actually defined in the superclass, but they can define a new implementation for the operation.

In the above diagram, OntarioTaxCalculator class diagram redefines or overrides the operation
implementation in BasicTaxCalculator. That is , the operation is called in the same manner yet
the code is different.

Sometimes the child classes need to be forced to override the operations of a parent class. In such
a scenario the methods or operations in the superclass can be defined as abstract. The class can
be defined as abstract if it has abstract operations. Each of the abstract methods and the classes
have been shown in italics. But it is important to note that all of the operations in any of the
abstract class don't have to be abstract.

The abstract operation calculateTaxes in AbstractTaxCalculator must be implemented in the

child classes OntarioTaxCalculator and NovaScotiaTaxCalculator. As the operations has to be
implemented, it is not essential to display them in the child classes, but its actually up to you.
The key should be to have the diagrams as simple and clear as possible. The above diagram is
simple and its meaning clear, but with the multiple levels of inheritance and more number of
attributes and operations, you may choose to specify all of the methods that are overridden
 

Interfaces

MANY OF THE OBJECT ORIENTED PROGRAMMING LANGUAGES DO NOT ALLOW MULTIPLE

INHERITANCE. THE INTERFACE CAN BE UTILIZED TO SOLVE THE LIMITATIONS POSED BY THIS
PROBLEM. FOR E.G, IN THE CLASS DIAGRAM GIVEN EARLIER CLIENT AND COMPANY CLASSES
GENERALIZE CONTACT CLASS AND ONE OF THE CHILD CLASSES MAY HAVE SOMETHING IN
COMMON WITH A THIRD CLASS WHICH WE DO NOT WISH TO COPY IN MULTIPLE CLASSES.

The interface Sortable, is used in the above diagram to depict the child classes Company and
Product can implement the operation sort. It can be said that Company and Product implement
Sortable or they are Sortable. Because Product class already generalizes Contact, we cannot
allow the same to generalize Sortable. So, we can make Sortable an interface and add a
realization link to depict the implementation.
Interfaces are similar in structure and functionality to abstract classes but they do not have any
attributes. All of the operations in an interface have no implementation, unlike that of a class.
The child classes Company and Product are forced to implement the sort operation in it's totality.

ASSOCIATIONS

CLASSES CAN ALSO HAVE REFERENCES TO ONE ANOTHER. IN THE DIAGRAM BELOW, HE COMPANY
CLASS HAS TWO ATTRIBUTES WHICH ACTUALLY REFERENCE THE CLIENT CLASS.

This is technically correct, but it can be more expressive to display the attributes as associations.

In the above diagram, the two associations have the exact same meaning as the attributes in the
earlier version of the Contact class.

The first association (the top one) represents the old contactPerson attribute. There is one contact
person in a single Company. The multiplicity of this association is one to one meaning that for
every Company there is one and only one contactPerson and for each contactPerson, there is
only one Company.

In the second (bottom) association, there are zero to many employees for each of the company.
Multiplicities can be specified by you as anything such as  given below:

0 zero

1 one
 1..* one or many

one, two or ten and above but not three

1..2, 10..*
through nine

At the end of each association , the arrows represent their navigability. In the above given
examples, the Company class references the Client class, but the Client class does not have any
idea of the Company. So, the navigability on either, neither or both ends of your associations can
be set accordingly. If no navigability is to be shown then the navigability is unspecified in the
diagram.

AGGREGATION AND COMPOSITION

 The above given example displays an aggregation association and a composition association. 
composition is depicted by a solid diamond. The ProductGroup composed Products. This in
turn means that in case a ProductGroup destroyed, the Products the group will be destroyed as
well. The aggregation association can be depicted by a hollow diamond. PurchaseOrder is an
aggregate of Products. Even if PurchaseOrder will be destroyed, the Products will still exist.

In case you have confusion regarding the difference between the composition and aggregation,
all you have to do is to just think of the alphabet of the word Composition which means destroy
and the letters 'c' and 'd' are right next to each other.

Dependencies
A dependency can exist between two elements in a way that in case there are any changes to one
of the elements then it will also affect the other. For e.g, a class calls an operation in another
class, then there is a dependency between the two classes. If the  operation is changed, then the
dependent class will also change. The goal should be to minimize the dependencies, while
designing the system,

To help get clarifications on the dependencies in the design, you can draw a Package Diagram.
A package diagram is nothing but a class diagram in which the packages and dependencies are
displayed. Dependencies may exist between any of the components in the UML diagram.
However at the highest level, dependencies will actually exist between packages. In a package,
the dependencies can be numerous more than can be specified. But it's not that such numerous
dependencies are okay. Even within a package its better to limit the dependencies,  particularly
between the packages and be strict about the number of dependencies which exist. In general,
lesser the dependencies the more scalable and maintainable the system will be.

Putting it all Together

Class diagrams  are considered to be the core of most object oriented designs so you will be
finding yourself using them most of the times. Class diagrams actually closely relate to most of
the object oriented languages, so the basics such as the classes, the operations, the attributes, and
generalizations, etc. should be fairly easy enough to be grasped. You should start with what you
know and then probably move forward.

The most important thing which should be said about design is that you should not feel bogged
down by it. In fact it will be better to have a collection of clear diagrams than many confusing
and complex diagrams. In a previous example we saw the AbstractTaxCalculator was
generalized by OntarioTaxCalculator and NovaScotiaTaxCalculator. If we tried to create a
diagram with all ten of the Canadian provinces and three territories we would have built a huge
and complex mess. In case we were designing a tax system for United States and suppose we
tried to depict all of the states, we would land up in even more trouble. It will be clearer, and
maybe just as expressive to show two or even three child classes and to add a note or comment to
the diagram which explains that the other provinces and territories are to be implemented in the
same way.

To keep the designs simple will allow you to be more productive and make your designs more
usable and understandable. To add, as the system will be implemented and upgraded, the design
should be kept in sync with your implementation. This will be far more easier with a simple and
clear design of the key system concepts.

4. Interaction Diagrams - Sequence and Collaboration

After the use cases have been specified, some of the core system objects can be  prototyped on
class diagrams so that the designing of the system dynamic behavior can be done. If you recall
the Use Case section of the tutorial, a use case encompasses an interaction in between a user and
a system. Typically, an interaction diagram captures the behavior of a single case by depicting
the collaboration of the system objects in order to accomplish the task. The diagram given below
displays the system objects and the messages which are to be passed between them.

We can start with a simple example which is given above: that of a user logging on to the
system. The Logon use case can be specified by the following steps:

Ideal Flow:

      Log on dialog is displayed

USER NAME AND PASSWORD IS ENTERED BY THE USER

OK BUTTON IS CLICKED OR THE ENTER KEY IS PRESSED BY THE USER

THE USER NAME AND PASSWORD ARE CHECKED AND THEN APPROVED

THE USER IS ALLOWED TO LOG ONTO THE SYSTEM

Alternative Flow: Log on Failed

            IF AT STEP 4 THE USER NAME AND PASSWORD ARE NOT APPROVED, ALLOW THE USER TO
TRY           AGAIN

We can now have a simple Use Case with which to work with and some of the classes involved
in the interaction can now be specified.

The LogonDialog has public methods to display and hide the window, and a private method
which can be called when the user clicks the OK button or presses enter. In our example (and
most of the cases) you need not specify the interface dialog elements.

Our design also includes a LogonManager class that will include one method which  returns true
if the log on is successful, and false in case it fails..

A DatabaseAccess class will allow us to run queries for our database. A query string can be
passed and a ResultSet of data will be returned.

Now that we have prototyped the classes involved in our interaction, we can begin to make our
interaction diagrams.

 UML tutorial part 4

 
Instances and Messages
Interaction diagrams mainly consist of instances and messages. An instance can be considered as
the realization of a class. So if there is a class Doctor, then the instances of the class can be Dr.
Jones, Dr. Smith, etc.. In any of the object oriented application, instances are what exists when
you instantiate a class (that is create a new variable with the class as its data type).

In the UML diagram , instances can be represented as rectangles with a single label which is
formatted as:

InstanceName: data type

You can also choose whether to name the instance or not. But the data type has to be  specified at
all times. After the name, the attributes and their values can be listed. In Visual Case tool, the
attributes from your class can be mapped and new values specific to that instance can be entered.
Attributes need to be shown only when they are vital and you don't have to specify and display
all of the class attributes.

Messages actually represent operation calls. So, in case an instance calls an operation in itself or
in another class, a message will be passed. Also, on the completion of this operation a return
message will also be sent back to the instance which had initiated the call.

The format for message labels can be given as:

Sequence Iteration [Guard] : name (parameters)

Sequence: actually represents the sequence in which the message will be called.     The sequence
is redundant on the sequence diagrams, but is required on            collaboration diagrams

Iteration: an asterisk (*) is shown to represent iteration if the message is called repeatedly

Guard: is an optional boolean expression (the result can either be true or false)

which actually determines if the message is called

Name: represents the operation which is called

Parameters: represent the parameters on the operation which is called

Sequence Diagrams
The two types of Interaction Diagrams are - Sequence and Collaboration. Sequence diagrams
emphasize the sequence  in which the things happen. On the other hand collaboration diagrams
provide more flexibility in their layout. When drawing interactions you can choose between
these two depending on your preference, since both show the same information.

An example of a sequence diagram for our logon collaboration is gicen as below:

Things which should be noted:

ｷ        The flow of time is depicted from top to bottom, that is messages which are higher on the
diagram occur before those which are lower down

ｷ        The blue boxes are actually instances of the represented classes, while the vertical bars
below them are the timelines

ｷ        The arrows (or links) are the messageswhich are either the operation calls or return calls
from operations

The hide and show messages use guards in order to determine which to call. Guards are always
displayed in square braces [ ]and they represent the constraints present on the message (the
message will be sent only if the constraint is satisfied)
 ｷ        The messages are labeled with the operation which is being called and parameters are
displayed. It can be chosen whether to enter the parameters or not - this is dependent
upon their importance to the collaboration which is being shown

THE SEQUENCE NUMBERS ARE NOT DEPICTED ON THE MESSAGES AS THE SEQUENCE IS INTRINSIC
TO THE GIVEN DIAGRAM

Asynchronous Messages

A message can be specified as asynchronous in case the processing continues while the message
is being executed. In the below given example, the asynchronous call does not block the
processing for the regular call which is there right below. This is useful in case the operation
which is being called is run remotely, or in another thread.

UML tutorial part 5

 
Collaboration Diagrams

Collaborations are more complex to follow rather than sequence diagrams, but they provide the
added benefit of higher flexibility in terms of spatial layout.
Given above is a collaboration diagram for our logon interaction. You can probably notice that
each of the messages is numbered in an order. This is because it is not obvious from the diagram,
what the order of the messages is .

Lollipop Interfaces

Another advantage which can be given for the collaboration diagrams over the sequence diagram
is that the former allows to show lollipop interfaces.

Lets say that our DatabaseAccess class implemented an interface which is called Queryable. In
case the logon manager has access only to the interface, we can show that the message is being
called through the interface by including a lollipop interface on the diagram. The stick of the
lollipop indicates that the class DatabaseAccess realizes Queryable.

Putting it all Together

With the use of diagrams, the sequence of operation calls among objects used to complete a
single use case can be clarified. While drawing these diagrams, you should try to keep them as
clear and simple as possible. Sequence diagrams may be easy to read and follow, as they enforce
a more standard layout on the diagram. Collaboration diagrams have the added benefit of
interfaces and the freedom of layout, but they can be difficult to follow, understand and create.

It's important also not to confuse interaction diagrams with state and activity diagrams.
Interaction diagrams are used in order to diagram a single use case. If you want to examine the
behavior of a single instance over time then you should use a state diagram, and In case you want
to have a look at the system behavior over time then you should use an activity diagram.

UML tutorial part 6

 
5. ACTIVITY AND STATE DIAGRAMS

Previously we have seen how the interaction diagrams demonstrate the behavior of several
system objects while executing a single use case. When you want to display the order of events
on a broader scale then you should use activity and state diagrams.

Activity Diagram

An activity can be defined as the execution of a task whether it be a physical activity or the
simple execution of code. Simply put, the activity diagram depicts the sequence of activities.
Like any simple flow chart, activity diagrams have the support for conditional behavior, but also
have added support for parallel execution as well.

Start: each activity diagram has only one start (symbol above) at which the sequence of the
actions begins.

End: each activity diagram has only one finish at which the sequence of actions ends
Activity: activities are to be connected together by transitions. Transitions are actually directed
arrows which are flowing from the previous activity to the next activity. They can be optionally
accompanied by a textual label of the form:

[guard] label

The guard is considered to be a conditional expression which when true indicates that the
transition has taken place. The label is optional and is represented in free form.

To show conditional behavior you can use a branch and a merge. The top diamond is a branch
and can have only one transition flowing into it but any number of mutually exclusive transitions
flowing out. So, the guards on the outgoing transitions must resolve themselves in order that only
one is followed. The merge is used to finish the conditional behavior. There can be any number
of incoming transitions, and only one outgoing transition.

To show the parallel behavior you can use a fork and a join. The fork(placed at top) has only
one transition entering and any number of transitions which are exiting, all of which will be
taken in action. The join(placed at the bottom) represents the end of the parallel behavior and has
any number of transitions entering while there is only one leaving.

UML tutorial part 7

 
State Diagram

The state diagram depicts the change of an object through a time period. Based up on the events
that occur, the state diagram displays how the object can change from start to finish.

States can  be represented as a rounded rectangle with the name of the state displayed as shown
above. You can optionally include an activity which represents a longer running task during that
state.

Transitions connect these states together. These represent the events which cause the object to
change from one state to another. The guard clause of the label is mutually exclusive and must
either be true or false. Actions represent the tasks which run so as to cause the transitions.

Actions are varied from activities in the way that their actions cannot be interrupted, while an
activity can be interrupted by the incoming event. Both can actually display an operation on the
object which is being studied. For example, an operation which sets an attribute would be
considered an action, while a long calculation might be considered as an activity. The specific
separation between the two depends actually on the object and the system which is being studied.

Like the activity diagrams, state diagrams have only one start and one end from which the state
transitions can start and end respectively.

Putting it all Together

Activity diagrams are used to depict the work flow in parallel and also conditionally. They are
useful while working out the order and the concurrency of a sequential algorithm and that too
while analyzing the steps which are there in a business process and while working with threads.

State diagrams display the change of an object over time and are useful when an object exhibits
interesting or unusual behavior - such as that of a user interface component.

As always, these diagrams should be used only so as to serve a purpose. You should not  feel that
a state diagram should be drawn for every system object and an activity diagram for every
system process. You should use them only here they add value to your design. You may choose
not to include these diagrams in your system design, and your work may well be considered to be
complete and useful. The purpose of Visual Case Tool and of these diagrams is to help you to do
your job. So if the diagram becomes too complicated and confusing, you and those working with
you may lose focus of the task at hand.

6. Implementation Diagrams - Component and Deployment

So far, we've seen how the tasks which the system will perform can be diagrammed along with
the details of the system classes, and the system dynamic behavior. But what about the big
picture? There are two types of implementation diagrams which strive to provide the solution.
With the deployment diagram, you can depict how the system components are physically
related, and with the component diagram, you can display the components in the system which
are organized.

You can combine the two diagrams if you wish:

Above, the nodes are given in green and the components in maroon. The nodes represent
something upon which a component can run, and components are units of software.
On the diagram, nodes are connected with connections which displays the physical path of
information with in the system. Components are connected with directed dashed lines which
represent the communication between components. You can also use lollipop interfaces on
components to depict which of the communication is actually through an interface.

Putting it all Together

The physical diagrams will help with the overall structure and distribution of the system. The
component and deployment diagrams can be drawn separately or combined as you choose to do.
Also, the components within the nodes need not be displayed as given above, although it will
help in the overall understanding of what is being executed where.

Visual Case Tool - UML Tutorial

7. Summary & Further Reading

Now that you have the basics of each kind of UML diagrams, you're ready to begin. You can
now Download the trial version of the Visual Case Tool and try some of the simple designs.

You should but remember what each UML diagram is and what each is used for:

Use Case diagrams help to specify the user goals that the system has to carry out.

Class diagrams depict the physical structure of the system objects and their static relationships.

Sequence and collaboration diagrams give the dynamic interactions between instances which
are used to carry out a single use case.

State charts diagram depict an instance over time and the events that cause it to change.

Activity diagrams are good for giving details on  high level processes that require conditional
and parallel processing.

Physical diagrams give you an overview of the structure, distribution and implementation of
your system.

Putting it all Together

You should not be overwhelmed with the semantics and detail.  UML is a very rich and detailed
language and you should remember that there is no need to master each and every bit of
information at first. You should first strive to get comfortable with the basics.

Also, you should keep your diagrams very simple. Each of the UML diagram should have only
one key concept or design feature which you're striving to explain. Further, that key concept or
feature should be interesting enough. You don't need to design the very obvious features as you
should not be redundant. You should express what needs to be expressed and move forward.

Finally, all of the diagrams in this tutorial have been created with Visual Case, so you should
Download the trial and get started with your own system designs.

In order to get Further Information!!

You can browse the web for various resources such as message forums, other tutorials and more
examples.

A good and very accessible book which should get you started is: UML Distilled Second
Edition - A Brief Guide to the Standard Object Modeling Language