Accepted

We need to know whether dqcockpit does (interactively) modify the results to design the interfaces between dqcockpit and other components.

dqcockpit does not modify the results - at least not in a way that is relevant to other components. dqcockpit still allows to modify the layout / presentation of the results.

The amount of external required functionality for dqcockpit is low resulting in a reduced coupling of the component. The drawback is that users have to create or modify a RQA to get new results

Users can modify the RQA results or the RQA in dqcockpit - we do not allow that since dqanalyzer is responsible for defining RQAs and the responsibilities of the components need to be separated.

Proposed

The dqcockpit has to obtain the RQA results in some way. We need to know which component is responsible for updating the results in the cockpit.

The dqcockpit decides when to poll results.

This requires a notification mechanism to publish the status of the analysis (more effort) or dqcockpit has to poll frequently (inefficient). However, other components (dqanalyzer) could be notified as well and poll the same results. Furthermore, the status could be interesting for other functionalities as well to keep the user posted on the current progress.

Another component dqexec / dqtranslator could directly send the results to the dqcockpit, although it could not be available. Furthermore, changes to the sender will be necessary if other components are interested in receiving the state / results which increases coupling.

Proposed

To model the overall architecture, the dependencies of the dq-components need to be defined. Dqcockpit has to get the results and it must be clear which component is responsible for translating the technical RQA results to the domain RQA results.

dqtranslator is the component that delivers the domain RQA results directly to dqcockpit (after being requested to do so).

dqcockpit never speaks to dqexec so the coupling between these two components is low. However, there is probably more implementation overhead in dqtranslator.

dqexec could send the results directly to dqcockpit and dqcockpit could then use the dqtranslator to map them to the domain level. However, that would create more complex communication between several components leading to lower maintainability.

Accepted

The question is whether modeling domain stories is part of dqualizer. If yes, a key decision would be to develop an own modeler (big effort) or use an existing, established one (high dependency on that tool and its development). The second case is particularly relevant since there are not many DST modelers and the WPS modeler is hard to extend.

dqedit does not need to be able to model domain stories.

Modifying domain stories is less convenient for the user since it has to be done in another tool. On the other hand, dqedit is easier to develop and maintain with a weaker dependency on the domain story modeller(s). In theory, dqedit could import different domain story description formats of different modelers.

Dqedit must be integrated in a domain story modeler. Modeling and annotating are usually two quite separate use cases (there is often no reason to change the domain story when defining an RQA). Thus, the usability in this rare use case can be neglected in favor of significantly reducing the implied constraints on the development of dqedit and probably lower usability in the core use cases.

Proposed

The initial dqanalyzer created by Dominik shows the results of RQA inside of the dqanalyzer. The question is whether we want a clear separation of specifying RQA definitions and investigating the results.

dqedit can also show (partially) the same or different results but should keep it on a high level

Seeing the results in the dqedit makes it easier for users to get an answer to their domain question since they have everything in one place. In particular, users can relate metrics to domain elements. However, additional care is necessary to not develop duplicated functionality in dqedit and dqcockpit.

dqcockpit could be the sole source for the RQA results. However, in Dominik’s evaluation participants explicitly stated that they liked "to have everything in one place".

Proposed

The main component for investigating the RQA results is dqcockpit. Thus, we need to define where dqanalyzer gets the results from, i.e., whether the source is dqcockpit or another component.

dqedit can obtain results from dqtranslator similarly than dqcockpit

dqtranslator is the central source of domain RQA results for the front-end components, keeping its cohesion high.

dqedit could obtain (reduced) results from dqexec or dqcockpit which would probably be more efficient but reduce maintainability. We do not want to maintain several ways of obtaining results.

Proposed

RQA definitions should be persisted, but not every component needs access to them.

dqanalyzer (internally) persists the RQA definitions.

Other components can not get the RQA definitions without contacting dqanalyzer

There could be a global database but dqanalyzer (and other components) would have external dependencies with increased effort for maintaining and accessing the data. However, in theory, there is no need for other components to persist the RQA definitions since dquanalyzer provides them if necessary.

Proposed

Schemas for the mapping, RQA definitions, etc. …​ can change and should have a version to be compatible with one another and with the models.

We use the functionality provided by Git(Hub) that is actually designed for file versioning.

The effort for providing versioning functionality is significantly reduced. However, implementation is also restricted to the provided functionality by Git(Hub).

Own implementation, but versioning is not one of our key functionalities and competencies.

Proposed

Do the existing dqlang schemas have to be unified? In the future, this would require different dqualizer members have to learn the use of this meta model.

The dqlang schemas can be defined using different meta models

This makes it easier for dqualizer members to use the techniques they are familiar with. Furthermore, the used meta model is (ideally) always the most suitable for the schema. The drawback is potentially low compatibility between the different schemata.

Every dqualizer member uses the same meta model. We do not want to enforce that - everyone should use his/her expertize best.

What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?

What is the issue that we’re seeing that is motivating this decision?

What is the decision that we’re proposing and/or doing?

What becomes easier or more difficult to do because of this decision?

What are alternative options considered, along with the reasons they were not selected?