CLAVELAND

RELATIONSHIP BETWEEN CLASSES AND OBJECTS

Classes and objects are separate yet intimate related concepts.Specifically , every object is the instance of some class ,and every class has zero or more instance .For particularly all applications classes are static : therefore their existence ,semantics ,and relationship are fixed prior to the execution of a program.Similarly ,the class of most objects is static ,meaning that once an objects is created ,its class is fixed. In sharp contrast, however, objects are typically created and destroyed at a furious rate during the life time of an application.

For example, consider the classes and objects in the implementation of air traffics control, systems .Some of the more important abstractions include planes ,flight plans ,runways, and air space. By their very definition ,the meaning of these class of objects are relatively static, or otherwise one could not build an application that embodied knowledge of such commonsense facts as that planes can take off, and then land ,and that 2 planes should not occupy the same space at the same time .Conversely ,the instance of these classes are dynamic. At a fairly slow rate, new runways are built, and old ones are filled away. With great frequency, new planes enter a particular air space, and old ones leave.

THE ROLE OF CLASSES AND OBJECTS IN ANALYSIS AND DESIGN

During analysis and the early stages of design, the developer has two primary tasks:

• Identify the classes and objects that from the vocabulary of the problem domain
• Invent the structures where by sets of objects work together to provide the behaviors that satisfy the requirements of the problem.

Collectively, we call such classes and objects the key abstraction of the problem, we call these cooperative structures the mechanisms of the abstractions.

During these phases of development, the focus of the developer must be upon the outside view of these key abstractions and mechanisms. This view represents the logical frame work of the system, and therefore encompasses the class structure and objects structure of the systems .In the later stages of design and then moving into implementation, the tasks of the developer changes .The focus is on the inside view of these key abstractions and mechanisms, involving their physical representation .We may express these design decisions as part of the systems module architecture and process architecture.