Software Design Case Study - Vroom-Jago Decision Tree

The Vroom-Jago model has undergone some transformation since its inception. This project implements the model as described by Schermerhorn, John R., James G. Hunt, and Richard N. Osborn. Organizational Behavior. 7th ed. New York: John Wiley & Sons, Inc., 2000. p 363-64.

The Problem

The problem was to write an application that implements the Vroom-Jago decision tree model. The model defines five leadership styles that can be used in a situation:

AI – The manager solves the problem or makes the decision alone, using information available at that time. (Autocratic.)

AII – The manager obtains the necessary information from subordinate(s) or other group members and then decides on the problem solution. The manager may or may not tell subordinates what the problem is before obtaining the information from them. The subordinates provide the necessary information but do not generate or evaluate alternatives. (Somewhat autocratic)

CI – The manager shares the problem with relevant subordinates or other group members individually, getting their ideas and suggestions without bringing them together as a group. The manager then makes a decision that may or may not reflect the subordinate’s input. (Somewhat Collaborative.)

CII – The manager shares the problem with subordinates or other group members, collectively obtaining their ideas and suggestions. The manager then makes a decision that may or may not reflect the subordinate’s input. (Collaborative.)

G – The manager shares the problem with the subordinates as a total group and engages the group in consensus seeking to arrive at a final decision. (Group Consensus.)

Eight questions are asked (in this order) about the specific problem:

Problem Attribute	Manager’s Question
QR – Quality Requirement	How important is the technical quality of this decision?
CR – Commitment Requirement	How important is subordinate commitment to the decision?
LI – Leader’s Information	Do you have enough information to make a high-quality decision?
ST – Problem Structure	Is the problem well structured?
CP – Commitment probability	If you were to make the decision by yourself, is it reasonably certain that your subordinate(s) would be committed to the decision?
GC – Goal Congruence	Do subordinates share the organizational goals to be attained in solving this problem?
CO – Subordinate Conflict	Is conflict among subordinates over preferred solutions likely?
SI – Subordinate Information	Do subordinates have sufficient information to make a high-quality decision?

Each question forms a node on the decision tree. Based on the response to QR, the decision tree is traversed to the next node, and so on until the answer is reached. Depending on the answers, some nodes are skipped.

The Design

First, a User Interface design was mocked up using a drawing tool. The mockup revealed two useful design goals: Do not enable a question until it is time to answer the question. Have the ability to play "what-if" by changing a prior answer and immediately seeing the new answer. It also illustrated that each question had four attributes that varied: The text for the first radio button (e.g. "High" or "Yes"). The text for the second radio button (e.g. "Low" or "No"). The text of the question itself. The user's selection (which radio button was checked, if any). I chose a data-driven method to define a static structure array for the questions. Each structure in the array defined a) the Question's Logical Name, b) the Yes Text, c) the No Text, d) the Question Text, and e) the user's selection. It was also apparent that each question could have three possible values: a) First Button Checked, b) Second Button Checked, and c) Not Answered. Each time a radio button was clicked, the entire decision tree would be traversed, starting at QR, and progressing until it either reached an unanswered question or the answer.

A Mealy state machine would be used to implement the decision tree. The state and transition tables would be used to implement the decision tree logic. The Activity diagram for walking the tree is as follows:

This would be a dialog based application. The class collaboration was:

The main dialog box would create the CVRtree object, passing the user responses to the object. CVRtree would send messages back to the dialog box to update the screen controls. However, I did not want CVRtree to know how the UI was implemented, so I used SendMessage() to pass messages back to the UI. This decoupled the decision tree object from the UI implementation.

Communicating to the UI was done as follows:

The Implementation

During implementation it was useful to add a fourth possible value for each question: "Not Applicable". That allowed the answer states to be handled in the state machine just as if they were questions. This also simplified the task of doing "what-if" by changing a prior answer. In fact, because of the design, no additional code was required to implement the "what-if" feature.

Get source code in C++.

Get executable program.

Unit Testing

Unit testing required a test for each decision node. Using the decision tree as published in the textbook, I answered each question in succession, verifying that the correct branch was taken at each node.