Tasks

Working with the Navigator View

The R4E Navigator View is the main component of R4E. It shows all the information that is available to the user and it is also the place where most user commands are available. The Review Navigator information is organized in a hierarchical tree structure and is presented in a Navigator panel. Elements shown in red are read-only. Commands are available in the view toolbar and in context menus that appear when right-clicking the navigator elements.



When a Review is open, the Navigator view can focus on and display the Review elements in an alternate display that show them in a more compact and table-like way. Both representations can be toggled on by using the Change Display toolbar command.



Disabling and Restoring Elements

When Review Navigator elements are not relevant anymore (e.g. completed reviews), they can be removed from the view by using the ''Disable ''command from the element's context menu.



Disabled elements data is kept, but they will not appear in the navigator view anymore. Take note that currently it is not possible to completely remove references to an element once it is created.

To see disabled elements in the Navigator view, go to the R4E Preferences Filter Tab and select the Show Disabled Elements checkbox and apply the preferences. The disabled elements will show in the Navigator grayed out and with the little disabled decorator icon

Ideally, disabled elements should never be shown, but there could be a need to restore mistakenly disabled elements. To do so, first go to the Eclipse preferences R4E page, on the Filters tab and enable the Show Disabled Elements filter, then return to the Navigator view and select the ''Restore ''command from the disabled element context menu



Sorting Review Navigator Elements

The Navigator elements can currently be sorted alphabetically or by review type, by selecting the appropriate sorter in the Review Navigator Toolbar menu.



Filtering Review Navigator Elements

The Navigator view provides different filters that can be used to limit the visibility of elements within the navigator tree. Filters are available in the Review Navigator Toolbar menu.



The filters available are:


Setting Elements Reviewed State

To help Users to keep track of the content that was reviewed it is possible to mark relevant Review Navigator elements as reviewed using the context menu Mark/Unmark as User Reviewed command. This will put a little done decorator icon. The marking can be removed by using the same command to toggle the state.


Other Review Navigator Commands

These other commands are also available from the Navigator view toolbar and/or drop-down menu:


Take note that not all filters and toolbar commands are available on all Review Navigator representations.


Handling Review Groups and Reviews

Creating a Review Group

When using R4E for the first time, the first thing to do is to create Review Groups that will hold the R4E review data. Typically, Review Groups include common settings that will be used for multiple reviews. For instance, one can create a Review Group for a design organization, for a given project or task etc.

A given Review Groups is created only once, typically by a "super-user" selected among people that are part of the group.

In order to create the Group, select the New Group icon in the Review Navigator Toolbar.



This opens the New Review Group dialog.




Opening an Existing Review Group

When you create a new Review Group, its references are automatically included in your workspace. To add other Review Group references, open the R4E Preference Group Tab (Window->Preferences->R4E, then switch to tab "Groups")




Creating a Review

The Review is the main element of R4E. It is used to group together file that are to be reviewed. There are three type of reviews, Basic, Informal and Formal review (See concepts section for an explanation of the different types of reviews).

To create a new Review, right-click on the parent Review Group under which you want to create the review and select the New Review Command from the R4E Context Menu.



This opens the New Review dialog.




Opening and Closing of Review Groups and Reviews

In order to be able to see the Review Group child Reviews, a Review Group must be open. Closed Review Group are shown with hollow Group icons. You can open a closed Review Group by right-clicking on it and selecting the Open Element command, or simply by double-clicking on it.  Closing unused Review Groups make navigation easier and free up memory and resources, so the Groups should be closed when they are unused.

Likewise, reviews can also be open and closed using the same mechanism. The only difference is that only one review (called the Active Review) can be open at any given time. Opening another Review closes the currently open one.

Take note that Review Groups and Reviews are automatically open after they are first created.


Adding Participants to a Review

Participants are automatically added to the current Review as soon as they add review items to it or create an anomaly. It is also possible to add them manually.

To do so, right click on the parent review and select the New Participants Command from the R4E Context Menu.



This opens the Enter Participant details dialog.



The dialog is divided into 3 sections:


If an LDAP database is configured and connected, the user information could be searched and filled-in automatically using the Find button, which will open the Find User Dialog



