Is an abstraction of reality or a representation of a real object or situation?

In Object Oriented Programming we are trying to model either real world entities or processes and represent them in software. There are compelling reasons why we model:

• A model is a simplification of reality. We model because we cannot comprehend the complexity of a system in its entirety.
• We model to visualize, specify, construct, and document the structure and behavior of a system's architecture.
• A model is a complete description of a system from a particular perspective.

Principles of Modeling

The model that we create is dependent on the problem that we are trying to solve and the entities in the scope of the problem.

• The choice of what models to create has a profound influence on how the problem is attacked and how a solution is shaped.
• Every model maybe expressed at different levels of precision.
• The best models are connected to reality.
• No single model is sufficient. Every non-trivial system is best approached through a small set of nearly independent models.

Basic Principles of Object Orientation

• Abstraction: the most important or essential aspects of something while ignoring the less important details. Abstraction is dependent on perspective - what is important in one context may not be in another. We model our problem domain using abstractions.
• Encapsulation: physical localization of features into a single blackbox abstraction that hides their implementation behind a public interface. "Information hiding" is a corollary concept that indicates data fields are hidden from the user but the functionalities as implemented through functions are exposed.
• Inheritance: organization of abstractions according to some order (e.g. complexity, responsibility, etc.).
• Polymorphism: substitute variables or objects of one type with variables or objects of another type. Polymorphism gives us the ability to switch components without loss of functionality.

Basic Concepts of Object Orientation

• Object
• Class
• Attribute
• Operation (Function)
• Polymorphism

What is an Object?

An Object represents an entity either physical (box), conceptual (chemical process), or software (list).

An Object is a concept, an abstraction, a thing with sharp boundaries and meaning for an application. It has

• Identity - a name
• State - determined by the values of its attributes
• Behavior - determined by how the object acts or reacts to requests (messages) from other objects

An Object is represented as a rectangle with a underlined name in UML.

What is a Class?

A Class is a description of a group of objects with common properties (attributes), behavior (operations), relationships, and semantics

A class is an abstraction. An object is an instance of a class.

Example of a Class

• Class: Course
• Properties: Name, Location, Days Offered, Credit Hours, Professor
• Behavior: Add Student, Delete Student, Get Course Roster, Determine If Full

A class is represented by a compartmentalized rectangle in UML. It has three sections - Name, Attributes, and Operations. You can show as many or as few of the Attributes and Operations in the diagram. Most of the times for the sake of clarity the Attribute and Operation lists are suppressed.

You start from real world objects - abstract out what you do not care and go through the process of classification of what you care. A Class is the result of this classification. Classes are then used as templates within a software system to create software objects.

The basis of the object-oriented approach is as good as possible a representation of something that exists in the real world first in a model and later in an IT system. However, this representation will never completely correspond to reality. Everything in the real world, whether it is a living being, an object, or an idea, is so complex and has so many aspects, that this complexity can never be completely represented:

Figure 4.21 A few aspects of Mr. Smith

To allow representation as a model it is necessary to focus on a few particular aspects and to leave out all others. The essential, meaning the interesting, aspects are emphasized and all other aspects are omitted. It is exactly this that is the art of modeling objects.

In order to model objects successfully we have to know for what purpose they are needed in the IT system. The object “Mr. Smith” will look different in a customer management system than in a medical information system or in a tax register (see Figure 4.21). Only when we know, at least approximately, the purpose of the IT system we can build functional objects.

In models, we always abstract from reality in a target-oriented manner. We restrict our consideration to the important aspects for the current purpose and omit everything else. Figure 4.22 shows this step of abstraction by the example of an airplane:

Figure 4.22 Modeling

When depicting the real world in abstract models, we differentiate between two steps. In the first step, we abstract from individual persons or things to objects. In the second step, we combine similar objects into classes. Figure 4.23 shows, with a few examples, how things of the real world are depicted first as objects and then as classes:

Figure 4.23 Object and Class formation

The direct illustration in a model of something that exists in the real world leads to an object. A 1:1 relationship exists between something from the real world and the object. The object represents exactly one particular exemplar from the real world. In a database an object corresponds, for instance, to an entry in a spreadsheet. The definition of objects is already a first step of abstraction, since only relevant features are modeled in the object. For example, in the object Mark, the person Mark is reduced to those aspects that are important for a passenger, for instance, title, first name, last name, and date of birth.

Write down a dozen objects from your personal work environment.

In the second step of abstraction, we combine similar objects into classes. Similar means:

• That the goal of the abstraction is similar
• That we are interested in similar characteristics
• That the objects have similar behavior

Most of the time the two steps of abstraction are combined, meaning that classes are formed directly. The step of object creation is not carried out explicitly.

Modeling is often made more difficult by the fact that something that only exists as a concept or idea, and not in the physical sense, has to be modeled. While in the past it was still possible to actually hold a stock certificate or a savings book in your hands, today, such things often exist only as information.

Try to group the objects that you wrote down into classes.

Dealing with classes becomes easier when you consider that the term class has two somewhat different meanings:

• On the one hand, the class is the pattern according to which objects are created.
• On the other hand, the class is the set of objects that have been created according to that class.

The class as a pattern dictates the characteristics and behavior of objects that are created from the class. In Figure 4.24, class is compared with a cookie cutter, which can be used to cut cookies (objects of the class) from dough:

Figure 4.24 Cookies, classes, and objectsFigure 4.25 Class as a pattern

The class as a set contains and knows all its objects. It can be pictured as a table in a database, which knows all its entries.

Usually, classes, in addition to attributes, contain methods, which specify the behavior of objects. However, in our approach to modeling IT systems we broadly abstain from using this possibility. The behavior of objects depends largely on their respective states. A “cancel flight” method of the class “flight”, for instance, has to perform something different with a flight object in the condition “in execution” than with a flight object in the condition “planned”.

According to our experience, such rules can generally be modeled much more easily in the statechart diagram in the behavioral view than they can be modeled with operations. Only in the later project stages of design and implementation is the behavior of classes converted into methods according to the programming language utilized.

In the Hanseatic merchant’s trading office a class corresponds to a book, for example a customer index, and the clerk who is responsible for the book. The book can only be accessed through the clerk. Individual customer entries correspond to the objects. Entries in the different books are connected by cross-references.

What is an abstraction of reality?

What is an abstract representation of reality?

What is an abstract representation of objects?

Is an abstraction or representation of a real system idea or object?