Back Home Up Next


2.1 What are Concepts?
2.2 Sharing of Concepts
2.3 Overlapping Concepts
2.4 Derived Concepts
2.5 Concepts Hierarchies
2.6 Recognizing Key Concepts
2.7 The Environment of a System
2.8 Guidelines
2.9 Summary
2.10 References


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.


2.1 What are Concepts?

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.


2.2 Sharing of Concepts

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.


2.3 Overlapping Concepts

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.


2.4 Derived Concepts

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:

Triangle: a triangle is a polygon with three sides.

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:

Triangle: a triangle is a closed figure bounded by three lines.

Now our list of concepts may include closed figure and line as new concepts.

Another example of a concept definition is:

Customer: a customer is a person or organization that purchases a commodity or service.

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.


2.5 Concepts Hierarchies

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.


|                               |
Open Figure                   Closed Figure
|                               |
          Line                     ----------------------
                                   |                    |
                                   Polygon              Ellipse
                                   |                    |
                         ------------------------       Circle
            |           |          |
                Triangle  Quadrangle  Pentagon      

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.


                 |                               |
             Land Vehicle                   Water Vehicle
                 |                               |
       ----------------------         ----------------------
       |                    |         |                    |
  ----------               -------------                 ------ 
  Automobile                 Amphibious                   Boat
                   Figure 2-2: A concept may have multiple parents


2.1 Extend Figure 2-2 with the concepts of balloon, airplane, and seaplane.

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.


2.6 Recognizing Key Concepts

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:

"The requirement is for a software system that will manipulate the hardware for traffic control located at an intersection. The hardware includes a set of sensors, the traffic lights, and the control box. The software reads the state of sensors, determines the new state for the intersection, and signals the lights to change. In addition, the system is to have capabilities such as a test option which cycles the lights through the set of configurations. The system can also be set to a default state which might be flashing yellow in one direction and red in the other. The sensor indicates the presence (or absence) of a vehicle in a particular lane. There are several kinds of sensors, each of which works differently internally. All the sensors however are interrupt-driven and a bit is set whenever the sensor is tripped. After the decision to change the state of the intersection, every sensor is reset. This particular intersection uses two kinds of traffic lights. One is the usual three-color light which is used for the go-straight lanes. The other light is a four-position light: red, yellow, green, and turn arrow. Each light has a current state, a set of valid next states, and a default state. The controller physically contains the switches for the lights, the data stores for the sensors, and a clock for timing the state of the poll/decision cycle. The controller software reads the clock, polls the sensors, determines the next state, and sends the signals to change the lights."

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.


2.7 The Environment of a System

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).

                                           | ---  !      |
                                           | ---  !      |
                                         O |Sen-  !      | Traffic-
                                Traffic- O |sors  !      | Light
                                   Light O | ---- !      | O O O
-------------------------------------------             ----------------------------------------------
     <= Lane                                             ! Sensors !                   <= Lane 
 - - - - - - - - - - - - - - - - - - - - - -             - - - - - - - - - - - - - - - - - - - - - - -
    Lane =>                      ! Sensors !                                            Lane =>
--------------------------------------------             ---------------------------------------------
                                     O O O |      ! ---- | O               ----------- 
                                  Traffic- |      !Sen-  | O Traffic-      | Control |
                                   Light   |      !sors  | O  Light        |   Box   |
                                           |      ! ---- |                 -----------
                                           |      !      |
                 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.


2.8 Guidelines

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.


2.9 Summary

Step 1 of the conceptual modeling process is to make a list of key concepts which are essential to describe the problem domain.
Concepts are abstractions of reality. They include tangible things, but also abstract entities such as accidents, situations, or events.
Concepts may overlap. Overlapping concepts may represent different roles which might be essential for the problem domain.
Concepts are based on other concepts. Concept definitions may be used to discover derived concepts.
Concept hierarchies may be used to discover more general concepts in the problem domain.
Key concepts are often found in the operational environmentg steps. Make also a list of candidate concepts which could be used in following iterations to refine the model. of a system.
Make a list of key concepts as input for subsequent modelin


2.10 References

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.


Top of Page   Part 4: Domain Modeling   Chapter 2: Concepts


Home | Highlights of Elisa | Integrating Different Paradigms | Getting Started with Elisa | Demo's  | What is Domain Orientation | Bibliography | Copyright | News | Contact | Contents

Language Description:

Lexical Elements | Basic Data Types and Expressions | Definitions | Streams | Backtracking | Statements and Special Expressions | Arrays | Lists | Descriptors | Components | Collections | Generic Components | Terms | Categories | Types | Built-in Definitions | Higher-order Definitions | External Interfaces | Index 

Data Structures: Sequences | Examples involving Lists | Trees | Graphs | Searching State Spaces | Language Processing | Knowledge Representations
Domain Modeling:

Domain Modeling | Concepts | Domain Definitions | Domain Operations | Domain Implementations | Systems | Case study: an Order processing system | Case study: an Airport Support system | Domain Orientation versus Object Orientation

Design Patterns:

Introduction | Abstract Factory | Builder | Factory Method | Prototype | Singleton | Adapter | Bridge | Composite | Decorator | Facade | Flyweight | Proxy | Chain of Responsibility | Command | Interpreter | Iterator | Mediator | Memento | Observer | State | Strategy | Template Method | Visitor 


click tracking


Send me your comments


This page was last modified on 27-09-2012 16:47:30   

free hit counter