Any field can be entered in the Search Filters section and by clicking the Search button, an LDAP query will be sent to the database. If any matches are found, the results will be displayed in the Query Results section. Once the results are in, users can be added by double-clicking on them in the results table, or by selecting them and using the Add Users button. Pressing the OK button will result in the users being added to the New Participants dialog participant list.


Creating a Review Item

In R4E, Review Items are a collection of one or more files, or parts of files, that are to be reviewed. There are two types of Review Items that exist: Commit Review Items and Resource Review Items.


Creating a Resource Review Item

This item type is created by manually selecting a workspace resource (i.e. File) or a portion of a resource (i.e. line ranges within a given file).





Once a Resource Review Item is created, it will be shown in the Review Navigator. If you expand the Review Item, you will see the child elements: The file on which the Review Item is applied and the line range selection that is part of the item.



Creating a Commit Review Item

This item type is created by selecting files that were committed to a Version Control System repository. Currently, the only Version Control System supported is Git.

To create a Commit Review Item, right click on a project attached to the Egit team provider (see Project Configuration) and select the Find Review Items command from the R4E Context menu.



This will show the Version Control System Commit Dialog (Here shown for the Git connector).



Use the Available Commits combo box to browse through all available commits and select one. For the selected commit, the commit information and affected files appear in the Commit Information and Committed Components sections respectively.

Once a Commit Review Item is created, it will be shown in the Review Navigator. If you expand the Review Item, you will see the child elements: The file on which the Review Item is applied and, optionally if the option is selected in the preferences, the line ranges for the Deltas (or differences between the committed file and its direct ancestor) that are part of the Item.



The icons for the files that are new and were added in the commit will be shown decorated with a little icon The icons for the files that were removed in the commit will be shown decorated with a little icon Files in the commit that are out of sync i.e. for which the version to review and the version present in the users workspace differ will be shown with the > sign prepended to the filename. Such files can be reviewed, but to use the full navigatability provided by the editors, it is strongly recommended that the files be in sync with the workspace whenever possible.


Assigning Review Elements

It is possible to assign specific review elements (i.e. Review Items, File Contexts, Selections and Deltas) to specific participants. To do so, use the context command Assign to Participant for the desired elements.

To remove an assignment, use the context command Unassign Participant.

Take note that if a parent is assigned to given participants, then all its children will also be assigned. It is possible to override the parent's values and to change the children's assignments by operating on the child element directly.

Assignments can also be managed by using the Properties view for the selected element.

Creating an Anomaly

R4E Anomalies are raised by reviewers to flag problems or add comments on specific parts of the contents as part of the review process.

Anomalies are added in a similar way Resource Review Items are, either from a selected Resource or from a portion/range of a resource, by selecting the Add Anomaly command from the R4E context menu.



Anomalies that are directly tied to a specific selection/delta range can also be created by selecting the Add Linked Anomaly command from the context menu of the affected selection/delta in the Review Navigation View



Anomalies can also be created at the review level. This is useful to flag problems that are not specifically tied to a given file or file part. To do this, use the Add Anomaly Command from the context menu of the Global Anomalies element in the Review Navigator view.



This opens the New Anomaly dialog.




Cloning an existing Anomaly

Anomalies can be duplicated so that their information is applied to a new location and/or file. Anomalies are cloned be selecting a new range in an editor and using the Clone Anomaly contextual command

This will trigger the Clone Anomaly Dialog, where the source anomaly to clone can be selected.

Once this is done, a new Anomaly will appear at the new location with the same information as the source one.

Anomalies can also be cloned to a specific Delta or Selection element by dragging and dropping them unto the desired Delta or Selection, by using the Copy and Paste Review Navigator Contextual commands or by using the generic Copy (CTRL+C) and Paste (CTRL+V) hotkeys.

Take note that the child comments on the source anomaly are not copied to the new cloned anomaly. It is however possible to copy the comments manually (see below).

Creating Comments on an existing Anomaly

It is possible to add comments to an existing anomaly. This could be useful in discussing the anomaly or for tracking purposes. To create a Comment, use the Add Comment command on the context menu on the selected Anomaly.



This opens the New Comment dialog, where the comment can be added.



Cloning existing Comments to an Anomaly

