Page Areas:

Additional Information:


Science Park 3

We are located on the second floor of the Computer Science Building (Science Park 3) ...  more of Location (Titel)

Position Indication:


C2O Configurator 2.0


05/12/2011 Tool Update (including different isolation techniques, new HUMUS computation in PicoSAT)
11/11/2010 Tool Update (includes some bug-fixes)
11/03/2010 Tool & Site Update (added CNF relation to be used for Import purposes)
10/20/2010 Website online

C2O Configurator 2.0 Description

Decision models are widely used in software engineering to describe and restrict decision-making (e.g., deriving a product from a product-line). Since decisions are typically interdependent, conflicts during decision-making are inevitably reached when invalid combinations of decisions are made. Unfortunately, the current state-of-the-art provides little support for dealing with such conflicts. On the one hand, some conflicts can be avoided by providing more freedom in which order decisions are made (i.e., most important decisions first). On the other hand, conflicts are unavoidable at times and living with conflicts may be preferable over forcing the user to fix them right away – particularly, because fixing conflicts becomes easier the more is known about an user's intentions. The C2O (Configurator 2.0) tool is one example how guided decision-making could look like. The tool allows the user to answer questions in an arbitrary order – with and without the presence of conflicts. While giving users those freedoms, it still supports and guides them by 1) rearranging the order of questions according to their potential to minimize user input, 2) providing guidance to avoid follow-on conflicts, and 3) supporting users in fixing conflicts at a later time.

Download and Installation Instructions

System Requirements

Java 1.6 or better

Windows Users

