he relationships between two classes can be of the following three types:

• Association

• Aggregation

• Dependency

An Association is a bi-directional connection between classes and is represented by a solid line.

An Aggregation is the relationship between the whole and its parts. An aggregation is represented as a line connecting the related classes with a diamond next to the class representing the whole.

Composition is a stranger form of an aggeration. The whole is responsible for the creation and distruction of its parts. Composition is represented as a line connecting the related classes with a filled in diamond next to the class representing the whole. With Composition the part may belong to only one whole.

A Dependency is a relationship where the client does not have semantic knowledge of the supplier. A dependency is shown as a dashed line pointing from the client to the supplier.

An Inheritance. Inheritance is represented by a line ending on a triangle on the parent class.

A class is drawn as a rectangle with three compartments: the first compartment shows the name of the class, the second compartment shows the attributes of the class and the third compartment shows the methods of the class

When creating and working with classes, a class should have only one purpose. An object that performs multipule tasks is less reuseable than an object that is specialized in just one task. Coupling between objects which have multipule task is increased, more task means addition information the oject needs to know about the other objects. Less is better!

Example:

This class (P) Customer’ was selected at ramdom form the Handheld Rose model, simuair classes exsist thoughout the model. Only five (5) of the class operations are list to make a point.

The name of this class is (P) Customer, therefore one would rightfully belive that its main goal is to focus on the customer (i.e. Cutomer Object).

It should, therefore only have methods respecting the customer’s domain (i.e. customer information). Yet, there are methods which should be in the Oder object (GetNumTodaysOrder). There are methods which should be in the Deals object (CreateDealList), a method which should be in the Contacts object, and methods which should be in a Message or Communication object.

Yes, the information from the these methods are needed for the customer, but they are not customer information. What is ment by this statement is; Order is order information, and creating a Deal List has to do with the Deals object. The same is true for Contact and Messages respectively.

A better way to build classes would be to only include operations for which the class is responsible (assign responibilties to classes). Ask the responsible object for the information or result you are seeking.

This will reduce coupling between objects and improve cohesion within the object. Any attempt remodel the current ‘Handheld model’ would result in a completely different model, which would include the possiblity of additional classes and associations which may not currently exsist.

In Object Oriented Programming all data member of a class should be privte or at lest protected. Consider the following:

A routine is a generic program unit, that is, a function, procedure, subroutine, iterator, block, or main program. The quality of routines appearing in a program has a tremendous impact on the reliability and readability of that program.

Routines exhibit the following kinds of cohesion (listed from good to bad):

• Functional or logical cohesion exists if the routine accomplishes exactly one (simple) task.

• Sequential or pipelined cohesion exists when a routine does several sequential operations that must be performed in a certain order with the data from one operation being fed to the next .

• Global or communicational cohesion exists when a routine performs a set of operations that make use of a common set of data, but are otherwise unrelated.

• Temporal cohesion exists when a routine performs a set of operations that need to be done at the same time (though not necessarily in the same order). A typical initialization routine is an example.

• Procedural cohesion exists when a routine performs a sequence of operations in a specific order, but the only thing that binds them together is the order in which they must be done. Unlike sequential cohesion, the operations do not share data.

• State cohesion occurs when several different (unrelated) operations appear in the same module and a state variable (e.g., a parameter) selects the operation to execute. Typically such routines contain a case (switch) or if..elseif..elseif... statement.

• No cohesion exists if the operations in a routine have no apparent relationship with one another.

The first three forms of cohesion above are generally acceptable in a program. The fourth (temporal) is probably okay, but you should rarely use it. The last three forms should almost never appear in a program. For some reasonable examples of routine cohesion, you should consult "Code Complete".

Coupling refers to the way that two routines communicate with one another. There are several criteria that define the level of coupling between two routines:

• Cardinality- the number of objects communicated between two routines. The fewer objects the better (i.e., fewer parameters).

• Intimacy- how "private" is the communication? Parameter lists are the most private form; private data fields in a class or object are next level; public data fields in a class or object are next, global variables are even less intimate, and passing data in a file or database is the least intimate connection. Well-written routines exhibit a high degree of intimacy.

• Visibility- this is somewhat related to intimacy above. This refers to how visible the data is to the entire system that you pass between two routines. For example, passing data in a parameter list is direct and very visible (you always see the data the caller is passing in the call to the routine); passing data in global variables makes the transfer less visible (you could have set up the global variable long before the call to the routine). Another example is passing simple (scalar) variables rather than loading up a bunch of values into a structure/record and passing that structure/record to the callee.

• Flexibility- This refers to how easy it is to make the connection between two routines that may not have been originally intended to call one another. For example, suppose you pass a structure containing three fields into a function. If you want to call that function but you only have three data objects, not the structure, you would have to create a dummy structure, copy the three values into the field of that structure, and then call the routine. On the other hand, had you simply passed the three values as separate parameters, you could still pass in structures (by specifying each field) as well as call the routine with separate values.

A function is loosely coupled if it exhibits low cardinality, high intimacy, high visibility, and high flexibility. Often, these features are in conflict with one another (e.g., increasing the flexibility by breaking out the fields from a structures [a good thing] will also increase the cardinality [a bad thing]). It is the traditional goal of any engineer to choose the appropriate compromises for each individual circumstance; therefore, you will need to carefully balance each of the four attributes above.

A program that uses loose coupling generally contains fewer errors per thousands of lines of code). Furthermore, routines that exhibit loose coupling are easier to reuse (both in the current and future projects). For more information on coupling, see the appropriate chapter in "Code Complete".