As for anomalies, it is also possible to copy comment information to another anomaly. It is done in a similar way than for cloning anomalies, by dragging and dropping the source comment(s) unto the target anomaly, by using the Copy and Paste Review Navigator contextual commands or by using the generic Copy (CTRL+C) and Paste (CTRL+V) hotkeys

Importing Postponed Anomalies

Postponed Anomalies are Anomalies that were written in previous Informal/Formal Reviews, but were not handled then and were instead set to POSTPONED state. If the current Review include files on which these anomalies were written, whether it is the same or a different version of a file, it is possible to import them in the current review so that they can be addressed. Currently, only Postponed Anomalies that belong to Reviews under the same Review Group can be imported. Global Anomalies that were written in other Reviews in the same Review Group can also optionally be imported.

To import Postponed Anomalies, just select the current Review in the Navigator View and use the context menu:

R4E will scan all Reviews under the current Review Group and will copy all Anomalies in POSTPONED state that were written on files also included in the current Review, and also Global Anomalies in POSTPONED state written in other Reviews, if the option is selected in the preferences. Once the command is done, the imported elements will appear on their own container elements under the Review element in the Review Navigator tree.

From then on, Postponed anomalies will behave like any other Anomaly and can be handled in the same way. All changes except the state changes will be local to the imported anomaly i.e. changing the imported anomaly will not change the original one. When a Postponed Anomaly is modified, the state changes will also be reflected in the original Anomaly (i.e. the one filed in the previous Review). For instance if the imported anomaly is fixed, the original one will be marked as fixed to convey the fact that the postponed issue is now closed.

Take note that Postponed Anomalies that have their state changed from POSTPONED will be disabled. If they are set back to Postponed, they will be restored as Postponed elements.

Handling Design Rules

Creating a Rule Set

R4E support the use of Design Rules, to help reviewers enforce consistent design conventions and rules. A Rule Set is a container that includes multiple related Rules. Rule Sets are independently defined and can be shared among multiple Review Groups. Take note that the use of Design Rules is completely optional.

To create a new Rule Set, select the New Group icon in the Review Navigator Toolbar.



This opens the New Rule Set dialog.




Importing an Existing Rule Set

When you create a new Rule Set, its references are automatically included in your workspace. To import other Rule Set references, open the R4E Preference Rule Sets Tab




Creating a Rule Area

In order to create Design Rules, a Rule Area et a Rule Violation containers first need to be created.

Rule Areas represent a logical grouping of Rule Violations. They can, for instance refer to a specific language of element of the architecture. To create a Rule Area, right-click on the parent Rule Set and select the New Rule Area command.


This opens the New Rule Area dialog.



Creating a Rule Violation

Rule Areas contain Rule Violation. A Rule Violation is a logical grouping and Design Rules. They refer to a specific problem highlighted by the Rule e.g. Syntax Error, Bad Naming Convention etc.

To create a New Rule Violation, right-click on the parent Rule Area and select the New Rule Violation command.



This opens the New Rule Violation dialog.




Creating a Rule

A Rule is the smallest unit in the Design Rule hierarchy. It refers to a specific code convention that is to be followed. The values of the rules are automatically set in anomalies that are created using the Rule as a reference. This can speed up and put some consistency in the review process.

To create a New Rule, right-click on the parent Rule Violation and select the New Rule command.



This opens the New Rule dialog.




Working with Editors

Once the Navigator view is open and Review Items are present. The items can be reviewed. Files are reviewed using various editor views to browse the content. Currently R4E is fully integrated with the Java JDT and C/C++ CDT editors and will take advantage of the special features these editors provide.  

Files can be open in editors by double-clicking on them or their children in the Review Navigator. By default, files belonging to resource review items will be open in single-file editors, whereas files belonging to commit review items will be open in a compare editor. If the file is open using the child Selection/Delta/Anomaly element, then the cursor will automatically be positioned to the start of the line range that corresponds to the element. Files and also be open in the single-file editor by using the Open File in Editor command from the selected element context menu.



Once the file is open, anomalies can be added on the contents by selecting a range in the file and using the New Anomaly command in the R4E context menu.


Working with R4E Properties

Updates to any review elements are performed via the R4E Properties View. The R4E Properties view uses the Generic Eclipse Properties View to display the R4E Properties and will show up when any Review Navigator element is selected to display the properties that are associated with this element.

