CS302: Software Engineering

Process and Data Methodologies as Flip Sides of the Same Paradigm

Object orientation is based on the notion of objects which encapsulate both data and processes on that data. An object is an entity from the real world whose processes and attributes (that is, the data) are modeled in a computerized application. 

Processes are variously called functions, actions, services, programs, methods, properties, or modules; these terms may or may not have the same meaning to the people using them. For that reason, we stick to the term process to mean the transformational program language code that acts on its object data. 

An abstract data type (ADT) is the name used in some languages (e.g., C) for the new, user-defined data type that encapsulates definitions of object data plus legal processes for that data. In this text, we use the terms encapsulated object, object, and abstract data type interchangeably. 

The major analysis activities focus on defining objects, classes, and processes. Class/objects are the lowest level of logical design entities. Class/objects define a set of items which share the same attributes and processes, and manage the instances of the collection. The class defines the attributes and processes; the objects are the instances of the class definition. 

There are different types of class-object relationships. First, classes can occur without having any real data associated with them. Classes whose instances are other classes are called meta-classes. For instance, we might define a class Customer with subclasses for CashCustomer and CreditCustomer. The class is a meta-class; the subclasses are class/ objects which manage the data of Customer. 

Classes can be composed of class/objects to describe a composition relationship of whole and part. A whole class defines the composed object type. The part class defines all the components of the whole class. For instance, a car, as a whole class, contains parts that include motor, wheels, doors, seats, and so on. 

Classes can also be defined to allow specialized versions of an item. The meta-class is called a generalization class, or gen class for short. The subclasses are called specialization, or spec, classes. A generalization class defines a group of similar objects. For instance, vehicle is a generalization on car. The specialization class is a subclass that reflects an is-a relationship, defining a more detailed description of the gen class. For instance, a car, truck, or tank are all specializations of the general class vehicle. These could be further specialized themselves. For instance, car could have specializations by type car: full-size, mid-size, or economy.

Each type of class and its subclasses form a hierarchic, lattice-like arrangement of relationships. Through the relationships, the lower-level classes inherit the data and processes of the related higher-level classes. Thus, if we were to refer to an economyCar object, we would have information and processing for vehicles, cars, and economy cars all available.

Messages are the only legal means of communications between encapsulated objects. Messages are clear in their intention but not clear in their implementation, which is completely determined by the language (see message types in Figure 11-4). For instance, at the moment Ada does not implement message communication. In this text, a message is the unit of communication between two objects. Messages contain an addressee (that is, the object providing the process, also called a service object), and some identification of the requested process.

A major difference between object orientation and other methodologies is the shifting of responsibility for defining the data type of legal processes from supplier (or called) objects to client (or calling) objects. This shift, along with the notions of inheritance and dynamic binding, support the use of polymorphism, which is the ability to have the same process take different forms when associated with different objects. Dynamic binding is a language property that selects actual modules to execute during application operation. The concept is completely described in Chapter 12.

A supplier object is one that performs a requested process. A client object is one that requests a process from a supplier. For instance, I might need to have a date translated from month-day-year format to year-month-day format. As a client object, I request the translation of the supplier object and pass it the date to translate. If the language supports polymorphism, I also pass the data type of the date to be translated.

Example of Message Types

An example of polymorphism is, for instance, a process to perform comparison of two items to identify the 'larger' of the two. One object might be alphabetic, requiring a logical comparison; another object might be decimal numeric, requiring a numerical comparison; a third object might be an array, requiring numerical array comparisons. This polymorphic object has three implementations of its process to compare and determine the larger of two items. The client object requests a specific comparison process, here either alpha, numeric, or array.

To summarize the terms, objects are encapsulations of data and processes that have both public and private parts. Objects can communicate via messages which differ by language. Objects are arranged into classes of similar objects, and can belong to more than one class. By the property of inheritance, an object exhibits the attributes and provides the services of the classes of which it is a part. Polymorphism is a desirable property of objects but requires a client-server view of objects along with dynamic binding capabilities.

Source: Sue Conger, https://resources.saylor.org/CS/CS302/OER/The_New_Software_Engineering.pdf
This work is licensed under a Creative Commons Attribution 3.0 License..