Overall review

In summary, three essential elements constitute the GMCR+ DSS: the structure of the model (conflict specifications), conflict data processors, and display components (GUI).

The conflict specification is built on a structured set of objects (options, DMs, condi-tions, etc.) with defined properties and interactions that exist within a conflict model as outlined in Section 6.2.

The “conflict data processors” as explained in Sections 6.3 and 6.4 constitute the so-lution engines. GMCR+ has 4 distinct and independent “solvers”: the logical solver, the matrix solver, the inverse solver, and the goal seeker.

The GUI is the component which the user actually interacts with. The purpose of the GUI is to control the flow of all parts of the program. It is organized into screens, of which there are eight so far (more can be easily added). Each of these screens is composed of a series of smaller elements that display and/or control some elements of either the conflict model or one of the solution engines. These elements are reusable on multiple screens, as appropriate. When a user launches the program, the basic parts of the user interface are constructed, then an empty conflict model is formulated. GMCR+ then initializes all the parts of the interface that are meant to contain and/or control conflict information by building those elements and giving them references to the part of the conflict model they are meant to represent. When a user interacts with a part of the interface, it sends a message to the conflict model and the requested change is executed. This change is then reflected in all other elements of the interface that hold references to that part of the conflict model.

When a user navigates to one of the result screens (Equilibria Results, Inverse GMCR, or Post Analysis), GMCR+ creates an instance of one of the solvers, giving it a reference to the current conflict model. The solver does the work of interpreting the conflict model and generating results. The interface elements of the screen (some of which communicate with the conflict model, some with the solver, while others communicate to both) display the results generated. Moreover, GMCR+ allows the user to request additional analysis from the solver, the results of which are returned to the appropriate user interface element.

Figure6.17 illustrates the di↵erent elements of GMCR+ and their interactions. More-over, the figure depicts the modular design of GMCR+ and how new extensions can be integrated.

6.9.2 Complexity

Algorithms are commonly measured for computational complexity in order to determine time and memory requirements as a function of the input, and are commonly expressed us-ing the O-notation (Papadimitriou,2003). Complexity class is based on the mathematical logic required. Complex computations are classified as Non-deterministic Polynomial-time hard or NP-hard which is “at least as hard as the hardest problems in NP”. (Bovet et al., 1994). Less complex operations are classified as polynomial. The primary operation in GMCR+ is a simple comparison, which has a complexity of O(m), where m refers to the number of feasible states in the conflict model. However, the comparison operation is per-formed on the reachability matrix which has a size of m⇥ m. Therefore, initializing the

Logical

There are recent and ongoing expansions

of the GMCR methodology which can be conveniently incorporated into GMCR+ due to its modular design The program has 4 distinct and independent "Solvers"

Model

. . .

Input ScreensOutput Screens

Figure 6.17: Elements of GMCR+ and their interactions

matrix has a complexity of O(m²). Using the improved method ofPeng(1999), populating the reachability matrix has a worst-case complexity of O(2^2m/n) where n denotes the num-ber of DMs. This level of complexity was achieved in GMCR II by limiting the scope of the search to only possible moves among states controlled by each DM instead of looping through all feasible states (Peng, 1999).

The number of permutations for calculating Inverse GMCR using brute-force is given by (m!)ⁿ as mentioned in Section 5.2.5, making the complexity of this implementation O(m!). This can harm the system performance especially when large models are used.

However, the improved approach based on the definitions stated in Section5.2 reduces the complexity to less than O(m²).

Memory issues may arise as the core of any conflict model within GMCR+ is based on a dense reachability matrix. The full reachability matrix with size m⇥ m is created in memory. The observed limit is around 20,000 states using a computer with 4GB of RAM, and reflects the memory required to hold the reachability matrix. Most real-world models in the literature contain fewer than 1,000 states, making GMCR+ sufficient. Moving to dynamically generated reachabilities could eliminate this constraint for conflicts having more than 20,000 states, and might be an important future project .

6.10 Chapter Summary

The framework, modules, and algorithms used within the newly developed DSS, GMCR+, are presented in this chapter. GMCR+ allows the analyst to be accurate, efficient, and insightful in modeling and analyzing strategic conflicts. The presentation and visualization components of GMCR+ provide a superior platform for communicating conflict dynamics and results. Strategic insights are derived from the rich, easy-to-manipulate post-analysis tools within the system. Finally, flexibility and modularity make the system adaptable and open for future theoretical developments in the field of conflict resolution and the graph model. Key highlights of the GMCR+ system include the following:

1. GMCR+ is a comprehensive DSS that has been built from scratch to overcome previous DSS limitations and provide additional features.

2. GMCR+ uses Python and Javascript programming languages, allowing it to be a universal software.

3. All features from GMCR II are included in GMCR+, in addition to many new fea-tures including:

(a) Stability explanation (b) Categorization of equilibria

(c) Interactive graphs and status quo analysis (d) Advanced coalition analysis

(e) Post analysis capabilities

4. GMCR+ includes Inverse GMCR capabilities to facilitate negotiation modeling, in addition to other post analysis features.

5. GMCR+ has four distinct and independent “solvers”: the logical solver, the matrix solver, the inverse solver, and the goal seeker.

6. The modular design of GMCR+ facilitates the addition of new graph model algo-rithms.

Chapter 7