The R4E Properties View is a tabbed properties view that consists of two tabs.

Editable properties can be changed directly in the properties view. Take note that some properties can only be set when the element is created, while others could be editable only under specific circumstances (e.g. a specific element state or review phase for Formal Reviews).

By default, the Properties view is linked with the Review Navigator. This means that if an element of the Review Navigator is selected, the Properties view will be activated and will show the element's properties. It is possible, to remove this link by toggling on and off the Link with Properties command, which is located in the Review Navigator View drop-down menu.

When the Review Navigator view in unlinked, the Properties view will not be started automatically upon element selection. To activate the Properties view and see the element's properties in this case, right-click on the element and use the Show Properties contextual command.

A more detailed description of the properties for each element is shown below.

Working with Review Groups Properties

Properties for the Review Group Element includes:


Working with Reviews Properties

Properties for the Review Element includes:

Working with Review Items Properties

Properties for the Review Item Element includes:


Working with File Contexts Properties

Properties for the File Context Element include a section for the base (predecessor) and target (current) files. Each section contains:


Working with Selections and Deltas Properties

Properties for the Selection and Delta Elements include the Position (i.e. the line range) where the selection or delta is located within the parent file and the participants it is assigned to for review purposes.


Working with Anomalies Properties

Properties for the Anomaly Element includes:

Working with Comments Properties

Properties for the Comment Element includes:


Working with Participant Properties

Properties for the Participant Element includes:

Working with Rule Sets Properties

Properties for the Rule Set Element includes:


Working with Rule Areas and Rule Violations Properties

Properties for the Rule Are and Rule Violation Elements only include the name of the Area or Violation.


Working with Rules Properties

Properties for the Rule Element includes:


Using Key Bindings and Hotkeys

Keys

Eclipse allows you to customize your keyboard using General>Keys preference page. Within Eclipse, key strokes and key sequences are assigned to invoke a command.

Bindings

R4E defines some keys as accelerator keys to help the user to perform reviews. Each command starts with ALT +4 as below:


When selecting the accelerator key ALT + 4, if the user waits before selecting the next accelerator key, a commands list like the one shown above will be displayed at the bottom right corner of the Eclipse window.

The default Copy and Paste accelerators (CTRL+C, CTRL+V) are also available in the Review Navigator view to clone Anomalies and Comments.

Using Notifications

R4E support sending Meeting and E-mail notifications directly from the Eclipse workbench. Notification send are pre-filled with all the relevant information, making it easy to have standardized communication between the Review participants.

Meeting notifications also can be used to schedule various meetings (e.g. decision meetings) automatically.


Using Email Notifications

E-mail notification can be sent on Review Navigator elements by using the Send Email/Notification command from the selected element context menu.



Once the command is triggered, a dialog appears asking the kind of notification to be sent. Take note that not all the options are available depending on the element selected, the review type and other factors.



Selecting one option and closing the dialog will show up a simple email client pre-filled with all the relevant information. The user is free to modify the information as he sees fit and send the email by clicking the ''OK ''button.




Using Meeting Notifications

Meeting can also be scheduled directly in the workbench using R4E. Meeting data generated is in a VCalendar format that is attached to the Email that will be sent. Meeting data for decision meeting is mandatory for Formal Reviews and optional for other review types.

To add meeting data, use the ''Update ''button in the Extra property tab, under the Decision Information section, for the selected Review element. This will open the Meeting Information dialog.



The meeting information to enter include the time of the meeting, the duration and location where the meeting will take place. To make the time entry easier, you can use the date selector button (the "..." button on the right side of the Starts text field).


The meeting info stored in the system can be retrieved at all times by using the ''Refresh ''button in the Extra property tab, under the Decision Information section, for the selected Review element.


Using Statistical Reports

Statistical reports provide useful information to analyze the efficiency of one or several reviews.

Generating Reports

To generate a statistical report, select in the Review Navigator view one or more review, the right click and select "Generate Report"

Two types of report can be generated.

The report folder is located under the group folder. The group folder is specified in the R4E Preferences,

If the user is not allowed to create a report in the existing group report directory, a new pop-up allows the user to select or to create a new directory to save the requested report. The user can enter a path or select the Browse button to select a location where to store the report.



