Benefits of UML

• Allow specification of architecture at abstraction level
• Define notation used in communication between designers, architects and developers
• Allow to systematicly capture reusable experience, solving re-occurring types of problem

UML basic notation elements

1. Elements
   1. Class
   2. Interface
   3. Collaboration
   4. Active class
   5. Component
   6. Package
   7. Note
2. Relationships
   1. Dependancy
   2. Association, directed
   3. Association, undirected
   4. Association, aggregation
   5. Association, composition
   6. Generalization
   7. Realization

1. Elements

1. 1. Class

Define basic unit of design, with ability to be instantiated as an object, In the definition the top field contains name, followed below by attributes and operations (containing method definitions), which can be defined with various accessibility:

+	public
#	protected
~	package
–	private
--	implementation visibility
(+)	forced public. Override of an interface method thatshould be treated as private, even if declared public

Obmitting accessibility, Java defaults to "package" access - however UML does not support the notion of a default access. Furthermore UML has no notion of "implementation visibility" (accessible only within an object - other objects of the same class cannot access it).

1. 2. Interface

Define basic unit of design, possibly containing operation method argument definitions, but without ability to be instantiated.

Strict UML uses the «interface» stereotype in the name compartment of a standard class box. A small circle in a corner of the compartment can also indicate an interface. Perhaps more relaxed, the intalic font interface in the name compartment may also specify an interface body.

Since interfaces contain no attributes, the "attributes" compartment is always empty.

1. 3. Collaboration

Marked with dotted line... in the diagram:

1. 4. Active class

1. 5. Component

1. 6. Package

Define body grouping a number of classes related in some way:

1. 7. Note

Define commenting remark not possible otherwise to specify with UML notation:

2. Relationships

2. 1. Dependancy

Defines situation where Class1 uses Class2, but Class2 is not a member of (field in) the first class. If Class2 is modified, some method of Class1 might need to be modified. Class2 is typically a local variable or argument of some method in Class2. The line is typically stereotyped (e.g. denoted «creates» or «modifies»)

2. 2. Association, directed

Defines relationships between classes. Associated classes are connected by lines. Can be directed or not. When relationship is identified, line is supplied with arrow head > or < (solid or not) to indicate direction.

Cardinality can be used to indicate relationship to either side:

1	exactly one (usually omitted if 1:1)
0..*	0 or more
*	0 or more (as above)
n	unknown at compile time, but bound
0..n	between 0 and some bound number unknown at compile time (n)
1,8	either 1 or 8
1..8	between 1 and 8 (both inclusive)

2. 3. Association, undirected

Defines relationships between classes. Undirected, associated classes are connected by lineswithout with arrow head > or < (solid or not).

Undirected means:

• it has not been decided if the association is directed
• the association is bidirectional

2. 4. Association, aggregation

Defines relationships between classes where destroying the "whole" does not destroy the parts.

Both "aggregation" and "composition" really don't have direct analogs in Java. An "aggregate" represents a whole that comprises various parts; so, a Club is an aggregate of its Members. A Meeting is an aggregate of an Agenda, Room, Attendees. At implementation time, this is not really a containment relationship since the parts of the aggregate might be doing other things elsewhere in the program. There's no implementation-level difference between aggregation and a simple "uses" relationship (an "association" line with no diamonds on it at all). In both cases an object has references to other objects. Though there's no implementation difference, it's definitely worth capturing the relationship in the UML, both because it helps you understand the domain model better, and because there are subtle implementation issues. It is possible to allow tighter coupling relationships in a composition than with a simple "uses,".

Cardinality specified as above.

2. 5. Association, composition

Defines relationships between classes with a (has) relationship. The parts are destroyed along with the "whole." Not really concept in Java - but used indirectly in the servlet definition, where method public void destroy() {} is called upon container shutdown. But used explicitly in C++ when defining destructor method to be called when object is destroyed.

Composition involves tighter coupling than aggregation, and involves containment. The basic requirement is that, if a class of objects (call it a "container") is composed of other objects (call them the "elements"), then the elements will come into existence and also be destroyed as a side effect of creating or destroying the container. It would be rare for a element not to be declared as private. An example might be an Customer's name and address. A Customer without a name or address is a worthless thing. By the same token, when the Customer is destroyed, there's no point in keeping the name and address around. (Compare this situation with aggregation, where destroying the Committee should not cause the members to be destroyed---they may be members of other Committees).

In terms of implementation, the elements in a composition relationship are typically created by the constructor or an initializer in a field declaration, but Java doesn't have a destructor, so there's no way to guarantee that the elements are destroyed along with the container. In C++, the element would be an object (not a reference or pointer) that's declared as a field in another object, so creation and destruction of the element would be automatic. Java has no such mechanism. It's nonetheless important to specify a containment relationship in the UML, because this relationship tells the implementation/testing folks that your intent is for the element to become garbage collectable (i.e. there should be no references to it) when the container is destroyed.

Cardinality specified as above.

2. 6. Generalization

Defines derivatance by inheritance. Derived (sub) Class2 is a specialization of (extends) the base (super) Class1.

Class2 is the super-class, where attributes and methods will be handed down to the derived Class1 - unless methods are specificly overridden with new methods using same name/argument specication but different implementation body.

Cardinality specified as above.

2. 7. Realization

Defines implementation of interface. Realization is the fullfillment of the interface contract specifying a set of methods that must be implemented by the derived class. In C++, an interface is a class containing nothing but pure virtual methods. Java supports them directly. (c.f.. "abstract class," which can contain method and field definitions in addition to the abstract declarations. An abbstract class cannot be directly instantiated - but only used for inheritance. Normal way to obtain a reference to this method would be by the factory design pattern).

Since interfaces contain no attributes, the "attributes" compartment is always empty.