Metaphors from the real life are important inspiration when we program the computer. It is limiting - and in fact counterproductive - to focus only on the technical computer concepts (bits, bytes, CPUs, memory words, USB ports, etc). According to my favorite dictionary (the American Heritage Dictionary of the English Language) a metaphor is

"a figure of speech in which a word or phrase that ordinarily designates one thing is used to designate another, thus making an implicit comparison."

Many familiar programming concepts are not from the technical world of computers. Quite a few, such as int, float, and double come directly from mathematical counterparts. Messages and message passing, which we discussed in Section 2.1, are widely known from our everyday life. Even before email was invented, people communicated by means of messages (Morse codes, telegrams, postal mail letters).

It turns out that the ideas of classes and objects are - in part - inspired from the theory of concept and phenomena. We will unveil this in the following sections. Be warned that our coverage is brief and dense. It may very well be the case that it takes time for you to digest some of the ideas and concept that we are going to present.

3.1 Phenomena and Concepts 3.3 Aggregation and Decomposition 3.2 Classification and exemplification 3.4 Generalization and Specialization

 

3.1.  Phenomena and Concepts
Contents   Up Previous Next   Slide Annotated slide Aggregated slides    Subject index Program index Exercise index 

The definitions of phenomenon and concept are taken from the PhD thesis of Jørgen Lindskov Knudsen and Kristine Stougaard Thomsen, Aarhus University [jlk-kst]. This thesis is also the source behind Section 3.2 - Section 3.4.

The characteristic aspects of a concept are the following:

The concept name The intension: The collection of properties that characterize the phenomena in the extension of the concept The extension: The collection of phenomena that is covered by the concept

The name of the concept is also called the designation. The designation may cover a number of different names, under which the concept is known.

The word intension is used in the less well-known meaning (from logic) "the sum of the attributes contained in a term" (see for instance the American Heritage Dictionary of the English Language).

The word extension is used in the meaning (again from logic): "The class of objects designated by a specific term or concept" (according the same dictionary). Be careful not to confuse this meaning of extension with the more common meaning of the word, used for instance in Chapter 26 for extension of classes.

Concepts can be viewed in two different ways: The Aristotelian and the fuzzy way.

Using the Aristotelian view, the properties in the intension are divided into defining properties and characteristic properties. Each phenomenon of a concept must possess the defining properties. It is assumed that it is objectively determinable if a given phenomenon belongs to an Aristotelian concept.

Using the fuzzy view, the properties in the intension are only examples of possible properties. In addition to the example properties, the intension is also characterized by a set of prototypical phenomena. It is not objectively determinable if a given phenomenon belongs to a fuzzy concept.

We will primarily make use of the Aristotelian view on concepts. The relative sharp borderline between different concepts is attractive when we use concepts as the basis for the classes that we program in an object-oriented programming language. Many such classes represent real-life concepts, simply because many of our programs administrate things from the real world. It is, however, also common to make use of imaginary concepts, which have no real-life counterparts (such, as for instance, a hashtable).

3.2.  Classification and exemplification
Contents   Up Previous Next   Slide Annotated slide Aggregated slides    Subject index Program index Exercise index 

Classification and exemplification describe a relation between concepts and phenomena.

Classification forms a concept from a set of phenomena. The intension of the concept is the (defining) properties that are shared by the set of phenomena (according to the Aristotelian view).

Exemplification is the inverse of classification. Thus, the exemplification of a concept is a subset of the extension of the concept.

Figure 3.1    The relationships between concepts and phenomena. Given a concept we can identify the examples of phenomena in the extension of the concept. Given such an example, we can (the other way around) find the concept that classifies the sample phenomenon.

3.3.  Aggregation and Decomposition
Contents   Up Previous Next   Slide Annotated slide Aggregated slides    Subject index Program index Exercise index 

In this and the following section we will see ways to form new concepts from existing concepts. First, we look at concepts related to 'parts' and 'wholes'.

The concept of a house is an aggregation of (for instance) of the concepts wall, window, door, and roof. The latter are the decomposition of the house concept.

The intension of the aggregated concept corresponds to the intensions of the part concepts. But, in some cases, the whole is more than the sum of its parts. Thus, the aggregated concept may have additional properties as well.

Figure 3.2    An illustration of aggregation and decomposition. Notice that the relations between wholes and parts are in between concepts. Thus, aggregation and decomposition show how to form new concepts from existing concepts.

In Figure 3.3 we show an example, namely the aggregation of a bike. Notice that we do not address the number of parts of the aggregated concept (no cardinalities). Following the tradition of UML notation, we use a diamond shape next to the aggregated concept. Notice, however, that it is not our intention to use exact UML notation in this material. We will primarily be concerned with programming notation, as defined (precisely) by a programming language.

Figure 3.3    An aggregation of a Bike in terms of Frame, Wheel, Brake, etc. This illustration does not capture the number of involved parts. Thus, the diagram does not capture the number of spokes per wheel, and the number of wheels per bike. The diamond shape is UML notation for aggregation.

3.4.  Generalization and Specialization
Contents   Up Previous Next   Slide Annotated slide Aggregated slides    Subject index Program index Exercise index 

Generalization and specialization are seen as ways to form a new concept from an existing concept. The extension of a specialization S is a subset of the extension of the generalization G.

It is more difficult to capture specialization and generalization in terms of the intensions.

The concepts of Encyclopedia, Bible, and Dictionary are all specializations of the Book concept. Encyclopedia, Bibles and Dictionaries are all subsets of Books. It may be the case that the set of encyclopedia and the set of dictionaries are overlapping.

Figure 3.4    An illustration of generalization and specialization.

Below, in Figure 3.5 we show a generalization/specialization hierarchy of transportation concepts. Each parent in the tree is a generalization of its sons.

Figure 3.5    A generalization/specialization hierarchy of 'Means of Transport'. All the concepts in this diagram are specialized means of transport. Notice that all the nodes in the specialization trees are concepts - not individual phenomena.

The ideas of generalization and specialization among concepts are directly reflected in generalization and specialization among classes (see Chapter 25) as supported by inheritance in object-oriented programming languages.