Object Oriented Analysis

A short outline of Object Oriented Analysis (OOA) will be given here, to help the reader to understand the basic principles of the subject. The basic terms and principles necessary for understanding of program structure, used later in this paper, will be mentioned and explained. Object Oriented Analysis is based on the uniform application of principles for managing complexity (see Ref. [1]).

-

Abstraction (Procedural and data abstraction): The principle of ignoring those aspects of a subject that are not relevant to the current purpose in order to concentrate more on those that are relevant.

-

Procedural abstraction: The principle that any operation that achieves a well defined effect can be treated by its users as a single entity, despite the fact that the operation may be actually achieved by some sequence of low level operations. Procedural abstraction is widely supported by existing programming languages; procedures and functions are examples of procedural abstraction.

-

Data abstraction: The principle of defining a new data type in terms of the operations that apply to an object of that type, with the constraint that the values of such an object can be modified and observed only by the use of the operations. When applying data abstraction, an analyst must define attributes and services that exclusively manipulate these attributes. The only way, to get an attribute is via these services.

-

Inheritance: The mechanism for expressing similarity between data types, making common attributes and services explicit within a class hierarchy. Inheritance allows an analyst to define common attributes and services only once, as well as to specialize and extend those attributes and services into specific derived classes. It expresses generalization specialization between data types.

-

Association: Expresses the relationship, the state of being associated.

-

Communication with messages: Models the processing dependency. It represents the need for services necessary to fulfill object responsibility.

In an overall approach, OOA consists of five major activities: finding classes and objects, identifying structures, identifying subjects, defining attributes, and defining services. In order to present the general structure of a developed program, a graphical form will be used. Particularly, the Coad-Yourdon methodology will be used (see Ref. [1]). It introduces the following basic elements and mutual relations between them (see Fig. 1.):

• An Object is an abstraction of something in a problem domain, reflecting the capabilities of a system to keep information about it, interact with it, or both. It is also an encapsulation of attribute values and their exclusive services. A Synonym for object is an instance.
• Class: A description of one or more objects with a uniform set of attributes and services, including a description of how to create a new object in a class.
• Class & object: A term meaning class and the objects in that class.
• Attributes describe the values (state) of the object, to be exclusively manipulated by the services of that object. The attributes and exclusive services on those attributes are assumed as an intrinsic whole. If another part of a system (another object) needs to access or otherwise manipulate the values in an object, it must do so by specifying a message connection corresponding to service defined for that object.
• Services: The central issue in defining services is to define required behavior and necessary communication.
• Generalization specialization structure may be viewed as a layout for distinguishing between classes. Less formally, a Genspec structure can be thought to be an expression for ``is a'' or ``is a kind of'' relation. Within a Genspec structure inheritance applies. An example is the generalization class Vehicle and specialization class Truck vehicle. Genspec structure is represented by generalization class and by specialization class with a line drawn between them. A semi-circle mark distinguishes classes as forming Genspec structure. The notation is directional -- it uses a line drawn outward from semi-circle midpoint to point to the generalization (see Fig. 1.).
• Whole part structure groups together class&objects based upon whole-part meaning. This structure is represented by a whole object and by a part object, with a line drawn between them. A triangle mark distinguishes the object as forming the whole part structure. The notation is again directional. Each end of whole part structure line is marked with amount or range, indicating the number of parts that the whole may have and vice versa, at any given moment in time. The alternative modeling is to use an instance connection. It is weaker in meaning, but it still captures the mapping (see Fig. 1.).
• Attributes depict the object state. Instance connections add to this information, which required mappings are needed by an object to fulfill its responsibilities. Instance connections model association. A connection is represented by a line drawn between objects. Each object can again have an amount or range marks on each of its instance connections, reflecting constraints with other objects.
• A message connection is a mapping of one object to another (or occasionally to a class, to create a new object), in which a sender sends a message to a receiver, to get some processing done. The needed processing is named in the sender's service specification, and is defined in the receiver's service specification. The benefit of such a discipline is that it creates a very narrow interface between the strong encapsulation and exclusive services on those data. In effect, a message connection combines event-response and data flow perspectives. Each message represents values sent within the context of particular service need, and a response received as result.