Tree of Attributes
==================

In a :doc:`multi-attribute <DEXiGlosMAMod>` model,
:doc:`attributes <DEXiGlosAttr>` are organized hierarchically into a
*tree of attributes*. A model can have one or more *root attributes*.
Each attribute can be 'decomposed' into one or more descendant
attributes that appear one level below that attribute in the tree.
'Decomposed' attributes are called *aggregate attributes*. Attributes
that do not have descendants and appear as leaves of the tree, are
called *basic attributes*.

Interpretation
--------------

A tree of attributes can be interpreted in three ways:

#. *Decomposition*: It represents a decomposition of a decision problem
   into sub-problems. To solve 'a problem', which is represented by a a
   higher-level attribute, one has to solve sub-problems represented by
   its lower-level descendants.
#. *Dependency*: A higher-level attribute depends on its immediate
   descendants in the tree. This dependency is modeled by a :doc:`utility
   function <DEXiGlosFunct>` that corresponds to the higher-level
   attribute.
#. *Aggregation*: Tree structure defines the bottom-up aggregation of
   option values. The value of a higher-level attribute is calculated as
   an aggregation of the values of its immediate descendants in the
   tree. Again, this aggregation is defined by the corresponding
   :doc:`utility function <DEXiGlosFunct>`.

The interpretation of attribute types is as follows:

-  *basic attributes* represent inputs of the model,
-  *root attributes* represent its main outputs, and
-  other *aggregate attributes* represent intermediate results of
   :doc:`option evaluation <DEXiGlosEval>`.

Example
-------

See the tree of attributes for :doc:`Car Evaluation <DEXiCarTree>`.

Recommendations
---------------

#. Before editing a tree in :doc:`DEXi <DEXi>`, sketch it on paper.
#. Before making a real tree, create an unstructured list of attributes.
   Brainstorm! At this stage, try not to overlook important attributes,
   but do not bother about their structure or redundancy.
#. When making a structure of attributes, create meaningful subtrees
   that contain related attributes. Try structuring your unstructured
   list in two directions:

   -  Bottom-up: Group similar attributes together into a single
      higher-level attribute. It is usually a good indication if you can
      find a meaningful name for it.
   -  Top-down: Decompose complex attributes into simpler ones.

#. Avoid meaningless, redundant, duplicate, inessential and
   unoperational attributes. In other words, check each basic attribute
   that:

   -  it has a well defined meaning,
   -  it does not duplicate or overlap with some other attributes,
   -  it does affect the decision (and you know how, at least
      approximately),
   -  it can be measured or assessed with sufficient accuracy.

#. Avoid aggregate attributes that have more than three descendants. Too
   many descendants cause a :doc:`combinatorial
   explosion <DEXiGlosExplos>` on the size of corresponding
   :doc:`utility functions <DEXiGlosFunct>`, making them extremely
   difficult to handle. In this case, try to
   :doc:`restructure <DEXiGlos4to3>` the tree below that attribute.

See also
--------

DEXi's :doc:`Model Page <DEXiIntTabMod>`.

Explanation of :doc:`linked attributes <DEXiGlosLink>`.

.. toctree::
  :hidden:

  DEXiGlosLink