The first step of conceptual modeling is to make a list of concepts which are relevant for the problem area. Understanding the problem area first requires an understanding of what the concepts of the problem area are. This chapter focuses on the nature of concepts and how to select them.
We are using concepts as mental tools to understand the world. Because we live in a complex world we need ways to categorize the things we perceive. As a child we all became familiar with things in the real world such as balls, tables, chairs. We discovered that a ball is different from a table and that we could recognize balls and tables by their shapes and other characteristics. We learned that all balls have a number of common characteristics which distinguish them from tables and from other things. Gradually the concept of a ball, of a table, and of many other things took form in our mind. When we saw a new object, we compared in our mind its shape and other characteristics with the concepts we already knew and gave it a name accordingly. Later on, at school, we learned about abstract things, such a triangles, and circles. We discovered that they also are belonging to different kinds of concepts.
Concepts result from our ability to abstract. They are formed in our minds as abstract or generic ideas often generalized from particular examples. Once these concepts are formed, we can further organize the world mentally by understanding the relationships between different concepts.
We have classified things in our world in many ways. We discovered that objects of the same type have a common set of properties. For example, balls are round, and have a certain size and weight, while boxes have a rectangular shape with a length, a width, and height. And we called round objects 'balls' and rectangular objects 'boxes'. We classified the objects in different classes.
If things have a common set of characteristics, we say that they are of the same type or are belonging to the same class. A class is a conception of the mind. Classes cannot be perceived in the real world; only examples of things belonging to a certain class are visible. For instance, trees are visible, not the class of all trees.
We also discovered things that are definite not objects. For example, a storm is not considered to be an object. The same is true for dreams, accidents, situations, or events. But we have formed in our minds mental images of storms, dreams, accidents, and we are using those concepts frequently in daily life. We have also arranged storms, accidents, situations, and events in different classes, because of their distinct characteristics.
By convention, privately held ideas or notions are called conceptions. When a conception is shared by others, it becomes a concept. To arrive at agreed concepts, we must communicate with others and share our individually held conceptions. Shared concepts are representing pools of common knowledge. For example, your conception of what a tree is might include brushwood. However, that conception may or may not be shared by the forest-law and the forest-keepers.
The same situation may occur if a system should be modeled and the main concepts are identified. If you, as a modeler, has a conception of a customer, which is different from what the users of the system think a customer is, then there is a problem. The only way to solve such a problem is to come to a shared understanding before the system is built.
We use classification to order concepts. However, it is often not easy to define clear-cut concepts, because concepts may overlap. If we define a class of red flowers and also a class of roses, then these classes have common elements: the red roses.
The same problem occurs if an employee of a company is also a customer. The concept of employee and customer have overlapping elements. Often there is overlap if an element of a class can play different roles. For example, the same person can be a father, a doctor, and a patient.
Overlapping concepts are quite common in daily life. In our modeling activities we should take care of overlapping concepts if they are relevant for the problem domain. For example, if the same person can be a father, a doctor, and a patient, then all those roles are probably irrelevant for a transportation system, but they may be important for a hospital information system. That means that a conceptual model for a hospital information system will recognize each role as a different concept and that those concepts may have common members.
If we try to define a concept, we often will use other concepts in the description. As an example, the concept of a triangle may be described as:
In this description we introduced two other concepts: polygon, and side. We may conclude that both concepts may be important for our conceptual model. And we decided to include them in the list of concepts which should be used for modeling.
However, in this stage of modeling it is often too early to decide if derived concepts should be added to the concepts list. If we had used another definition for triangle, for instance, we might have ended up with another set of derived concepts. For example, we may also define a triangle as:
Now our list of concepts may include closed figure and line as new concepts.
Another example of a concept definition is:
In this description we introduced four other concepts: person, organization, commodity, and service. It depends on the problem area if we need to add them to the list of concepts. For example, we may decide that persons and organizations are important concepts in our problem domain, but that commodities and services are not. Often it is safe to include a derived concept in the concepts list if it has a meaning in the problem space.
Many concept definitions and descriptions can be found in problem descriptions, system requirement specifications, encyclopedia, and dictionaries.
Concepts are often defined in terms of more general concepts. We saw already an example of that: a triangle is a polygon with three sides. A polygon is a higher abstraction because it also encompasses quadrangles, pentagons, and so on. But there is also a higher abstraction for a polygon, as shown in Figure 2-1.
Figure 2-1: An example of a hierarchy of concepts
The classification of concepts in a hierarchy is based upon generalization and specialization. Generalization is used to find general concepts based upon existing concepts which have a number of characteristics in common. Specialization is the opposite of generalization: it tries to define specific concepts based on more general concepts.
Concept hierarchies are not limited to tree structures. In tree structures each node, except for the root, has only one parent node. But concepts may be based on more than one generalized concept. So, a concept may have multiple parent concepts. For example, in Figure 2-2, an amphibious vehicle has the characteristics of a land vehicle as well as the characteristics of a water vehicle.
Figure 2-2: A concept may have multiple parents
Concept hierarchies are powerful tools to display the relationships between different kinds of concepts. They can also used for the definition of new concepts. Concepts may be often defined in terms of more general concepts albeit with a number of restrictions. We saw already some examples, such as: a triangle is a polygon with three sides.
Concepts must be relevant for the problem space. It will be clear that we are not interested in concepts which have no connections with the problem we try to solve. But even in the problem space itself there are many related concepts. Fortunately, not all these concepts are needed for modeling a system. Often it will suffice to list only the main concepts which are playing a key role in the problem domain. However, the main question remains: What are key concepts?
Let us analyze a requirements specification as given by Korson and McGregor (1990) for a traffic intersection control system:
In this specification are many concepts are used: software, hardware, system, sensors, traffic lights, control box, states, signals, cycles, lanes, configurations, bits, switches, clock, and so on. They all are related to the problem of traffic intersection control. The question is: how are we selecting the main concepts from this list?
In such a situation it often helps to draw a diagram which shows the system in its environment.
The first step in modeling a system is to draw a picture of the environment of the system, showing concepts in the real world which are relevant in the context of the system. The system itself will be considered as a black box. Because systems are always parts of larger systems, a system may represent a computer-based information system, but it may also represent a organization or any other kind of system.
Let us start with a diagram representing the traffic control system in its environment (see Figure 2-3).
Figure 2-3: Example of the Environment of a Traffic Control System
Although the diagram is simple, it gives us the necessary information. It tells us what the key concepts are of the system to model: traffic lights, lanes, and sensors. All other concepts are either internal to the system or are not relevant in this stage.
It is often worthwhile to draw a diagram of the system in its environment in a very early stage of the modeling activities, because it may give you a lot of information about the relevant real-world concepts which should be represented in the model.
There are some rules to follow when drawing such a diagram. First of all, the diagram should only show the system in its environment. No internal operations of the system should be disclosed in this diagram; only the sources of inputs and the destinations of the outputs are important at this stage.
Secondly, the diagram should show the relevant real-world concepts, not the corresponding information concepts.
And a third rule is to keep the diagram simple and to show only the most important categories of entities. For example, a traffic control system may support many different kinds of sensors. In our diagram we all collected them under the name of sensor. The differences will be dealt with later.
The first step of conceptual modeling is to make a list of key concepts which are relevant for the problem domain. Often the best way to start is to draw a diagram of the environment of the system. No internal concepts or operations of the system are shown, only the most important external entities which are relevant for the operation of the system. These are representing the key concepts.
Make two lists of concepts. Use the first one for the key concepts and use the second one for possible candidates. About the key concepts you are sure they should be supported by the system. About candidate concepts, you are not sure. Candidate concepts may be overlapping concepts, derived concepts, concepts higher in the concepts hierarchy, and so on.
Conceptual modeling is an iterative process. For the first iteration only the key concepts are used in the following modeling steps. Later on, also candidate concepts may be used to refine the model.
Booch (1991) describes the difficulty of classification. Martin and Odell (1992) are discussing the roles concepts are playing in object-oriented analysis.
An article of Korson and McGregor(1990) provides an overview of object-oriented concepts used in analysis, design, and implementation. They use as an example a requirements specification for a traffic intersection control system.
This page was last modified on 27-09-2012 16:47:30