When the report generation is completed, a pop-up window will indicate where the report was stored.



Once the OK button is clicked, the HTML report will be displayed in the default web browser or in the Eclipse web browser depending on the Eclipse web browsing preferences.

Report Contents



Report Summary

This section lists the reviews that were selected for the report. The review name, group, component, review item type, review type and project information are displayed for each review. The total number of reviews is also displayed at the bottom of this section when more than one review was selected.

Review Anomaly Statistics

This section provides the following anomaly counts.

Review Efficiency Statistics

This section provides several interesting review efficiency statistics divided in the following groups.

Review Items
Review Anomalies
Average Time Line
Average Effort per Participant
Total Review Effort
List of Anomalies

This section is only available for the inspection record. The list of anomalies raised during the review with the following information: File Name, line range, tile of the anomaly, class, ranking and the due date.

Performing Reviews

Performing Basic Reviews

In R4E, basic reviews are the simplest form of reviews available. Basic reviews are stateless and the anomalies that are raised are also stateless. This means the participants must track progress of the Review and of the raised Anomaly externally.

Typically, the workflow of a basic review will go as follows:

  1. Review is created
  2. Review Items are added, either by manually selecting resources or by automatically selecting files committed using the Find Review Items command on the target project .
  3. Optionally, review elements are assigned to specific participants.
  4. Organizer/Lead notifies reviewers that the items are ready for review. his can be done externally or by using the Email notification functionality provided by R4E
  5. Reviewers review their items and raise anomalies as they encounter them.
  6. At any time there could be communication between the reviewers and the authors of the code under review. Since there is no anomaly state tracking, they will have to agree on how to handle the anomalies raised.
  7. Once all the reviewers are done and the anomalies are fixed, the review can be set as completed.


Performing Informal Reviews

Informal Review workflow is pretty much the same as the Basic Review workflow, so the steps described above still apply. However, the main difference is the fact that anomalies are now stateful and they need to be addressed/resolved before the review can be closed.

The state diagram for the anomaly workflow is as follows:


Once all the Anomalies are in a terminal state, the review can then be closed as it is done for Basic Reviews.


Performing Formal Reviews

Formal Review follow the IEEE 1028-1997 standard. They are stateful and divided into Review Phases. As in Informal Reviews, anomalies created are also stateful.

The state diagram for Formal review workflow is as follows:

Planning Phase

The Planning phase is the active phase when the review is initially created. In this phase, the Review Organizer and/or Lead adds the contents that is to be reviewed, either manually or by selecting items from the Version Control System and adds participant that will be part of the review. Optionally, review elements are assigned to specific participants. At the end of this phase, a notification is sent to the participant that the items are ready to be reviewed, and an invitation to a decision meeting set-up by the Organizer/Lead. Once this phase is completed, it is impossible to go back to it.

Preparation Phase

The Preparation phase is the phase where participants review the items included in the review and potentially raise anomalies. Once all reviewers have completed their tasks (and notified the Organizer/Lead), then the review can progress to the next phase.

Decision Phase

The Decision phase is where all the anomalies that were logged are analyzed and a decision is made on each of them on how to handle them. Potential outcomes include fixing the problem flagged by the anomaly, deferring it, or rejecting it if it is not valid. Once all the Anomalies are examined, a decision can be taken on how to close the review. The possible outcomes for the review at this stage is that it could be rejected and more reviewing/rework is necessary, it could be accepted as is, or it could be conditionally accepted, provided that the outstanding anomalies are fixed.

Rework Phase

The Rework phase is an optional phase, only used when a review is conditionally accepted, in which valid anomalies are fixed. Once the fixed are included, the anomalies will need to be re-checked to verify that the fixes are acceptable. When all the fixes are verified, the Review can be completed.

Other Considerations

Take note that there is a slight difference between the anomaly states in Informal Reviews and the ones used in Formal Reviews, as it can be seen below:

A new Anomaly in a Formal Review is set to CREATED ''by default. During the decision phase, it could be set to the same values as in Informal Reviews, and it can also be set to ''ACCEPTED, which means that the anomaly is deemed valid and will be handled and fixed. There is no ''ASSIGNED ''state for Anomalies in Formal Reviews. The rest of the anomaly flow is essentially the same as with Informal Reviews.