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
1..2, 10..*	one, two or ten and above but not three 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:

1) 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.