Mapping
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67
68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101
102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118
119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135
136 137 138 139 140 141 142 143 144 145 146
Class structures describe the structure of the objects representing concepts, abstractions,
and other items within a problem space. In other words, class structures provide
blueprints for building the data structures and scripting the behaviors of objects within
an object-oriented system. Class structures in the cognitive mapping domain would
describe a variety of objects spanning a range of granularity. Class structures describing
“fine-grained” objects serving as fundamental building blocks of a social causal mapping
system would represent an individual’s concepts and assertions of causality (i.e., nodes
and arcs, respectively). Those fundamental class structures must also describe methods
to create, store, link, dispose of, and otherwise process nodes and arcs. Higher-level
class structures would describe the building of “coarse-grained” objects from “finegrained”
fundamental objects (e.g., aggregating nodes and arcs into causal maps).
Methods associated with these higher-order objects would prescribe processes for
analyzing large numbers of maps, such as identifying equivocalities and feedback loops
within and between individual causal maps.
A thoughtful, coherent set of class structures can facilitate efficient software design and
coding in many ways. Perhaps the most useful way to do so is by designing the class
structures so that they integrate and cooperate with each other. This can be achieved
in object-oriented design through hierarchies of interrelated classes in which commonlyused
data and method structures are encoded in high-order “super-classes” that allow
related lower-order “sub-classes” to re-use, or inherit, those structures. This and other
applications of hierarchical classes structures will now be explored in the context of social
causal mapping.
Hierarchies of Classes in Object-Oriented Design
Class hierarchies are based on what’s commonly called an “is-a” relationship. Objects
exhibit an “is-a” relationship with their classes, just as someone’s pet dog “is-a” member
of the canine family. Likewise, two classes can also be linked through an “is-a”
relationship, just as a canine “is-a” type of mammal and a mammal “is-a” type of animal.
“Is-a” relationships are transitive, so it can be said that a particular dog “is-an” animal.
Hierarchies of sub-classes and super-classes facilitate the creation and encoding of
object-oriented software by allowing designers to conceptualize the given problem
space at various levels of abstraction. This approach is similar to—but not exactly like—
the common example of the taxonomies of animal species. For example, the generalized
notion of “mammal” arises from the abstraction of common characteristics of groups such
as lions, dogs, weasels, and humans: all are mobile, have seven vertebrae in their necks,
nurse their young, and have hair. In turn, the term “animal” is a more abstract concept
encompassing fish, birds, reptiles, mammals, and other mobile life forms. The abstract
notions of “mammal” and “animal” are useful because they help biologists construct
taxonomies that succinctly structure knowledge about related forms of life. A diagram
depicting a hierarchical, taxonomic structure of animal classifications is displayed in
Figure 3.
Object-oriented design extends the notion of taxonomy beyond the hierarchical positioning
of related groups and objects into an efficient approach to designing information
systems. This approach relies upon inheritance, in which the characteristics of higherlevel
classes are imparted to—or inherited by—their lower-level counterparts. Inheritance
is particularly helpful in object-oriented design. It promotes the re-use of design
structures, thus enhancing efficient program coding and consistency of design across
the software and information system. It also helps ensure that important general
structures and methods are not forgotten in the implementation of specialized subclasses.
Inheritance typically takes two steps. The first step involves grouping data structures
and methods that are common to a set of classes within one class (e.g., the super-class
CognitiveMap). Data structures and methods that are particular to one or more but not
all members of that group are relegated to unique sub-class structures (e.g., the subclasses
CausalMap, CategoricalMap, and AssociativeMap). The second step involves
identifying the relationships between a super-class and its sub-classes. This step is
typically accomplished with a software statement. The Java clause “class CausalMap
extends CognitiveMap” is an example of how a super-class/sub-class relationship could
be identified by a software statement.
Hierarchies of Classes for Social Causal Mapping
The similarities among the data structures and methods among causal, categorical, and
other cognitive maps suggest that these classes can be arranged in one or more
Dogs Cats Fin whales
Carnivores Cetaceans
Mammals
Dolphins
Animals
Birds
Waterfowl Raptors
Ducks Geese Hawks Eagles
Figure 3. Hierarchies of super-classes and sub-classes in the animal kingdom
hierarchies of sub-classes and super-classes. Three hierarchies are of immediate interest:
one concerns the maps themselves (i.e., a hierarchy of cognitive maps), while two
concern their constituent components (i.e., nodes and arcs).
A Hierarchy of Cognitive Maps for Social Causal
Mapping
The general notion of cognitive maps can be abstracted from causal, categorical, and
other similar types of representations. All are directed graphs composed of nodes and
arcs, and all exhibit functionalities (i.e., encoded in their methods) that can contribute to
the five OMIS functions conceptualized in Stein and Zwass (1995). It is these elements
and characteristics that are common to and drawn from causal, categorical, and other
related maps that are used to construct the super-class of cognitive maps (i.e., Class
CognitiveMap). A diagram of these hierarchical relationships is displayed in Figure 4.
Cognitive map sub-classes (e.g., CausalMap, CategoricalMap) would inherit data and
method structures delineated in Class CognitiveMap, but would also contain unique
characteristics as well. For example, the Class CausalMap would contain a method to sum
the “+” and “-” values in a chain of causal node-arc-node segments. Class CategoricalMap
would not need that function because categorical arcs do not exhibit “+ or “-” values.
Indeed, the differing natures of the nodes and arcs within the causal and categorical maps
suggest that separate class hierarchies are needed for nodes and arcs. These two
hierarchies are explored next.
Figure 4. Hierarchies of super-classes and sub-classes for social causal mapping
Cognitive Maps
Associative
Maps
Categorical
Maps
Causal
Maps
Workflow
Diagrams
Political
Maps
Synonymous
Terms
Content
Analysis
Hierarchies of Node and Arc Classes for Building