Introduction
Related work
Artifact search and discovery
Context change management
Artifact relevance mechanism
Interface
Technical details and DOI function
ContextCorePlugin
is the one that specifically deals with Mylyn’s ability to handle Java classes, user interactions, and interest values. On the left, the InteractionContextScaling
class stores the interest contribution that each interaction event will add to a class’ interest value at the moment of the interaction. The management of events, classes, and classes’ interest values is performed by the InteractionContextManager
class, which also stores data about task contexts. The class can be seen in the middle of the figure. Below, the InteractionContext
class represents a task context and it may have one or more InteractionEvent
classes, i.e., interaction events. Finally, task contexts contain elements (e.g., classes, methods, and variables), represented by the InteractionContextElement
class, and each of these elements has its own related Degree of Interest function, or an instance of the DegreeOfInterest
class, displayed at the bottom of the figure.
Data | Description |
---|---|
Time | The time when the event occured. |
Kind | The type of event occurred (Table 2). |
Origin | Identity of the tool that caused the event (e.g., new class wizard, keyboard). |
Handle | An identifier for the target element. |
Interaction | ||
---|---|---|
Event type | Contribution | Description |
Selection | 1.0 | Interaction that occurs by selecting files with mouse or keyboard. |
Editing | 0.7 | Interaction that occurs when editing files. |
Command | 1.0 | Operations such as saving or compiling. |
Propagation | 1.0 | Interaction that occurs when other elements are indirectly affected by another interaction event. |
Prediction | 1.0 | Capture of potential future interaction. |
ClassA
. The first line of the table states that the first interaction was a selection on ClassA
. The second line of the table represents the next 10 interactions, which were of the type selection performed on classes other than ClassA
. Note that the class was selected two times (i.e., in interactions #1 and #12). Therefore, its interest value is innitially calculated as 2 selections×1=2. However, since a class’s interest value decreases according to the number of interactions performed over time, a decay value has to be subtracted. In this example, the decay value is (current interation-first interaction on class)×decay_constant. Mylyn uses decay_constant=0.017. Thus, decay_value=(22−1)×0.017=0.357 needs to be subtracted from ClassA
’s interest value according to Eq. (4). In the end, the class’s final interest value is 2−0.357=1.643 according to Eq. (3), which is positive, meaning that this class is still interesting for the task being executed.
Index | Quantity | Event | Target |
---|---|---|---|
#1 | 1 | Selection | ClassA |
#2–#11 | 10 | Selection | Other classes |
#12 | 1 | Selection | ClassA |
#13–#22 | 10 | Selection | Other classes |
MylynSDP
Concept description
Overview
Context creation
Interactions
Interaction | ||
---|---|---|
event type | Contribution | Description |
Specification | 5.0 | Supports tasks’ initial context creation. |
Tool and architecture
Wizard
Architecture
InteractionContextScaling
had the interest decrease parameter modified from 0.017 to 0.2 to filter out unnecessary artifacts with less interactions. As explained in the next paragraph, the modification of the decay parameter is made to take into account the number of interactions with the different types of software artifacts (e.g., code files, use case documents). Moreover, the refresh rate was updated so MylynSDP’s views may reflect changes rapidly. Note that a new type of interaction was introduced, and a few changes were made to InteractionEvent
and InteractionContext
classes. The DegreeOfInterest
class had its interest calculation changed. The first modification is related to the ability to increase the interest value according to the Specification interaction event. The DOI function’s second modification allows the first interactions to be of higher importance than the others. The details of the DOI function’s implementation are provided next.
getValue()
method to retrieve the interest value for an artifact in relation to the running task context.getValue()
method calculates a partial interest value (line 3) and then subtracts a decay value (line 4) from this partial interest value. The main modifications from Mylyn’s DOI function are in each of the two other methods. Interest value calculations are initiated in the method named calculatePartialInterestValue()
. The method calculates the number of occurrences of a particular type of interaction times a constant associated with that type of interaction (i.e., its contribution to the interaction value). This is done for selection (line 10), edition (line 11), and command (line 12) interaction event types that already exists in the original Mylyn. For instance, if a particular artifact has been selected five times, its partial interest value is 5×1=5, because selection contributions are worth one each. The new Specification event is captured by the specificationBool
variable. The variable is a zero-or-one value that indicates if the artifact initially belongs to the current task context based on the software process specification. If this is true, then the value five is added to the artifact’s interest (line 14). The value five is the contribution made by the Specification interaction event. The value is arbitrary and was reached after testing the code and calibrating it. The calculateDecayValue()
method is then called to calculate an offset of the interest value, referred to as the decay value in a way similar to how Mylyn does it. The decay value of a particular artifact is based on how many interactions were performed in that task context since the creation of that artifact (see Eq. (4)). As explained earlier, the number of interaction events performed since the creation of a particular artifact (line 21) is multiplied by a decay constant (line 22). The novelty, in the case of MylynSDP, relates to the inclusion of the number of Specification interactions and the new decay constant in the calculations. An example may clarify these calculations. Suppose an artifact was created during interaction #10 and five other interactions happened to other artifacts, meaning that the most recent interaction event is #15. The decay value is now calculated as (15−10)×0.2=1. This value is the result of the calculateDecayValue()
method to the getValue()
method (line 22) as that artifact’s decay value. Finally, the getValue()
method calculates and returns the interest value for a particular artifact in a task context (line 5).Artifact A
using the appropriate wizard. After setting its properties, the artifact’s interest value is 5. Now suppose that the software engineer performs a series of interaction events on other artifacts, as illustrated in Table 5. In this example, the interest value is the sum of the contributions of the Specification and the Selection events; that is, (1×5)+(2×1)=7. Following the example, the decay value is calculated as follows: ((23−1)×0.2)=4.4. Thus, the final interest value of that artifact is (1×5)+(2×1)−((23−1)×0.2)=2.6, which is positive, meaning that it is still of interest for the current task’s execution.
Index | Quantity | Event | Target |
---|---|---|---|
#1 | 1 | Specification | Artifact A |
#2 | 1 | Selection | Artifact A |
#3–#12 | 10 | Selection | Other classes |
#13 | 1 | Selection | Artifact A |
#14–#23 | 10 | Selection | Other classes |
Evaluation study
Overview
-
What is the impact of the use of DOI function in managing artifacts in the execution of a software development process?
Exercise | Description | Purpose |
1 | Subjects are expected to locate a particular use case document among many others and add a brief description for that use case. | This exercise executes the activity “Describe UC” and deals with the case in which low filtering is applied, because the software engineer has not interacted enough with the artifacts. |
2 | Subjects are expected to locate a particular use case document among others and update its description by replacing acronyms and abbreviations by their respective expanded meanings. The latter is described in another artifact named glossary. Also, subjects should add an explanatory note beside a particular business rule present at one of the business rule documents. | This exercise executes the activity “Describe UC” and has as its goal to observe subject’s reaction when the task context is small enough to show only a few artifacts to the software engineer. |
3 | Subjects are expected to read a note left by another software engineering asking the subject to review a use case that is not initially part of the subject’s work. Subjects should locate the corresponding use case and fix any grammatical or typing mistakes. | This exercise executes the activity “Review UC Description” and is designed to analyze what subjects do when they do not find an artifact in a task context, either by incorrect filtering or by incorrect software process modeling. |
4 and 5 | Subjects are expected to locate a particular test case document and write a new test case for a given use case based on the specification of this use case. When the subject is about to start writing, the subject is presented with a new high priority exercise. From that moment, subjects are expected to update part of a particular SQL script based on the syntax of other similar SQL scripts. Subjects are then expected to resume the previous exercise. | These exercises execute the activities “Create Test Cases” and “Update DB” and simulate a context change. During the execution of exercise 4, the subject is presented with exercise 5, which is said to be high priority. Then, the subject has to change the context of the task he or she is performing. |
Number | Statement |
---|---|
1 | Using the DOI function in my job would enable me to accomplish tasks more quickly. |
2 | Using the DOI function would improve my job performance. |
3 | Using the DOI function in my job would increase my productivity. |
4 | Using the DOI function would enhance my effectiveness on the job. |
5 | Using the DOI function would make it easier to do my job. |
6 | I would find the DOI function useful in my job. |
7 | Learning to operate the DOI function would be easy for me. |
8 | I would find it easy to get the DOI function to do what I want it to do. |
9 | My interaction with the DOI function would be clear and understandable. |
10 | I would find the DOI function flexible to interact with. |
11 | It would be easy for me to become skillful at using the DOI function. |
12 | I would find the DOI function easy to use. |
-
To investigate the use of a DOI function during the execution of a software development process focused mainly on, but not limited to, the software engineer’s productivity.
-
Does the use of a DOI function improve the software engineer’s productivity during the execution of a software process?
-
-
∙ Subjective opinion about their execution
-
∙ Time of the execution of each task
-
Analysis
Subject | E1 | E2 | E3 | E4 and E5 |
---|---|---|---|---|
S1 | 19 min 13 s | 13 min 09 s | 06 min 42 s | 17 min 19 s |
S2 | 12 min 48 s | 06 min 57 s | 04 min 09 s | 11 min 20 s |
S3 | 06 min 40 s | 05 min 11 s | 05 min 03 s | 10 min 13 s |
S4 | 12 min 06 s | 06 min 56 s | 05 min 36 s | 18 min 26 s |
S5 | 11 min 15 s | 08 min 28 s | 04 min 22 s | 21 min 00 s |
S6 | 09 min 41 s | 04 min 28 s | 03 min 04 s | 05 min 45 s |
S7 | 14 min 20 s | 12 min 49 s | 07 min 40 s | 14 min 45 s |