Approach to Building Decision Support Resources

[Garret-Gallant]

Decision support application resources are inclusive of decisions, factors, and ranks.

I propose that each one of the resources should follow a specific design so that the maintainability of future versions of the application is better.

When creating a new resource, the resource class should be named after the resource, for example:

}```

Each class should have an associated test class in a test package that follows a similar naming convention with the Test keyword appended to the classname, for example: 

```public class DecisionTest {
}```

A class file should include class variables that best describe the needed qualities of a given resource, for example: 

public class Decision {

String name;
int rank;
[]Factor factors; <---- unsure if this would be the correct syntax for a custom type, anyone is welcome to give input

}

Within each class that is not associated with testing the main resource class there should be a constructor that allows for the instantiation of a given resource class. For example: 

public class Decision {

String name;
int rank;
[]Factor factors; <---- unsure if this would be the correct syntax for a custom type, anyone is welcome to give input

public Decision(String name, int rank, []Factor factors) {
this.name = name;
this.rank = rank;
this.factors = factors
}
}

This could use some input from others, as it is very barebones, but in order to get a better start toward being more able to complete some of the issues within the project in a standardized manner, I think this is a great start. 

[jody]

We also need to standardize our nomenclature.
Our stakeholders used alternative terminology:

One source is the Decision Support Process and Computations.
In the System Components section, we find Alternatives and Factors.
Later we find the use of the terms "Pairwise Comparison" and "Cross-Ranking".

Another source is the Decision Support Application - Overview.
Here we find "decision" as being comprised of "alternatives" (aka "outcomes"), "factors" (aka "criteria"), and "relative weighting" and "relative ranking".

In common are "alternatives" and "factors".
It also seems reasonable to consider a "decision" as being comprised of a collection of alternatives.

I'm a bit confused by the example given of a class Decision, as it doesn't seem to fit with any of these terms (decision or alternative).

A quick Java aside... I'm assuming that the notation []Factor factors; was meant to indicate an Array of Factor objects. In Java that would be written Factor[] factors; Instead of requiring use of the array type (along with its odd syntax and fixed size), let's consider using other forms of collections (see: Collections Framework Overview ).

The main questions about creating a new class is whether it embodies a cohesive set of behaviors and state information.