Encapsulation

К оглавлению
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 
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 

The second element of object-oriented modeling, encapsulation, refers to “the process

of compartmentalizing the elements of an abstraction that constitute its structure and

behavior” (Booch, 1994). The notion of “compartmentalization” means that only those

details that are necessary to interact with the “compartment” are visible to outside

entities. Non-essential details are hidden from view. In this way, encapsulation not only

facilitates representational conciseness, transparency, and efficiency, it also enhances

data integrity within the program because objects can interact only according to strictly

enforced rules and interfaces, and cannot access variables and values that are internal

to (i.e., encapsulated within) another object. In addition, encapsulation is not bound to

any particular sort of processing theory. Unlike relational databases that are limited to

set-theoretic algorithms, object-oriented programs are free to incorporate a variety of

algorithms that correspond to the processing requirements of causal mapping. One set

of algorithms that are particularly important for cognitive map analysis is graph-theoretic

algorithms. Encapsulating these algorithms within an object supports many processes

relying upon the traversal of node-arc-node segments, a process that is exceedingly

difficult—if not impossible—with set-theoretic algorithms.

Modularization

The third element of object-oriented modeling is modularization. Modules serve as “the

physical containers” in which the abstractions and encapsulated compartments are

stored (Booch, 1994). This concept directly impacts designers and implementers of ISbased

social causal mapping systems because it gives them a useful means for partitioning

the data and information into an orderly, integrated fashion. This element is

particularly important to causal mapping, because in the past causal maps of individuals

and groups have been stored in separate physical files that were difficult to integrate.

These physical limitations have created significant barriers to understanding social

causal cognition over large numbers of individuals and long time frames. The design and

implementation of compatible modules can overcome these past barriers, thus facilitating

research in social causal cognition.

Hierarchy

The fourth element is hierarchy, “the ranking or ordering of abstractions” (Booch, 1994).

Hierarchies of abstractions—whether they concern structure, behavior, or both—

facilitate transparency and conciseness by allowing the user or designer to focus on one

level of abstraction at a time. For example, all cognitive maps are directed graphs made

from nodes and arcs. A hierarchy of abstractions permits the designer to focus on one

of many levels of the representation problem (e.g., designing representations for nodes

and arcs versus designing algorithms that trace node-arc-node chains across the causal

maps from multiple individuals). Hierarchy, like encapsulation, facilitates the orderly

development of representational complexity. This orderly development not only assists

in the design, implementation, and maintenance of software tools for causal mapping, it

also allows designers to integrate the various types of cognitive maps. Integration can

be achieved because the causal, categorical, and other cognitive maps share a common

structure (i.e., node-arc-node segments) that allow them to be linked together in a unified

and analyzable fashion (e.g., as in the example IS security procedures __ updating

firewalls−→damage from virus attacks loss of data __ risk, where __ represents

synonymous (i.e., categorical) relationships, and and−→represent causal

relationships of direct and inverse proportionality, respectively).

The four elements of abstraction, encapsulation, modularization, and hierarchy will now

be used to describe the abstract problem space (i.e., the logical model) for a social causal

mapping system. In object-oriented analysis and design, those elements involve abstractions

and their interrelationships which are then described in terms of object and class

structures. A summary of descriptions of abstraction, encapsulation, modularization,

and hierarchy is provided in Table 3 for convenience. Readers desiring more in-depth

descriptions of those elements are referred to works such as Booch (1994).

Concept Definition Application to Causal Mapping

Abstraction The emphasis of details that are relevant and

the suppression of those that are not (Shaw,

1984:10).

“The essential characteristics of an object that

distinguish it from all other kinds of objects”

(Booch, 1994:511)

Common characteristics of causal,

categorical, and other maps can be

generalized within a common framework (a

“super-class” such as CognitiveMap); aids

design and implementation of software for

multiple kinds of cognitive maps.

Encapsulation The separation of an object’s interface from

its implementation (Booch, 1994:513).

Provides independence of cognitive map

types.

Hierarchy “A ranking or ordering of abstractions”

(Booch, 1994:514).

Hierarchies exist in the several ways.

Aggregations form hierarchies based on

fundamental objects used to construct higherorder

objects (e.g., maps built from nodes and

arcs). Taxonomies of classes can be formed

from sub-class and super-classes (e.g.,

cognitive maps are subdivided into causal,

categorical, and other maps).

Inheritance The ability of super-classes to impart their

data and method structures to their subclasses

Promotes re-use of design structures, thus

enhancing efficient program coding and

consistency of design across the software and

information system; helps ensure that

important general structures and methods are

not forgotten in the implementation of

specialized sub-classes.

Modularization “A unit of code that serves as a building

block for the physical structure of a system”

(Booch, 1994:516).

Modules describing individual or collective

causal maps should be compatible; that is,

data and information from one module should

be easily accessed by another module.

Table 3. Object-oriented concepts for social causal mapping