application/ (1.2 MB, Download and extract the ZIP ( file and run run.bat)

Linux Users

application/gzipC2O.tar.gz (1.0 MB, Download and extract the tar.gz (C2O.tar.gz) file and run

Third party libraries

More information on used third party libraries can be found at the following addresses

- prefuse
- PicoSAT

Getting started

Model Format

This specifies the preliminary model XML format, at the moment not many validations are performed so make sure you get it right.


< ?xml version="1.0" encoding="UTF-8" ? >
< model name="Example" >
     < questions >
     < /questions >
     < relations >
     < /relations >
< /model >

Each model has to have a < model > element as root where the name of the model is specified via the "name" attribute. Since some caching is performed and saved on the harddrive make sure this name is unique, otherwise switching between models with the same name might cause strange side effects. This < model > element has two child elements < questions > and < relations > which are explained next.


< question identifier="Question 1" description="Which Question do you want to answer?" >
     < choice name="Question 2" / >
     < choice name="Question 3" / >
< /question >

The < questions > element can have any number of child elements. Each must have a unique "identifier" attribute, and can have have a description containing the whole question. Each must have at least one element as a child. The < choice > element represents one possibility of how to answer the question and again must have a "name" attribute that has to be unique in the scope of this < question > element.


Constraint Relations in always must have one source question and at least one target question. Each < source > and < target > element must have a set attribute "questionIdentifier" that has to correspond to the unique identifier of a defined question.

< constraintRelation >
     < source questionIdentifier="Question 2" / >
     < targets >
         < target questionIdentifier="Question 4" / >
     < /targets >
     < rule choiceName="Choice 1" >
         < allowed choiceName="Choice 1" / >
     < /rule >
     < rule choiceName="Choice 2" >
         < disallowed choiceName="Choice 1" / >
     < /rule >
< /constraintRelation >

A Constraint Relation defines a relation where selecting choices for the source question constrain the possibilities for selecting choices of the target question. If you have more than one target question keep in mind that all the specified target questions must have the same choices.

Besides the source and targets a constrained relation can have rules. At most one for each choice of the source question. Each element has to have a "choiceName" attribute identifying a choice of the source question. This element can have either or child elements but not both, again with a "choiceName" attribute identifying a choice of the target question.

The semantics of the two rules given in the example are:
- If "Choice 1" of "Question 2" is selected only "Choice 1" is allowed as answer for "Question 4". The same is true for the other direction, meaning if "Choice 1" of "Question 4" is selected only "Choice 1" is allowed as answer for "Question 2"
- If "Choice 2" of "Question 2" is selected, every choice but "Choice 1" is allowed as answer for "Question 4", again if "Choice 1" of "Question 4" is selected any choice but "Choice 2" is allowed as answer for "Question 2". (this statement would be even further constrained by the first rule)

The semantics of choices where no rule is explicitly defined is that a combination with any choice of the target is possible.

Relevancy Relation

Relevancy Relations in always must have one source question and at least one target question. Each < source > and < target > element must have a set attribute "questionIdentifier" that has to correspond to the unique identifier of a defined question.

< relevancyRelation >
     < source questionIdentifier="Question 1" / >
     < targets >
         < target questionIdentifier="Question 2" / >
     < /targets >
     < irrelevantIf choiceName="Question 3" / >
< /relevancyRelation >

A Relevancy Relation defines a relation where selecting choices for the source question renders other questions relevant or irrelevant (determines if they need to be answered by the user). This relation can also be used to impose a specific partial order onto the automatic guidance calculation.

Besides the source and targets a relevancy relation can have rules. Those rules are represented by either a or element, at most one for each choice of the source question. Again those elements should not be mixed. Each of those elements has to have a "choiceName" attribute identifying a choice of the source question.

The semantics are:
- If no < relevantIf > or < irrelevantIf > element is defined, every choice of the source question makes the target questions relevant. This can be used just to impose a partial order onto the automatic guidance calculation.
- If < relevantIf > elements are used each choice identified by these elements will render the target questions relevant, all other choices will render them irrelevant.
- If < irrelevantIf > elements are used each choice identified by these elements will render the target questions irrelevant, all other choices will render them relevant.

CNF Relation

A CNF Relation is intended for more complex relations that cannot be expressed with the other two kinds of relations. You basically can write any CNF (conjunctive normal form) clause and add it as a relation. No source or targets are required for this type of relation.

< cnfRelation >
       < literal question="Question 3" choiceName="Choice 1" positive="true" / >
       < literal question="Question 3" choiceName="Choice 2" / >
       < literal question="Question 5" choiceName="Choice 3" positive="false" / >
< /cnfRelation >

A CNF Relation consists of elements, where each element represents one literal in a CNF clause, the attribute "question" and "choiceName" specify the answer that is internally represented by a literal, the attribute "positive" indicates whether the literal should be added as is (literal, positive="true" which can be omitted) or negated (not(literal), positive="false").

The semantics of this example are:
- (Question 3(Choice 1)) v (Question 3(Choice 2)) v not(Question 5(Choice 3))

Download Examples



Questions (1)

- Significance of Font Size: The bigger the font size, the higher is the potential (gain) of this question at this moment to lead to the desired configuration via the shortest path possible, if answered next. This potential is recalculated after every decision made by the user and adapts automatically.
- Green: Decision made by the user
- Yellow: Decisions automatically made by the reasoning engine derived from user decisions
- Red: Decisions which are in conflict with at least one other decision
- Orange: Highlight color for questions that match the search pattern

Choice list (2)

- Green: Choices which can be selected at this time without introducing any conflicts (or is already selected)
- Red: Choices which will result in a new conflict
- Yellow: Choices which will reduce the number of possibilities of how the current conflicts can be resolved. If the number of possibilities is reduced to one a conflict can be resolved automatically, and it will be dealt with according to the settings (Option -> Automatically Resolve Conflict)


- Explanation box (3): If you click the question mark (6) right next to a choice, you get infos about the effect if you select this choice as the answer to the question
- Back - Forward (4): Let's you move forwards and backwards in the history of your decisions
- Undo answer (5): The currently selected choice for this question is undone
- Get explanation (6): Displays which effects a selection of this choice would have.
- Search (7): You can search for a specific question which will be highlighted

Menu - File

- Reset: Resets the reasoning engine, and let's you start over
- Change Model: List of all available models you can change too
- Load Model: Loads a model in the above specified XML format

Menu - Options


- Activate Guidance: Gains will be calculated. The question font size adapts according to the calculated potential for leading to the shortest path if answered next
- Automatically Resolve Conflict: If activated the SAT Solver automatically solves conflicts if possible. If not activated you will be asked if you want to keep your original choice or take the proposed choice from the SAT Solver
- Change Conflict Isolation Strategy: Adds the possibility to change the Isolation strategy during the Isolation of a Conflict. The choices are HUMUS, MaxSAT and Skip in- or excluding implicit trust (trust the last user decision that caused the conflict). HUMUS basically isolates all contributors and MaxSAT isolates as few as possible (random), whereas Skip explicitly does not trust the decision that caused the conflict and skips it.
- Change SAT Solver: Adds the possibility to change the SAT solver from PicoSAT to SAT4j and vice versa, PicoSAT is faster (especially with the HUMUS calculation) but needs native libraries (which are provided with the download)


- Hide Irrelevant Questions: Hides (at this time) irrelevant questions, for a better overview.
- Redraw all: Redraws the complete GUI after each change, instead of only changed parts which is a little bit slower. This is useful because sometimes the size changes cause artifacts.
- Show Gain Tooltip: Adds a mouse-over-effect to each question which displays its current gain value
- Black & White: For presentation or printing purposes the GUI can be switched to gray scale.


Is the source code publicly available?

For the time being the source code is not publicly available. If you like the tool and want to use its technologies please contact us directly, so we can work something out.

Can I use other Data Types than String as question answers, or have multiple choice answers?

The reasoning engine can handle different data types and multiple choices answers, but this prototype cannot visualize and handle them at this time, also no support for loading such models is provided at the moment.

Does this technology work with other type of models?

- The conflict detection, explanation, and living with conflicts approach is built on SAT-solving technology, as a consequence it works with all models that can be translated into CNF (conjunctive normal form) and used by a SAT-Solver.
- The guidance heuristics is also implemented for models translatable into CNF. But the concepts behind it are very general so it should be easy to adapt to other models as well.

C2O related Publications

Research Papers

Nöhrer, A. and Egyed, A. Optimizing User Guidance during Decision-Making. In Proceedings of the 15th International Software product Line Conference (SPLC), Munich, Germany 2011.

Tool Papers

Nöhrer, A. and Egyed, A. 2010. C2O: A Tool for Guided Decision-Making. In Proceedings of the IEEE/ACM international Conference on Automated Software Engineering (Antwerp, Belgium, September 20 - 24, 2010). ASE '10. ACM, New York, NY, 363-364.

Workshop Papers

Nöhrer, A. and Egyed, A. 2010. Conflict Resolution Strategies during Product Configuration. In D. Benavides, D. Batory, and P. Grünbacher, editors, VaMoS, volume 37 of ICB Research Report, pages 107--114. Universität Duisburg-Essen, 2010.


For general information or cooperation suggestions contact either:

Bug reports are also very welcome. Please direct them to alexander.noehrer(/\t)


C2O is provided with no warranty. Use at your own risk.