5.4.2 Architectural Decisions
Tables 5.7 and 5.8 reference the most important architectural decision problems (DP).
Table 5.7 discusses the storage of decision groups within Jira. Table 5.8 discusses whether to implement a model class for decision groups. Note, that decisions are also valued by their contribution to the NFR's this thesis mainly focuses on (see Section 4.5).
Table 5.7: DP: How should the groups be stored in Jira?
Type Description
Modi- abi-lity
Time behav-ior
Attrac- tive-ness Decision Use a database of group entries
Pros - Fast access
- Storage handled mostly by Jira Cons - New Database required
- Handler for Database required
Alternative Store them as attributes to knowledge ele-ments
Pros - No new classes required
Cons - Slower access if all groups are extracted - Storage dependent on knowledge ele-ments
Table 5.8: DP: Should a new Group-Model-Class be created?
Type Description
Modi- abi-lity
Time behav-ior
Attrac- tive-ness Decision Declare Groups as Strings
Pros - Simple and ecient storage - Less complication
Cons - No additional attributes can be added Alternative Create a model class for Groups
Pros - Versatile
- Allows future expansion Cons - Complex to handle
5.4.3 System Function Related Decisions SF8: Group Knowledge Elements
As discussed in the Review Discussion (Section 3.5) the limited amount of predeter-mined grouping schemes, increases the diculty for the user to assign their decisions correctly and with a low enough eort. As such, it was decided to only implement this predetermination in a very limited manor. Users are required to select from one of three decision levels (High, Medium and Realization Level) when assigning a group but are otherwise free to assign groups with any name they desire. This allows some form of uniformity across the project, while keeping the grouping process relatively simple. It is also more versatile to assign custom groups for each project individually, rather then predetermining them universally.
Another decision that had to be made was how the inheritance of groups between related knowledge elements would work. Multiple alternatives existed for this. The rst would be to not implement any inheritance what so ever and assign each element individually.
This however would result in additional eort should a user require each related element to be of the same group and could lead to a loss of connection between elements as they would not automatically carry similar groups. The next alternative would be to imple-ment universal inheritance. In this case, if one eleimple-ment of the knowledge tree was tagged with a group, all others would automatically be equipped as well. The problem with this approach however would be that, as individual elements are tagged with dierent groups, the tree could become overloaded with too many of them, reducing the value of the grouping mechanism. The third alternative, which was chosen for the project, was to implement a top-down inheritance scheme, in which all knowledge elements below another in the tree would inherit the group from the one above but not the other way around. This approach seemed to provide a good compromise between the other two alternatives.
SF9: Manage knowledge element groups
The question of how to visualize the groups existing within a project was decided on based on the tasks of the related view (WS3.7). Since the views main task was the bulk deletion or renaming of existing groups, it was decided to provide a very simple clean look. The view, tasked with implementing this system function, merely presents a table listing the existing groups, with the connected decision knowledge elements and java classes. The editing of the group is done via the custom context menu already existing in ConDec.
Additionally, to keep the view as simple and clear as possible, instead of listing the keys of all connected issues, the table simply lists the number of knowledge elements and code classes connected to the group. This allows the users to easily assess how many elements are eected by their changes. The functionality of seeing all elements belonging to a group is still present in the Decision Knowledge Overview (WS3.1) and the Code Classes View (WS3.6) by using the provided group lter.
SF10: Filter knowledge graph
Lastly, the decision was made to allow the grouping lter to be combinable. This means
be all High level decision within the "Safety" group.
5.4.4 Results
Figure 5.8 shows the results of the Decision Group View (WS3.7) implementation and can be compared to the mockup in Figure 4.12 in Section 4.7. The view presents a table listing all decision groups that are currently assigned to at least one knowledge element.
On the right side it shows the number of assigned decision knowledge elements and also the number of assigned Java classes. By right-clicking a group the user is presented with the possibility of either renaming the group or deleting it completely. By choosing these options, the change is automatically propagated to all assigned elements.
Fig. 5.8: Decision Group View
6 Quality Assurance
This chapter describes the quality assurance process for the ConDec extension. It species the planing, execution and analysis of all tests done in relation to the extension.
Section 6.1 species the general planing and structure of the dierent tests. Section 6.2 explains the static code testing that was part of the implementation. Next, Section 6.3 describes the component tests necessary for the ConDec extension. Lastly, Section 6.4 then introduces the system tests done in relation to the system functions of the extension.