Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Concept Mapping
Concept mapping, which is the more formal elder brother of mind mapping, was invented in the 1960s by Joseph Novak at Cornell University.
In concept mapping, concepts are connected by linking words to form propositions.
- A concept is a thing (object) or happening (event) derived from your knowledge about the domain.
- Linking words specify relationships between concepts. They link concepts together to form propositions.
- Propositions are units of meaning. They are statements that affirm or deny something about the domain.
The concept map has a network structure, in which concepts are connected to other concepts. There is no "root" concept analogous to the "root" idea of mind mapping. However, you can highlight a particular concept as the "main" or "key" concept in the map to give the reader a logical place to start.
Concept maps are a useful "halfway house" between informal mind maps and more formal UML models, and a well-constructed concept map provides a very useful source of classes, attributes, operations, and relationships.
To analyze a concept map in this way, you need to look at the list of propositions and divide them into structural propositions that say something about the structure of the system, and look at behavioral propositions that say something about the behavior of the system.
Here is an example; consider the concept map shown in Figure 2. This example is for a simple burglar alarm system that we used as an example in UML 2 and the Unified Process [Arlow 2].
)
Figure 2 Example of concept mapping
What can you say about this concept map from an OOAD perspective? First, notice that there are propositions about the structure of the burglar alarm system. These structural propositions tend to be about things, about parts of the burglar alarm. The structural propositions are the following:
- Burglar alarm is operated by a control panel (this implies a whole-part relationship between burglar alarm and control panel)
- Burglar alarm has a siren
- Siren has an intruder sound
- Control panel comprises:
- Numeric keypad
- On/off indicator
- On button
- Off button
- Burglar alarm monitors zones (implying that the burglar alarm has access to the zones in some way)
- Zones contain sensors
- Sensors are of two type:s
- Intruder sensor
- Fire sensor
There are also many behavioral propositions, which are propositions about behaviors of the burglar alarm and its parts—they describe responsibilities of the system as a whole and of its parts. These propositions are the following:
- Burglar alarm monitors zones
- Numeric keypad accepts PIN
- Control panel does the following:
- Validates the PIN
- Accepts a new PIN (the preconditions for this aren’t mentioned on the concept diagram)
- PIN enables (assuming it is correct—what happens if it is not
correct?) the following:
- On button
- Off button
- On button
- Causes on/off indicator to display "on"
- Enables burglar alarm
- Off button
- Causes on/off indicator to display "off"
- Disables burglar alarm
- Intruder sensor
- Triggered by intruder
- Triggers siren intruder sound
- Fire sensor
- Is triggered by fire
- Triggers siren fire sound
- Overrides siren intruder sound
- Siren intruder sound sounds for 15 minutes
- Siren fire sound sounds for 30 minutes
The concept map captures lots of information about the system in a clear visual way, and it can very easily be converted to a series of structural and behavioral propositions about the system. It’s now straightforward to generate a class diagram and other UML artifacts from this concept map.
Figure 3 shows a first-cut class diagram derived from the concept map. If anything, this class diagram is too fine-grained for an analysis model. In particular, notice all of the one-to-one compositions around the ControlPanel class.
)
Figure 3 First-cut class diagram derived from the concept map
We can refactor the first-cut class diagram to get the diagram shown in Figure 4. This has removed some of the detail by consolidating the separate ControlPanel and KeyPad classes into the BurglarAlarm class. This consolidation is strongly indicated by the one-to-one composition relationships between those classes. We can always reintroduce those classes in design if it proves necessary.
)
Figure 4 Diagram after refactoring
The concept map also indicates important questions about the system. For example, we need some way of changing the PIN, but the details of that event are not explicitly captured in the concept map. This indicates that we need to do more analysis on this feature.